None of us “like” out-of-date things. Updates to apps and operating systems bring us new features, improved functionality, better user interfaces, and (most importantly) bug fixes.
We all hate bugs, but bugs vary in severity from mildly frustrating to zero-day security holes that can be exploited to do all kinds of nasty stuff. Depending on their type and scope, patches and updates aren’t things that arrive on our smartphones and tablets all that easily. Each bringing its own set of challenges and frustrations.
Applications get updated with whatever frequency their developers deem appropriate. Sometimes these updates add new features (which require additional permissions to be granted) in addition to other enhancements – and bug fixes. In order to fix critical holes in security or functionality, users must accept the new permissions that are being requested. If they don’t want to grant the new levels of access, their only options are to uninstall the app or put up with the vulnerabilities of the pre-patched version of the software in question.
This behavior is scheduled to change in Android M, once developers start writing their apps against the “M SDK”. This new version of the Android Software Developer Kit will change the way permissions are presented to users. Instead of an all-or-nothing approach that every past and present versions of Android has adopted, Android M is supposed to ask for permission to access a certain feature only when that access is requested, not when the app is installed. These permissions can then be sorted at a later date, and even toggled on or off – as the end-user desires.
Granular, on-demand permissions aren’t new. Blackphone and iOS have been doing that sort of thing (in their own ways) for some time now, but both suffer from the same limitation: disallowing access to requested permissions will result in limited functionality of the app. Dealing with the lack of authorization to use a specific permission is left up to the developer of the particular app. Blackphone’s solution isn’t elegant since apps aren’t (yet) designed to handle being denied what they request. Whether or not apps built against the M SDK will handle these scenarios any better remains to be seen.
Google has learned a lot about OS updates over the years (we’ll get to those in the next section). The solution to fixing bugs or adding features has been through updates to code libraries.
Currently Google pushes updates to Google Play Services, Google Play Games, the Google app (which provides search and other services to devices), Android System WebView (a component powered by Google’s Chrome engine which allows apps to display web content inside the app itself), Google Connectivity, and others.
All those apps are essentially libraries – collections of code – that extend functionality to the operating system and apps that call upon them. Developers include references to these libraries in their code instead of “reinventing the wheel” and writing their own code to accomplish something included in the library. Rather than waiting for an OEM and a carrier to test, certify, and deploy an update for every phone out there, Google can push updates to these libraries (sometimes transparently) directly.
These transparent updates may bypass the traditional approval dialogs, something that is fairly concerning.
The last type of updates to discuss here are updates to the operating system itself. Currently these updates may be automatically pushed to our phones (but manually approved by the user before they’re installed), notified to our phones (with download approval requested), or we may even have to search for those updates manually – or some combination of all of the above.
Thanks to the quagmire of OS update routines, mechanisms, and “hoops”, this may be a non-issue – for now. However, looking at what Microsoft may be doing with Windows 10 and its forced automatic updates, there’s cause for concern that this approach may be taken with Android (and other operating systems) as well.
Updates can add unwanted features, remove wanted features, change the way apps work, and can even be exploited by third parties or disgruntled employees (or at the requirement of nosey government agencies) to install malware, weaken cryptography, or enable backdoors that weren’t otherwise present.
Today we have the ability to deny the installation of those updates, but in the not too distant future, if Microsoft’s method is widely adopted, we may very well lose this “final say”. It removes you and I as the “owners” of the devices that we use, and instead puts that control in the hands of the maker of the operating systems they run.
Automatic updates, regardless of which of the three types we’ve talked about here, should be limited to critical security patches only. Every other update should require end-user approval, and the two types should never be intermingled into a single update package.