Disappointing: Google Releases... Then Removes Great Privacy Feature From Android
from the bring-it-back! dept
Peter Eckersley, over at EFF, has a disappointing blog post, noting that Google apparently released and then very quickly removed a really good privacy feature in Android. Basically, it would let users have much more granular control over what kind of data an app could access. Right now, when you install an app on Android, the system will tell you what kind of data it wants to access, and then you have to agree across the board, or not install the program. The new feature effectively gave users something of a line-item veto, blocking specific types of data access, while allowing others to go forward, so that people would still use the apps, but block certain attempts to access certain kinds of data they didn't want that app to see.Thus, it's really unfortunate that Google so quickly removed such a great feature. Google claims the feature was "released by accident." You could see how some app developers might be upset about such a feature, but hopefully not the good ones. If anything, this will drive app developers to be much more protective and careful both in how they design their apps and in how they explain the need for data access to users. As Eckersley notes, the right thing for Google to do here is to re-enable this feature. The fact that it released it, shows that they've actually been working on it and have the code. Hopefully, the true story for why it was removed was merely that the code wasn't quite ready, and that the code will be returned in the near future. In the meantime, however, those who jailbreak or root their device can get the same functionality -- but hopefully it will become standard on Android before too long.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
CyanogenMod (CM) 11 (Kitkat 4.4.2) has it
Open source is a wonderful thing.
Ehud
Tucson AZ
[ link to this | view in chronology ]
Re: CyanogenMod (CM) 11 (Kitkat 4.4.2) has it
The applications should ask for permission upon having to use a determined feature and the user should be able to grant such permission permanently or on a per-use basis. That's one major flaw in Android, unfortunately.
[ link to this | view in chronology ]
Re: CyanogenMod (CM) 11 (Kitkat 4.4.2) has it
[ link to this | view in chronology ]
WHY? IS SPYING BAD? -- Except when Google does it?
And it's not new. I've a tagline from quite some time ago:
Where Mike sez: "Any system that involves spying on the activities of users is going to be a non-starter. Creeping the hell out of people isn't a way of encouraging them to buy. It's a way of encouraging them to want nothing to do with you." -- So why doesn't that apply to The Google?
04:54:07[f-917-7]
[ link to this | view in chronology ]
Re: WHY? IS SPYING BAD? -- Except when Google does it?
[ link to this | view in chronology ]
Re: WHY? IS SPYING BAD? -- Except when Google does it?
[ link to this | view in chronology ]
Android Without Google
http://sufficientlysecure.org/index.php/2013/11/26/an-android-without-google/
[ link to this | view in chronology ]
Sorry but this should be standard and required by common sense.
It speaks volumes about how much this type revenue brings in that they do not.
[ link to this | view in chronology ]
Re: Sorry but this should be standard and required by common sense.
For example, I've heard many Android users say, "This app shouldn't need to monitor my phone calls - THEY'RE SPYING!!1!"
In reality, many apps need to monitor the state of your phone so that they can pause themselves if you get a phone call. Imagine people with no knowledge of how Android works deciding to turn off phone monitoring. They'd learn to *hate* Android because of the terrible user experience that they themselves have created!
THIS is what google needs to overcome before releasing such a feature (maybe by making it difficult to turn on, or something).
[ link to this | view in chronology ]
Re: Sorry but this should be standard and required by common sense.
Google doesn't care about privacy. They may say how much they protect your information, but then spam you with the search information you found using their search engine built into their 'droid device! The company benefits quite well from any data it can collect. Why would it want anyone to opt out of something?
[ link to this | view in chronology ]
Google philosophy
Google is still a whole lot better than the alternatives. That doesn't mean that I don't want more than they offer.
[ link to this | view in chronology ]
https://play.google.com/store/apps/details?id=com.stericson.permissions
Also, you don't "jailbreak" an Android phone. You Unlock the bootloader (if you have to as some phones come with the bootloader unlocked already), load a custom recovery mod (again if you have to as some phones will allow you to load custom packages without replacing it) then you can load the su binary and corresponding app that give you the ability to run apps with root permissions (or load a custom ROM that already has these things built in instead of the stock one) which is commonly known as "rooting" the phone. This is a completely different process from "jailbreaking" an iPhone which merely allows you to add the Cydia store that can be used to load apps that are not sanctioned by Apple's App Store. Stating "those who jailbreak"... "their device" when referring to Android devices simply makes you sound like you don't know what you are talking about.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
PS - I still cringe every time I hear someone talk about their cable or DSL "modem" when they really mean "bridge" or "router" so I know I can be a stickler some times for using the correct technical terminology. >:P
[ link to this | view in chronology ]
Re: Re: Re:
Depends on who you talk to. My device is a modem, switch and wireless router all in one. Here's a back shot of it
http://www.zyxel.com/uploads/images/public/vmg8924_b10a_spec_rear_pane.jpg
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
Are you sure you know what modulation actually is?
http://en.wikipedia.org/wiki/Modulation
Converting analog audio tones to and from digital data is known as an analog to digital converter (ADC) the reverse being a digital to analog converter (DAC). While it's an integral part of modulation that by itself is NOT modulation.
I assure you that digital signals are quite reguarly and correctly modulated.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
http://en.wikipedia.org/wiki/Modem
But this is more what I was referring to...
I guess technically just about any data that is transmitted is transmitted in SOME form of analog wave stream so any thing that converts that to and from a digital data bit stream is technically a modem. Just not in the same way that traditional modems work.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
A modem is a "modulator/demodulator" device, for converting between analog and digital signals, yes. But the analog side doesn't have to be "audio tones".
The coaxial cable used by cable TV, and by a cable modem, carries analog signals. The cable modem serves to mediate between that and digital equipment.
A cable modem often also does other things, including act as a network bridge, and very often a router; the one in our house, like many, includes a built-in minor Web server to provide an admin interface. But a cable modem doesn't have to do any of those other things (except possibly the network-bridge part), and it certainly does serve as a modem as well.
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
Jailbreaking - Allow a phone to use software other than provided or from 'authorised' sources. {mainly applies to Apple products)
Unlocking - Allow a phone to use any carrier service of the users choice.
Rooting - allow full administrative and debug access to the phones underlying system. This can either be OS, ROM, BIOS, or combination of all.
To Jailbreak or not is a EULA problem
To Unlock or not is a contractual problem
To Root or not is an ownership problem
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
For developers...
I develop an app (say) that needs to see your address book and your GPS location. If you don't like that, fine. Don't install it.
But with this suggested facility my app has to be able to gracefully handle a whole load of awkward cases where the user installed the app but didn't give permission for all the things the app needs to work.
Otherwise I get a bad rap in the app store. Sounds like a right mess.
What seems like a BETTER idea is being able to specify what I'd be prepared to authorise and using it as a filter when I view the app store.
[ link to this | view in chronology ]
Re: For developers...
However, apps don't have to handle denial of access, because the OS can just pass back bogus data if the permissions have been denied.
The reason your filter idea doesn't work is because often most of the most useful or popular apps ask for far many more permissions than they need, and users have no control over it. The flashlight app that reaped user data and sold it to third parties without their permission comes to mind, even if you said "no" to the popup that asked you.
[ link to this | view in chronology ]
Re: For developers...
[ link to this | view in chronology ]
Re: For developers...
No it doesn't. Anyone that would know how to use the feature to deny permissions to your app would know that they did so and that was why some functionality wasn't working in it and thus would not blame the app developer when they specifically denied permission to the app for one piece of functionality.
Also consider this: Let's say you developed an app that manages cloud storage content (such as Dropbox) and requires the typical permissions that you would expect for this type of app. Let's say you also built into the app the ability to share links to the content on your cloud storage into the app and for this functionality to work the app would require access to the Contacts.
Now let's say I look at your app and love the UI everything about the way it works except I have absolutely no use for the sharing functionality and really don't like the idea of giving your app access to my Contact List. In the current world without this or some app that provides this functionality I either have to live with the fact that the app has access to something I didn't want to give it or do without the app. However, with this sort of functionality, I can install the app, use it for the purposes I want, and deny it access to the things I don't want it to access and everybody is happy.
[ link to this | view in chronology ]
Re: For developers...
[ link to this | view in chronology ]
Re: Re: For developers...
The biggest offender is "network access" (followed closely by access to the contacts list). Almost all apps demand permission to access the network, but most of them don't actually need it.
[ link to this | view in chronology ]
Re: Re: For developers...
So surely the answer is to punish developers who ask for too many privileges, not make it easy for people to install the bad app anyway with a few things turned off.
For every smart user who spots the overreach and refuses there are more who won't understand and will blindly say yes.
If developer overreach does not result in a lost download, what incentive is there for the dev to fix it ?
To all those who say "a good dev should handle partial permission" this is daft. If I make a contacts viewing program that needs access to contacts and Android lets people install without granting access to contacts, I then have to code for a ridiculous use case, specifically that the app can't access contacts due to user permissions. Obviously in this example it's trivial. But with more complex apps you've just added a whole load of work that simply need not have happened.
[ link to this | view in chronology ]
Re: Re: Re: For developers...
Not at all. A well designed app should be fault tolerant for any and all faults that it might encounter. If you're engineering by trying to predict what might go wrong and only handling those cases, you're designing a brittle app.
It's bad programming practice to assume that any operation will always succeed.
[ link to this | view in chronology ]
Re: For developers...
You should be able to handle the case where the user has not populated any given user info. It should have been one of your test cases. If you built a modular app with incremental testing, it should be rather easy to catch the error (you are throwing your null pointers as sensible errors, right?) and load the dummy data you used prior to implementing support for importing the info instead.
So this really just forces developers to use good coding habits. I'd recommend avoiding the apps of any developers who complain about things like this.
[ link to this | view in chronology ]
Re: Re: For developers...
However
- if, as has been said, a request to Android for something not authorised gets dummy data back, this is inherently not useful. If someone asks my app to de-dupe their contacts and they have turned off access to comntacts, the correct response from my app would be to say "I can't do that for you as you've denied me access" not cheerfully work on a dummy empty contacts and waste everyone's time.
- I would still maintain that if (as all posted here seem to agree) there is a problem with apps asking for far too many priveleges, punishing their overreach by denying installation (as happens now) sounds like a better way to change their behaviour. The alternative is that people install the app anyway but with access denied, see that it apparently works anyway, and the message never makes it back to the dev.
The suggestion that if I applied a filter to the app store I'd see almost no apps surely shows that there is a widespread problem that needs fixing. This proposed change wouldn't change that.
[ link to this | view in chronology ]
Re: For developers...
A well-written app should already be able to gracefully handle all these failure conditions.
No.
There are too many apps that require permissions to do things that they have no business doing. Your suggestion would mean that there would be almost no usable apps.
A much better idea is that I, as the machine's owner, gets to decide what apps get to do what and when, regardless of the app-writer's desires. If that means the app doesn't work at all, then I'll just use another app.
For the record, I do selectively deny permissions to apps like this and almost all apps are just fine with it. Why should my cookbook app get unfettered access to the internet, or my contact list? It shouldn't, and I can make sure that it doesn't.
[ link to this | view in chronology ]
Re: For developers...
Only because you don't understand the actual mechanism that is at work. What this feature does won't break any app unless the app is already broken by design.
Think: if your app needs network access, and the user is in Airplane mode, does your app crash? If it is well designed, it won't: it will just not get internet access. This mechanism works like that.
In your case, when you ask for the address book, the system will provide you an empty one. You app can handle empty lists, yes? As for the GPS, your app will probably receive coordinates 0,0. Again, your app should probably be able to handle this without any fuss.
True, your app will be mostly useless without access to those things. But the system WILL NOT make your app crash or raise exceptions if the user blocks access to those things. It will give it fake values (like empty lists, zeros, etc) and fake interfaces (is that what they call it in Android?) which your app should be able to handle gracefully.
In other words, if your app works and obeys the guidelines, it will continue to work. It just won't be as useful (but the user DID ask for that by denying permissions).
"What seems like a BETTER idea is being able to specify what I'd be prepared to authorise and using it as a filter when I view the app store."
No. It is not. The Android security model is broken for many reasons. Here are some off the top of my head:
It's all or nothing, forever
You either give the app irrevocable access to the system for all eternity, or you can't even install the app. Period.
It would make much more sense to ask the user every time you needed to do something "nasty" (like access contacts). The iPhone does this and, hell, even windows does this to a lesser degree with UAC prompts*.
Is it annoying? Yes sir, it is. But annoying is good because it'll force you, the developer, to think twice before engaging in "nasty" behaviour and annoying the hell out of your users.
Permissions are not finely grained
The permissions categories are too broad.
If I need my app to be able to know when you are in a call or not for any reason, I can request the READ_PHONE_STATE permissions...and also gain access to your IMEI and phone number. Likewise, an application that monitors disk usage should not have disk write permissions, but that's exactly what it is going to get.
Coarse permissions make sense from a usability point of view but as a power user, I would like to know EXACTLY what the app intends to do with those permissions.
This could be achieved by presenting a GUI with the coarse permissions which, when pressed, show the finer permissions.
Android developers are idiots
There, that title should wake you up. Now on to my point.
How many apps are there, out there, that just ask for every permission under the Sun? Firefox is one that I know of. It asks for almost every possible permission. And for what? It's just a friking browser, made completely useless because it asks for every and all permission, and you can't control that access (I don't count relying on the developer to play nice and honour the options I selected as "having control").
And, if you think about it for a second, there's no legitimate reason for a single app to ask for so many permissions. That is only a sign that the app is poorly designed, trying to cram as much functionality in there as it can, which virtually guarantees that the app will be buggy as hell.
More people should employ the the UNIX philosophy, that is to make apps that do one thing and do it well. That creates less chances for things to blow up.
User Choices
The play store says that an app needs access to Internet access and my contacts before allowing installation. What do I do? Do I install it, run it and potentially let it harvest my contacts, or do I decline? Some applications are obviously scams, but others won't become apparent until you start using them...and after your system is already hosed.
Frankly, coming from a Unix heritage, is embarrassing how much security was dumbed down on Android, in the name of usability. But, as it stands, there isn't much Google can do about it other than say "from Android 5 on, you need to use this new permission model. Android 5 is not backward compatible.". But Google won't do that because it will annoy the hell out of developers. So we're stuck with what we have for the foreseeable future.
* Well...there's the superuser prompt...which you don't even get by default because you don't have root...and that's it...
[ link to this | view in chronology ]
Re: Re: For developers...
A million times this. It was the single biggest disappointment with the Android OS. I think they figured that is iPhone users don't mind shoddy security, neither will anybody else.
At least it's more-or-less fixable, though. Between the apps (and Cyanogenmod) that give you finer-grained control and using a firewall to ensure that almost no app can talk to the network, I am (just barely) OK with the situation.
[ link to this | view in chronology ]
Re: For developers...
Maybe you need a bad rap. I can see why you'd object.
[ link to this | view in chronology ]
Re: For developers...
Sometimes called the if-Then-else structure
1. LEARN IT
2. Use it
3. APPLY IT
4. Profit!
Otherwise just go back to writing goto/gosubs and stop whinging
[ link to this | view in chronology ]
Re: For developers...
[ link to this | view in chronology ]
Re: For developers...
[ link to this | view in chronology ]
Guess they ended up doing it anyway. I'd love this feature, and am sad to see it go, but I also accept Google's reason and believe that they wanted to make it ready fully before allowing it. My opinion is that they want to make it a part of the APK that your program has to continue working if your app was denied a permission it asked for.
See, right now, your app will crash - hard - if it tried to use a permission that is disabled. So google will reintroduce it only when it becomes a standard for people designing under the new android versions to put in "permission denied" workarounds, even if it's to say "this program cannot and WILL NOT work without XXXXXX permision" and close.
[ link to this | view in chronology ]
Re:
Most of the apps I use this feature with don't crash hard at all. They continue to work except for any functionality that actually used the denied permissions.
Some apps even check to make sure they have the permissions they think they need and give me a dialog box saying they can't work because they don't have x permission.
This condition is easy to handle for programmers. Crashing hard is an indication of a badly written app that you don't want on your device anyway.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
This wasn't "released" nor will it ever be
"T he mere fact that users discovered how to access an internal debug tool, one which has the very real potential to break compatibility in a great deal of applications, does not mean that it was ever “released”—no matter how much any of us want such a feature."
[ link to this | view in chronology ]
Re: This wasn't "released" nor will it ever be
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Wait, there are people that dont root their android device???
Whats the point of an unrooted android?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
it sound's like beta feature
I am sure there are a lot more examples even on my lightly loaded tablet, but it's hard to tell as the App Ops app doesn't see all the privileges that an app may have.
[ link to this | view in chronology ]