Smartphones are intensely personal (which is also why people can get so worked up if they think you're insulting their choice of smartphone; it's tantamount to insulting their personality). And when it comes to data, the events of the past six months - starting with the Guardian's revelations about NSA and GCHQ surveillance - have heightened peoples' awareness of the idea that it is their own data.
In fact the Information Commissioner's Office released app guidelines on Thursday which pointed out that these concerns are becoming significant:
A survey of 2,272 British people conducted by YouGov and commissioned by the ICO found that 59% have downloaded apps, but that 62% of them are concerned about resulting privacy issues. Over 40% said they have decided not to download at least one app due to these fears.
So why would you let an app get that sort of access to your contacts, location, or storage? If you're using Android, the answer is that you don't get much choice, unless (like those 40%+ in the survey) you decide not to download the app. And the peculiar thing is that Google seems to be quite OK with that - and in fact has gone as far as to reverse an update which let users block apps from accessing data they shouldn't.
The consequences of that are already beginning to play out as people notice the difference - and complain in the only way they can, by giving apps lower ratings for what they see as excessive demands.
The problem surfaced at the end of last week, when the Electronic Frontier Foundation (EFF) first praised and then doled out brickbats to Google for implementing, and then reversing, a function which allowed users to set per-app permissions to data such as their contacts, call log, location and so on. To access it you had to download a free third-party app called App Ops Launcher.
Once you installed and ran it, you could see and control all sorts of individual permissions - as shown below.
But the exposure of App Ops had only a short life. Bip! There it was in Android 4.3, which arrived in mid-November. Bam! There it was, gone in Android 4.4.2, released about three weeks later.
In fact it only seems to have appeared in 4.3 by virtue of a brief edit war in the Android code tree between Dianne Hackborn, an Android product manager, and Dave Burke. Hackborn removed the feature on 1 August; Burke put it back in the next day. The change made it through, but then was reversed once again, and 4.4.2 rolled out to squash it. And according to app developers, 4.4.2 properly kills App Ops: it simply won't function unless you take the extreme measure of rooting your phone. (Very, very few people do this.)
The upshot is that Android users once again can't control what permissions an app takes for itself - unless they reject the app wholesale ahead of installation.
And the effects of that reversal are showing up. OpenSignal, a crowdsourcing app which feeds back data about signal strength in various location, has suddenly seen a rash of bad reviews, says James Robinson, the company's chief technology officer. "The decline is all due to poor ratings on Android 4.4, where the ratings have dived from 4.3 to less than 4 in under a week," says Robinson.
He points to flaws in how 4.4.2 records changes to requests for permissions: though it appears to ask for access to USB storage, contacts, messages, phone status (which appears as "phone calls", location and network communication ("connect and disconnect from Wi-Fi"). The app, he says, used to need "Read Contacts" permission before Android 4.1 to count how much time you'd spent on calls; "Call Logs" was added later. And he's insistent that it never reads SMS or contacts.
But the bad reviews have been coming in - and in a number of cases they're related to the app's apparent demand to read contacts.
The reviews also show that nobody knows why the app might want to access your contacts - but they do want to block it.
The bizarre thing is that Android, which has always led Apple's iOS in terms of customisation - choose your own keyboard, choose your own default apps - has now lagged in this key area by more than a year, in a field where people have become more and more aware that data matters, and permission matters - and the ability to revoke permission matters even more.
Path to problems
Android used to be ahead of Apple's iOS by virtue of the fact that it did at least tell you what elements of your phone an app might access. That was in stark contrast to iOS, where before 2012 you didn't actually know what an app was up to after you downloaded it. That led to the furore in February 2012 when it was revealed that the social startup Path was grabbing iPhone address books and uploading them to its servers.
Path said sorry (raising the question of why it needed to be sorry for something that obviously wasn't an accident; shouldn't it have just not done it in the first place?). But the fallout was considerable.
Path was subsequently fined $800,000 by the FTC. Apple faced a congressional inquiry. But it took action: in September 2012 iOS 6 let you block apps' access to system-wide elements such as location, contacts books, Twitter and Facebook. (In 2013 it added microphone access to the controllable elements.)
The result is that any time app tries to access your contacts, or location, or photos without your having given permission, you'll be asked whether to allow it or not. You can simply block apps from ever getting access.
Permission not denied
But Android, which was on version 4.1 in July 2012, hasn't done anything about permissions.
That has led directly to user problems such as the Brightest Flashlight Free app, which grabbed the location and device ID of millions of people in order to show them ads - even if they didn't agree to it. And there are still thousands of pieces of Android malware about which exploit the fact that nobody really understands why apps are so demanding in permissions.
Yet when you add in the revelations about the NSA and GCHQ's surveillance of citizens, and that the NSA allegedly spied on Angela Merkel's phone, it creates an atmosphere where people are less willing to let their smartphone - which is, remember, the most personal device you own - be open to all and sundry.
Google, however, doesn't seem to be hearing this. In a Google+ thread, Hackborn defended her actions. (Google+ is now the only place where you will find out what Google engineers are thinking.)
"It wasn't intended to be available [to users]. The architecture is used for a growing number of things, but it is not intended to be exposed as a big low-level UI [user interface] of a big bunch of undifferentiated knobs you can twiddle."
She suggested that the per-app settings are "mostly for platform engineers… maybe some day for third party developers."
This didn't really wash with the people in the thread, who all appear to be Android users, and had plenty of counter-examples to explain why they most certainly did want some undifferentiated knobs they could twiddle. Such as Jon Sykes, who pointed out:
The Facebook app is a perfect example of an app I want to have , but refused to install on my phone because of the excessive permissions it wants:
Directly call phone numbers
Record audio
Read call log
Write call log
Download files without notification
Retrieve running apps
Draw over other apps
Prevent phone from sleeping
Turn sync on and off
Install shortcuts
Send sticky broadcast
Not one of those is justified for Facebook to show me updates from friends and family. Being able to go in and turn them all off is exactly what Android needs to let users do.
Possibly Facebook wants those permissions so that it can run Facebook Home, but the problem with the Android model is you just don't know. And moreover, without App Ops and 4.3, there's no way to prevent that short of not installing the app (as Sykes did). And even though Android is good in the way that it does tell you what an app will demand to access, it's terrible in letting you know why apps want that access.
increasing wariness
Any iOS user will be alerted to its privacy settings the first time an app tries to access something, whether it's location or contacts. The more technical Android users are clearly pained to be passed by Apple - especially in the provision of knobs you can twiddle.
Hackborn's tone comes across as exasperation and faint disdain that people should want to be able to change such settings. She seems to be underestimating a significant chunk of Android users.
Quite why Hackborn is so against the idea of people having this sort of control is a puzzle. Google has officially described the exposure of the App Ops interface as "experimental", and there have been indications that it's worried that apps might crash if denied access to data they expect.
"We aren't attempting to break anything for users," Hackborn insisted. "We are fixing security holes in the platform that developers have been using to get access to parts of the system that were never intended to be accessible."
Except they aren't really security holes. App Ops doesn't exploit a security hole; it just exposes something that's already there. By removing access, Hackborn is making security worse, not better.
She said that the UI for App Ops "is there for platform development purposes. There isn't really much utility for third party developers. As I said, App Ops is a part of the platform framework that is being used for an increasing number of things, which are visible in the UI - per-app notification control, location access history, current SMS app - and this UI is just a tool for people working on the platform itself to more easily debug and interact with it."
But why should that only be for developers? Don't users want to be able to control it too? Remember, if the response is "but users don't care about that stuff, and would find it confusing", Apple does make that stuff available. If Apple users can understand it, so can Android users. And the ICO survey shows that this lack of control is hurting Android developers - over 40% of people in its survey have decided not to download an app because of the data it wants. Given that iOS doesn't tell you what permissions an app will request, it can only be Android that they're referring to.
There's another argument that defenders of the current poor state of Android's permissions put forward: apps would crash if denied such permissions. That might be true, but it suggests that the apps (and/or Android's APIs) are poorly written: if they "need" access to your contacts, what happens if you don't have any contacts? If they "need" network access, what happens when that's off? If they "need" access to your call logs, what happens if those are blank? Android must return some sort of result in that case, and the fact that users of App Ops on 4.3 didn't storm the barricades complaining about crashing apps suggests that this isn't a problem.
And to those who say "you should just download a Permissions App" - implicitly acknowledging that the problem exists, but that you have to fix it on your personal device, not the maker of the software - that in turn suggests that apps won't crash left, right and centre if denied permissions. Which in turn suggests that Hackborn's description of "security holes" doesn't stand up. The security holes are the ones allowing apps to siphon your data, not the existence of App Ops.
Furthermore, the claim (also made) that "if the permissions change, I can just get rid of the app" points to the problem highlighted by OpenSignal above: 4.4.2 doesn't actually give the correct information about permissions changes.
Follow the money?
It's known that Google makes its money from pulling in data from users of smartphones - an increasingly important sector. That's why the loss of maps provision on Apple's iPhones (and to a lesser extent iPads) was such a blow, though Google Search is still the default on iOS. (One might wonder: for how long? Would an incoming chief executive at Microsoft make a better offer than Google for Bing to become the default search on iOS?)
So is the reason why it hasn't given users more control over their data that doing so would threaten its revenue stream from Android?
Or is it that, as it tries to take more control of Android by removing various elements from the open-source Android code (AOSP) - which now lacks a browser among other things - that it also wants to take this privacy control out, and make it a separate downloadable app, as Google Play is?
That doesn't seem likely; I asked the team at CyanogenMod (who have their own Privacy Guard software which exposes the App Ops interface) whether you could take that functionality out and re-enable it with an app. The consensus was that virtually impossible given the Unix model that Android is built on.
So where does that leave Android? Still without a decent permissions model, unless you're running 4.3 - which, according to Google's own statistics, is just 4.2% of those whose devices accessed Google Play in the last week of November.
That leaves a whopping 95.8% of Android users - probably a billion or so - who can't control whether rogue apps grab their data, nor what they do with it. Contrast that to Apple's figures for the proportion of devices using iOS 6 or above - 96% - and you have a stark contrast in the platforms' approach to apps and data.
Update: added extract from article about the Information Commissioner's survey on app privacy and guidelines.
Original Article
Source: theguardian.com/
Author: Charles Arthur
No comments:
Post a Comment