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.
Comments on “Disappointing: Google Releases… Then Removes Great Privacy Feature From Android”
CyanogenMod (CM) 11 (Kitkat 4.4.2) has it
CM11 still has this feature set. Settings -> Security -> Privacy Guard.
Open source is a wonderful thing.
Ehud
Tucson AZ
Re: CyanogenMod (CM) 11 (Kitkat 4.4.2) has it
That. I just saw there’s a stable version for my phone already.
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.
Re: CyanogenMod (CM) 11 (Kitkat 4.4.2) has it
I was going to point this out along with an extra little bit. It doesn’t work like one would expect. It can, and does, cause apps to become non functional. This is probably why Google pulled the update. It’s not ready yet, at least not ready for those who don’t know how to use it properly.
WHY? IS SPYING BAD? -- Except when Google does it?
Google gets all this info, but it’s only a problem for others to have, right? — This quite clearly points up how Mike regards Google as the trust-able exception to what he otherwise states for worries.
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]
Re: WHY? IS SPYING BAD? -- Except when Google does it?
If only it was possible to choose not to use Google.
Re: WHY? IS SPYING BAD? -- Except when Google does it?
Dear blue did Google reject your job application again?
Android Without Google
It’s possible and not that difficult.
http://sufficientlysecure.org/index.php/2013/11/26/an-android-without-google/
Sorry but this should be standard and required by common sense.
Google, Apple, M$, et al should make these kind of privacy features standard. Period.
It speaks volumes about how much this type revenue brings in that they do not.
Re: Sorry but this should be standard and required by common sense.
The problem (for some apps and information) is that users don’t understand why an app requires certain information.
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).
Re: Sorry but this should be standard and required by common sense.
Exactly…
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?
Google philosophy
Google doesn’t use the GPL, and their philosophy doesn’t match the GPL. Open Source is nice, but software freedom is better.
Google is still a whole lot better than the alternatives. That doesn’t mean that I don’t want more than they offer.
Although it would be nice if this functionality were baked in to the OS. There’s been an app that does this for quite some time although it does require root access to work.
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.
Re: Re:
…Or maybe he does know about it and simply wanted to say “jailbreak” instead of that long paragraph as a form of shorthand. I’ve installed Cyanogenmod to my Galaxy S2, and whenever I’m talking about it with friends or online, I say jailbreak, even though it’s not quite the correct technical term.
Re: Re: Re:
I have never heard anyone say “jailbreak” when referring to an Android device. With most Android devices (except things like the Kindle or B&N tablets) jailbreaking would never be necessary as the OS has the ability to side load apps already built in. By default the devices aren’t “jailed” so to speak. And I didn’t say he didn’t know what he was talking about. I said saying such things makes him SOUND like he doesn’t know what he is talking about. It wasn’t meant as a dig so much as I was stating that maybe “jailbreak” was a poor word choice as some people will be confused by it. Also I went into the detail that I did so that people who don’t know would understand the difference when they read my comment.
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
Re: Re: 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”
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
Re: Re: Re:2 Re:
Modem is short for “Modulator/Demodulator” which is a device that converts analog audio tones to and from digital data. There is no such thing as a “digital modem” and it is a contradiction in terms. A bridge negotiates the connection and passes through traffic to a single device (ie. the device gets the WAN IP not the bridge). A router on the other hand gets a WAN IP from the ISP and then routes the traffic through to/from devices that are behind it which have different IPs. Many devices have the capability to be configured as either a bridge or a router but don’t do modulation and demodulation. That is what I was talking about.
Re: Re: Re:3 Re:
Er
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.
Re: Re: Re:4 Re:
Ok well maybe I was a little off base…
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.
Re: Re: Re:3 Re:
Not quite.
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.
Re: Re: Re: Re:
I always thought that Jailbreaking a phone was to let it use other carriers. Rooting is when you gain admin access to the phone and unlocking is where you can install your own software.
Re: Re: Re:2 Re:
Not really.. But to pit it simply
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
Re: Re: Re:3 Re:
Exactly, except for one minor bit you left out that can be a source of confusion. There are two different things that people refer to with the term “unlocking” one is unlocking the lock that makes it so that it only works with a given carrier which is what you are referring to. The other is the bootloader that allows you to replace the recovery software and/or ROM which is something different.
Re: Re: Re:
This. I say “jailbreak” or “rooted” as a shorthand that everyone can understand. Nothing wrong with that.
What I want to know is how many apps does NSA have in the various app stores?
Re: Re:
Terrifying ain’t it
For developers...
This feature is a nightmare for a developer.
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.
Re: For developers...
iirc, the reason this was pulled was for the exact reasons you stated – apps aren’t built to handle the denial of access.
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.
Re: For developers...
No. Your app doesn’t get carte blanche on my device just because you said so. I also seriously doubt you gracefully handle awkward cases, since you clearly can’t handle this one.
Re: For developers...
“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.”
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.
Re: For developers...
The problem is that for every app which requests only the permission it needs, there are many less than honorable apps which will abuse that process including high profile ones like whatsapp. I think it’s a good idea, even though it could create extra work depending on how your app is designed.
Re: Re: For developers...
Plus, as the AC above pointed out, what the app developer thinks the app needs to have access to and what the app actually needs to have access to can be two different things, depending on what the user wants from the app.
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.
Re: Re: For developers...
” for every app which requests only the permission it needs, there are many less than honorable apps which will abuse that process”
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.
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.
Re: For developers...
If you were following software developer best practices, you’d have everything you needed to handle those cases on hand.
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.
Re: Re: For developers...
I don’t take issue with all the suggestions of why my post is wrong (and I don’t have any apps in the app store, before you rush out to never use them).
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.
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.
Re: For developers...
“Sounds like a right mess.”
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…
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.
Re: For developers...
“Otherwise I get a bad rap in the app store.”
Maybe you need a bad rap. I can see why you’d object.
Re: For developers...
I would like to draw your attention to conditional programming..
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
Re: For developers...
good point but forward thinking and going against the curve can give the devs a better rating in the end (from a non devs perspective)
Re: For developers...
Or you can just handle the case of ‘if not all permissions are available, alert user of broken functionality due to privacy settings, and don’t run’. Simple.
Heh, when news of this first broke, I spoke with my father who we are planning to make apps together. We’d discussed, at least a year ago, that android should allow people this option. I’d argued at the time it probably won’t, since any earlier android os versions would not include this feature. Most android devices never update their core version, and those that do are usually at the will of the device maker to update the version their device runs on (such as phones).
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.
Re: 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.
so how do we check that the NSA/GCHQ are still managing to get all our information? what threat did Google get to remove the feature? had to be something beneficial to someone other than the customer. we are thought so little of, i am surprised the feature was there at all, even for a couple of days!
Re: Re:
This really has little to do with the NSA/GCHQ and more to do with being able to control the access that apps have to data and functionality on the phone. The privacy concerns are more about an app accessing GPS data or contact lists and then being able to use that data or send that data without your knowledge to the developer unnecessarily. The classic example is the before mentioned flashlight app that wants access to your contacts for some unknown reason. Sure a malicious or exploited app could be used to by the NSA/GCHQ to spy the data on people’s phones but more likely it’s the developer that’s doing it rather than the government.
Re: Re:
Google just purchased a robotics company friday evening with a DARPA contract still intact
This wasn't "released" nor will it ever be
http://www.xda-developers.com/android/eff-misguidedly-chastises-google-for-further-hiding-app-ops/
“The 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.”
Re: This wasn't "released" nor will it ever be
Came here to post this link and make the case that it wasn’t something Google rolled out then took away.
Since we know it is possible, write an app to do the same thing. Problem solved.
Re: Re:
…but will it play in googleoria ? ? ?
Re: Re:
There are a number of apps that do this, such as PDRoid and XPrivacy. I believe they all require your device to be rooted, though.
Re: Re:
Advanced Permission Manager gplay its already there
In the meantime, however, those who jailbreak or root their device can get the same functionality
Wait, there are people that dont root their android device???
Whats the point of an unrooted android?
“Google” and “privacy” don’t go well. Ask NSA.
Such a feature would be great. However, existing Android apps are programmed with the assumption that they will have access to everything they want. Limiting them could cause them to stop working.
A feature that could, gasp, shock, horror, allow people some control of their mobiles and cause the potential loss of profit? Unspeakable! It must be stamped out forthwith.
it sound's like beta feature
For Google to remove this is inexcusable. It provides a partial answer to the bloat of applications such as web browser, a weather app, a wallpaper, read contacts and more
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.