And it wouldn't do anything for if you had two phones, right? This is pretty annoying as someone who still wants to use Uber. Enough that I would consider a competitor.
Most people don't have 2 phones, and put lyft/uber on different ones. I'm presuming they're doing it so they can target lyft users with more promotions.
Isn't permission overreach du rigueur on Android? Seriously, I thought that this was a preferred engineering pattern on Android due to platform weirdness or something.
Yes it is/was. The problem is/was that your app stops getting auto updates if you add permissions later. A lot of users never go into the update section and grant new permissions and so your app stays on the version with the old permission set for ever.
First : sadly most users (and I really mean most) don't even glance at the permission screen.
It makes it hard for us Android devs to push back against the product teams when they want to add a crazy feature needing a ton of permissions (I still do though and the fact that it breaks auto updates at least is a good argument... ).
The weird part of the permission system is that we have to transition from a 'designed by & for engineers system where there were a tons of different permissions that no users ever read to a granular system where you only need to ask user's permission in order to access private data.
IMO the platform is definitely moving in the right direction (if only because it apes the other platforms approach).
Edit: interestingly, this comment had five points before the uber fans modded away. Easier to click down then explain rogue apps I suppose...
They were lucky they didn't try the beta version of the new forthcoming uber app - that version wants access to the phones of all your friends, family, neighbours, your postman, the sister of the locksmith that helped you get the spare key last year, and the chap you met on the train to work last week called Brian. Still, go uber!
i'm on marshmallow, updated the app. it popped the contacts (http://i.imgur.com/wNzktdO.png) one when i tried to create a family profile (so i could add people to my family account).
other than that, i could not make these new permissions to trigger.
Does this recovery attempt of a bad feature deserve praise? It wouldn't be an issue if permissions were properly implemented from the go - i.e. user had the control over what permissions the app gets.
My Samsung phone came with the Uber app baked into the ROM. Fortunately I know enough to disable it, but I can't completely uninstall it. And most users will be prompted ad infinitum to update until they give in.
I've said it before but I'll say it again: this is why you create a second throw-away Google account and use that to create a new profile on your phone dedicated to snoopy apps. Seriously: screw anyone that thinks harvesting my personal data is the cost I must pay for a cab ride.
I don't think that will solve this particular problem. It wan't your browsing history from the device.
What we desperately need is a UL for privacy. Just like UL tests electronics, we need a lab to test these apps for what data they access and how they make use of that data. Then assign a score so consumers can chose not to use services that request unnecessary permissions and misuse your data.
No, what we need is the ability to modify the system software on our phones easily to stop this kind of thing. On a normal Unix system you would just run the app as a separate user (or worst case, sandbox it) but on android non of the interfaces (or really much of anything at all) can be controlled by the user.
That is simply not a solution that will work for more than 0.1% of the populace. While you meant nothing wrong, your "solution" repulses me because I don’t care about this sort of thing just for myself and other supernerds, but for my friends and family and countrymen as well.
Exactly. I don't get why there is no root account on most android phones. Why is "rooting" a hack that voids your warranty? Why can't we have our smartphones like our computers?
Because alternative mobile operating systems cannot compete in the same consumer space due to the duopoly of walled gardens where people expect all popular apps to be available (although I do believe that there is a niche market for a free software smartphone amongst developers).
If you treat a smartphone as a normal computer, you would expect to be able to use a service such as Uber by means of a modern web browser providing a sandbox for their web application, like you do on Linux, Mac OS X, or Windows. Installing someone's stand-alone software only to access an on-line service would probably seem invasive and absurd.
Broadly speaking, on a smartphone people probably accept this because of the trade-off. Apple and Google keep your mobile computer stable, fast, and free from viruses and malware by managing your operating system and vetting the software you can install through their app-stores. For a lot of people this trade-off seems preferable to an alternative.
Sure it does: my browsing history, contacts, etc are separate and distinct for each profile. To the best of my knowledge there is no Android permission that'll let you cross that boundry. Please, if you know of evidence to the contrary please share a link to the Android docs. That would be a reason to root my phone and run a release with a privacy plugin.
There is absolutely a permission for that, it's called INTERACT_ACROSS_USERS. I suspect what you mean is 'is there a permission accessible by normal apps that can do this', to which the answer is no - the permission is signature-level, meaning the app must be signed with the same key as the OS to be able to access the permission.
Thank you for the correction, but my point stands: unless it's signed by Google's OS key it won't be able to cross that boundary. Although since ABC is a major investor in Uber...
I think you're misremembering. In fact they make it very easy to have multiple accounts and open them all simultaneously within the same gmail tab, switch between them and manage them fairly seamlessly.
I was recalling when Gmail first introduced free storage in Beta. I believe you were only supposed to have one account so that one person couldn't gain multiple GBs of 'free' storage.
I hate that AI support-replies are a thing. He sent a serious mail, and got a bogus reply back. I've had the same issues myself with other vendors, for instance Steam.
With Marshmallow, you can just turn off or deny certain permissions. So for most people who really want to run the Uber app, the question is really whether it runs OK without all these permissions.
My copy of Uber just updated and it doesn't seem to be requesting any of these permissions. I'm on Marshmallow, and on the permissions page these permissions are not there. Version 3.98.2 of Uber.
It's possible that these permissions are used in some obscure place in the app. With the new permissions system, you can progressively request permissions when you need them, so it's possible it will request these at some point in the future, but the app seems to run OK without them.
I also disabled access to contacts, which the app does request for some reason.
> Not 100% sure, but I think the access to contacts is so that you can split ride fares with other people.
There's a standard intent to select a contact for purposes like that, and then the app only gets access to the information of that contact. Apps requesting access to contacts get all contacts.
It's actually probably so you can autocomplete a contact as a destination address for your Uber. The same is true in Maps for navigation. Unfortunately UX wins over privacy so launching an intent to pick a contact probably wasn't as elegant as using a unified autocomplete field.
When I go to that page I see the "retrieve running apps" permission under a category "Other." It would appear that I cannot disable the "Other" category in the app permission configuration.
EDIT: There's another comment in the thread that indicates that this retrieve running apps permission actually doesn't do anything on Lollipop+: it just returns the app's own windows. Which would explain why it was moved to the "Other" category.
Right. I remember hearing from somebody about Google Now recently. The guy was happy that it reminds him of bills etc., added that it even gets the amount and due date from the "emails" and "reminds".
I don't even understand why Android would even let then happen. I can't even think of desktop apps that try to gain access to your history or bookmarks let alone a mobile app.
One time bookmark import is a thing I suppose, but that's different than gaining permanent access once granted.
Yes, obviously it's possible for them to gain access, I'm saying I don't know of any desktop apps that need access to any of that other than one time bookmark importing.
Come on guys, where are the academics? Instead of overreacting please just reverse engineer, get the facts and check WHY the Uber app actually requests these permissions. I mean, it's still Java, so you got the source. I don't think they're using native code or do more obfuscation than the average app (disclaimer, haven't checked (yet)).
Who's first?
If you'd find out the Uber app is sending home your browser history, this is big news already! I'm in CEST, if I wouldn't be sleeping right now I'd start up Burp, Charles or Fiddler to check.
Anyone who knows android dev knows this is a non issue. The permission they request doesn't even do anything in lollipop and later.
Sounds more like a bad dev than anything malicious.
What's the saying? Never attribute to malice with what can be explained by stupidity?
It's not a logical argument. It's more of a heuristic of human behavior, which tends to be right. Only rarely is there someone sitting behind a large desk making tent hands while laughing maniacally.
EDIT: On second thought, if it is a logical argument, it's a specific case of Occam's Razor. Which is more likely? Someone made a mistake, or there is a grand conspiracy?
Here's another fallacy: the fallacy of the excluded middle or the false dichotomy. There are many alternatives on the spectrum between "mistake" and "grand conspiracy".
I think that proverb is not for accuracy, but rather for gentle social relations. Otherwise, a more balanced approach would sound like, attribute a set of factors X to a phenomena Y in whatever way you think is most fit or empirically economical, or better sounding would be, "choose the middle way".
That way, you are neither under-trusting nor over-trusting.
> The permissions you see on the install screen are actually triggered by various permissions in the permission group. I've checked Ubers (there's a button on the web play store and you can see it in the manifest), and the only one from the Device and App History group they actually use is "GET_TASKS", or get a list of recently opened apps.
> Furthermore, on Lollipop this permission doesn't even do anything anymore. The relevant function in the framework has been changed and only returns instances of the caller's own app now. So Uber can see when you last used Uber. Big deal.
> Basically, this is a big fuss for nothing. Uber is not accessing your browser history, and if you're on Lollipop or above they can't access your app history either. They may do that on lower versions, but it's most likely to counter buggy behaviour on those older verions and not to spy on you.
I don't even understand why they need local access to figure this out. Poll the web API for last_login and be done with it. Surely they're already tracking and storing this kind of data on their end.
But StavrosK just claimed it doesn't work that way. He said that it will only tell you about instances of your own app, not others (such as Waze or Google Maps).
Does the app log in every time it starts up, or does it just have a stored access token that is simply supplied with future requests regardless of whether it's been 5 hours or 5 months?
Given what the uber app does when it starts up (show you a map of your locations, with data from a few uber cars moving across it), I'd bet the app essentially contacts the servers immediately when it starts.
The only this would get them is "how many times did a user try to get an uber without data connectivity" ...
Contacting servers is one thing, logging in is another. No authentication conversation needs to occur if the auth model is based on access tokens like generic OAuth flow.
Doesn't uber have tight integration with other apps that could be running? e.g. Google maps?
I assume the handoff from Google Maps doesn't require any kind of check to running apps from Uber, but I am curious if it is something along these lines.
It does. The main reason I ended up uninstalling uber was because I didn't like it polluting my directions searches with adverts which didn't tell me anything I couldn't already have gotten from the driving directions
First, you're making a network call anyway, because that's what apps do, so the data is implicit. You simply group by user id and subtract the timestamps of the requests.
But let's say for some reason, you can't collect app-open timestamps. What could you possibly want to do with it locally? Say, "Hey it's been x days since you last used me. Thanks for coming back!"? These are stats you want in aggregate, which means sending the data back to the servers for actual data analysis. You're not going to do that analysis -- or any analysis -- on the device, since there's nothing to compare to.
Yes, but if the data of when the app was last opened is needed to make more network calls, or to just show the user something in general, you're looking at a network call with round trip latency and a success rate <100%, vs. a device call that takes <1ms and succeeds every time.
Put the last opened time on the initial authorization response.
We could go round and round like this. Give me a concrete use case, because for the life of me I can't come up with one that isn't simply superfluous chrome.
That's what I'm thinking. Who has competitors installed, and do they use them. Also, it does have the right amount of creep to be a plausible Uber tactic.
I don't really understand the point of having fine-grained permissions (like READ_CONTACTS), when the user only sees broader permission groups. Can someone shed light on this?
"Simplified Permissions" is a relatively new feature of the Play Store and only gives you general permission categories. It was probably changed from the older specific permissions to make it less complex for people who didn't care as much.
Note that PackageInstaller still shows all permissions, which is used when clicking on an apk or using a 3rd party app store (like F-Droid). Due to backwards compatibility, this can't be changed easily at the OS level.
It wasn't always this way. The individual permissions used to be displayed to the user directly; newer releases of the Play Store have "streamlined" this permissions prompt so that users see general permissions "groups", and some permissions (such as INTERNET) are considered "not dangerous", requiring a click on the "See all permissions" button to view everything the app requests.
I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates.
Then they threw the whole system out with Android 6.0, moving to a much more sane flow for everyone involved, where the user is able to grant or deny individual permissions at runtime.
Yeah, I'm afraid that in Uber's case this is what you must assume. Normally I don't default to such a state, I honestly feel that most times it's just incompetence within an organization, but in Uber's case they have been a bad actor for a long time now so they just can't be trusted.
Uber us quite literally a supervillain! They've done almost every despicable thing in the tech industry.
Sabotage, illegal practices etc al. That's why this is actually big on HN.
With uber, shoot first then ask questions later!
> I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates.
Because the way to fix "apps can demand a laundry list of permissions and users can only take it or leave it" is to sweep it under the rug?
A sane way to do it would be the way browsers deal with location data: "App [appname] is requesting permission to access [resource]. Allow always / allow / deny / deny always?"
Kind of, but you still get the situation where an app wants to get your IMEI to identify the device, but is forced to ask for permission to 'phone', which the user promptly denies because that also allows the app to make phone calls.
Lots of apps use IMEI as a unique device identifier on Android. A practice that is discouraged by Google.
Anyway, since 6.0, developers should find a different way to udid. One alternative is Advertising ID which doesn't require any special permissions but is resettable by the user (though not easily found in the system's settings)
Whoever is in charge of the permission system is absolutely nuts. Or it's designed by the committee from hell. Those are the only reasons I can think of. No one sane would create this.
They actually wanted to "simplify" the permissions system and let the user have more control/understanding. You could argue they've done the first... at the expense of everything else. Half of it seems to have been introduced so "it bugs you less", which is not the point, I want to be bugged (by default) so I know what applications are actually doing. If users wants to "not be bugged" let them manually set it, don't make it default.
I've meant to write a post titled "Android 6 permissions: Still pants" after buying a Nexus 5X and being happy with the phone/camera but utterly disappointed with the "revamped" permission systems:
- Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose...
- Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict?
- You get an Internet, you get an Internet, every application gets an Internet. Because every application needs Internet right? It's not like I'd maybe want to install an application to manipulate a specific file type right now but don't want it connecting all over the net right? Maybe I don't have time to verify it's not nefarious. Maybe I just want control over what applications can actually phone home from my device?
- "Runtime permissions" is hit and miss. Some applications ask and then respect the answer. Others will just pop up the dialog over and over and over again until you accept it... which was not the point.
- READ_PHONE_STATE is still terrible. It's used by app/games to pause tasks when the user gets a phone call but... also gives away the number that's calling you! Of course, nearly every application then requests this. I don't get it, it's yet another obvious use case ("Let the application know the user is busy without leaking any data") that seems to have been glossed over. I thought by this point they'd have a proper IS_USER_BUSY permission that tells applications that you're in a phone call/whatever but doesn't leak any of your personal data *whatsoever".
At this point my next phone will be an iPhone/iOS, even though I don't particularly like them as at least security/sane permissions seems to mean something over there...
>Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose...
Does iOS have separate permissions for the different location resolutions or distinguish reading contacts from writing contacts?
> Does iOS have separate permissions for the different location resolutions
No, and why should it? I'm a technical user and I'm not even sure what the different resolutions are. What is important is to know when an application is asking for location data. iOS permissions for location are a) Never b) Always c) While using. Those make complete sense to even normal users.
Personally I wish iOS did have more fine grained permissions. I agree with you on location but I'd really like
1) Has permission to read your contacts
2) You can access an OS level contact screen to choose a contact but the app can't read the list of all contacts
3) Has permission to write to contacts (remember when facebook changed contact to have a facebook email address? Would prefer no permission)
Photos. Currently it's all or nothing. I'd prefer
1) can write new photos
2) can read old photos
Taking a photos right now is "can access camera" where as I'd prefer no camera access for most non-camera apps (facebook) and just a way to launch a system camera. I don't want apps to have the ability to keep the camera/mic on without my knowledge but "can access camera" = can use constantly without my knowledge while app is running.
Yes I know I can get around some this by doing it manually (don't give app camera permission, swap to built in phone, take picture, do give permission see 100% of my photos, hope they aren't uploading my private photos, choose photo I just took).
It's not enough IMO especially in this age of the revealtion of all the apps that spy
> 1) Has permission to read your contacts 2) You can access an OS level contact screen to choose a contact but the app can't read the list of all contacts 3) Has permission to write to contacts (remember when facebook changed contact to have a facebook email address? Would prefer no permission)
I think 2 can be integrated into no permission passing some sort of Intent to the iOS address book framework.
Similarly, permission to read photos on a one off basis can be integrated into no permission. The user should get sent to Photos app and the photos app could ask them whether the user would like to share a particular photo or a particular group of photos with the app that sent them there and with the user's permission the iOS system app can pass the data back to the requesting app.
Sort of like what you said with
> Taking a photos right now is "can access camera" where as I'd prefer no camera access for most non-camera apps (facebook) and just a way to launch a system camera. I don't want apps to have the ability to keep the camera/mic on without my knowledge but "can access camera" = can use constantly without my knowledge while app is running.
Yes, I absolutely agree. I'd go as far as to say even Instagram doesn't need camera permission.
>>- Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict?
I've configured security for a large variety of systems and I've never heard of a write-only permission. Read-only is often seen as a lesser right than read-write.
I'm sure you've heard of the UNIX sticky bit, which is used so that anyone can write a new file to `/tmp`, but without being able to access other files in the same directory. I can certainly imagine the same implementation for contacts (create new contact, see only contacts you have created) and texts (create new text, see only texts you have created).
On the internet permission - its a difficult business decision for Google to allow users to restrict the Internet permission. If they did, every ad-supported app would overnight become an ad-free app.
On the other hand: Everything can now steal my data "just" so adverts can be shown. Really?!
To me that's more outrageous than the original points I listed. My device and my data are left permanently insecure, all to protect their adverts. Even though I purposefully don't use applications with in-built advertising (because they can't be trusted with permissions), I can't easily turn this off.
This really makes my phone suddenly feel like "A rented device who's main purpose is to deliver advertisements to me" instead of "Owned device that helps me managed my life and communicate".
> its a difficult business decision for Google
It's a really easy business decision: User security, user privacy and user control are king. If each application wants to tie "functionality working" along with "internet access" and "advert was displayed" than each application can implement that for themselves. It's not hard.
That this is all baked into the actual OS instead with no (easy/toggle) method of user override is nuts.
That's what happens when conflicting tasks are left to the same management/company. Google's business model is not to make a secure OS or protect your privacy, it is to sell your eyeballs and data to advertisers. Any conflict between these views will usually resolve, maliciously or otherwise, toward advertising. Why do you think AppOps was removed?
I am sure there are people at Google who are tearing their hair, screaming about these issues. But management wants more money, not security or privacy.
As long as people vote with their wallet and buy Google products, they are supporting this. Yes, "I just don't care" is implicit support.
> "A rented device who's main purpose is to deliver advertisements to me"
You don't own these devices as long as someone else has root. This kind of crap is evidence that we are loosing the War On General Purpose Computation. A lot of people are scared of the power of a general purpose computer in the hands of the general public. Computers (especially internetworked computers) allow people to see throw scams, remove artificial scarcity, and work past propaganda. When middlemen feel their power is under attack, they tend to lash out in stupid ways to counterattack the perceived threat and reestablish their position.
In the end, the general purpose computer must be made back into an appliance, and the internet back into something closer to cable TV. I don't blame the average person for falling for this scam, as they are often ignorant of the underlying technology. However, a lot of people that really should know better have been distracted with shiny baubles and keep buying into these increasingly locked-down walled gardens, when they should be setting an example and working to educate others so they have the information they need when they vote with their wallet.
"By limiting access to resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data if an attacker successfully exploits security holes in your app or the frameworks it is linked against."
As such, from the developer's perspective the ideal permissions system should actually be as fine grained as possible to let the developers minimize the exposure of their apps. Android's permissions system was probably designed from this point of view.
Let's be cynical but real here, how many developers care or are even security aware? Here on HN, maybe most are, but out there, most people don't really have a clue or care about the user's data. As long as there is some revenue, all is "well".
This is why such things should be enforced in the OS, with a strict security model, and such shady permission overreach should be frowned upon.
That's because the permission model is back compatible.
Instead of creating a new 'access contact permission', the permissions are now bundled automatically.
That way the same manifest (where you declare a bunch of things about your app, including its permissions) can be used for both old and new devices.
As far as the manifest is concerned, it would have been easy to automatically generate the old permission list from a new permission list like {Contacts, Calendars, ...} but you would also have to create a new library to translate these new permissions to the old ones in the code (since old OS versions still only understand the permissions that existed with them) ...
It is probably easier to just keep the old permissions.
Sure on Lollipop it doesn't work anymore but they could be trying to get some of this information from phones on KitKat and below, which are a solid chunk of the market.
I made the comment on Reddit. Have never even used Uber, just a developer from Belgium. This is a question I've had this question many times before, and Android permissions are just a mess in general. The permission grouping has scared many people since it's introduction.
But once it's granted, the app can auto-update in the future and use more of that permission set.
I don't think I've changed my settings from the default and for me at least (Nexus 5, Lollipop) if an app has the same permissions set, it will update automatically, if it requests more it will prompt me to agree.
So even if the use of the permissions is innocuous now, it's bad news for the future to grant it.
Not OP but I found Lollipop pretty laggy and that it didn't add much I wanted, most of Google's updates come via Play now anyway. So also no reason to upgrade to Marshmallow either.
And (more relevant to the discussion), you can actually disable access to individual permissions regardless of what the app requires (though on apps compiled against older sdks there's no guarantee that they won't crash, but I found that it's not an issue in practice and most apps work just fine even if you disable access to things they supposedly require).
Multiple comments here parroting the "this is a non-issue on Lollipop or later" defense. Per Android's own statistics [1], that leaves 60% of users vulnerable to excessive permissions.
To be fair, there is zero ability (outside of undocumented and forbidden private APIs) for an iOS app to even request access to browsing history, bookmarks, or app history.
Actually that's backwards. Android moved to the new permission system (fewer perm groups, runtime user permission) to be more like iOS. It used to be that all permissions were granted at install time, which made apps much more likely to ask for onerous permissions because the user is unlikely to read the list or turn back.
It's likely they don't try this on iOS because iOS simply doesn't have the APIs to do this under any permission. It's a philosophical platform difference about what the user should be able to allow apps to do.
And what intent are you implying? Is it not possible that they request these permissions to improve the functionality of the application, and do not in fact actively spy on their users?
This permission should just simply not exist. I had two games and an another app. The browsing history was, in this case, used for targetting ads. I did not need the apps and uninstalled the apps (it was around 2 years ago, on previous version of Android I think).
The apps on Android should be sandboxed and not be given this kind of permissions, that's all.
Well, browsing history sounds very helpful in order to create another browser and that's pretty much it.
The unfortunate thing is that it is bundled in the same group as 'running apps'.
I guess it is because Android's PMs wanted to limit the number of permissions groups but it means that many apps have to request it simply because they need GET_TASKS for old devices.
256 comments
[ 3.3 ms ] story [ 250 ms ] threadI use two phones, but I have both apps on both.
And then of course they have their twitter phone, and their facebook phone and...
Just forwarded to some friends, they are uninstalling the rogue app as I type this!
First : sadly most users (and I really mean most) don't even glance at the permission screen.
It makes it hard for us Android devs to push back against the product teams when they want to add a crazy feature needing a ton of permissions (I still do though and the fact that it breaks auto updates at least is a good argument... ).
The weird part of the permission system is that we have to transition from a 'designed by & for engineers system where there were a tons of different permissions that no users ever read to a granular system where you only need to ask user's permission in order to access private data.
IMO the platform is definitely moving in the right direction (if only because it apes the other platforms approach).
They were lucky they didn't try the beta version of the new forthcoming uber app - that version wants access to the phones of all your friends, family, neighbours, your postman, the sister of the locksmith that helped you get the spare key last year, and the chap you met on the train to work last week called Brian. Still, go uber!
other than that, i could not make these new permissions to trigger.
What we desperately need is a UL for privacy. Just like UL tests electronics, we need a lab to test these apps for what data they access and how they make use of that data. Then assign a score so consumers can chose not to use services that request unnecessary permissions and misuse your data.
Look at how popular adblock's becoming.
If you treat a smartphone as a normal computer, you would expect to be able to use a service such as Uber by means of a modern web browser providing a sandbox for their web application, like you do on Linux, Mac OS X, or Windows. Installing someone's stand-alone software only to access an on-line service would probably seem invasive and absurd.
Broadly speaking, on a smartphone people probably accept this because of the trade-off. Apple and Google keep your mobile computer stable, fast, and free from viruses and malware by managing your operating system and vetting the software you can install through their app-stores. For a lot of people this trade-off seems preferable to an alternative.
I can't find a page from the official docs from my phone, but there's a list of permissions on Stack Exchange: http://android.stackexchange.com/a/38389/150855
Just say no to an Uber install, even with a throwaway (TOS-violating) Google account.
It's possible that these permissions are used in some obscure place in the app. With the new permissions system, you can progressively request permissions when you need them, so it's possible it will request these at some point in the future, but the app seems to run OK without them.
I also disabled access to contacts, which the app does request for some reason.
There's a standard intent to select a contact for purposes like that, and then the app only gets access to the information of that contact. Apps requesting access to contacts get all contacts.
They request 'running apps' only from this particular subgroup. Notice the wording on the original screenshot: 'one or more of'.
TLDR they don't request browsing history, the Android permissions screen on update is confusing
EDIT: There's another comment in the thread that indicates that this retrieve running apps permission actually doesn't do anything on Lollipop+: it just returns the app's own windows. Which would explain why it was moved to the "Other" category.
Frankly, a vast majority (99.99%+) don't care.
One time bookmark import is a thing I suppose, but that's different than gaining permanent access once granted.
What's the saying? Never attribute to malice with what can be explained by stupidity?
Hanlon's razor
EDIT: On second thought, if it is a logical argument, it's a specific case of Occam's Razor. Which is more likely? Someone made a mistake, or there is a grand conspiracy?
- a mistake where misaligned incentives are against fixing it
- a questionable decision exacerbated by a mistake
- malice on the part of an external actor plus internal incompetence (essentially all data breaches)
That way, you are neither under-trusting nor over-trusting.
> The permissions you see on the install screen are actually triggered by various permissions in the permission group. I've checked Ubers (there's a button on the web play store and you can see it in the manifest), and the only one from the Device and App History group they actually use is "GET_TASKS", or get a list of recently opened apps.
> Furthermore, on Lollipop this permission doesn't even do anything anymore. The relevant function in the framework has been changed and only returns instances of the caller's own app now. So Uber can see when you last used Uber. Big deal.
> Basically, this is a big fuss for nothing. Uber is not accessing your browser history, and if you're on Lollipop or above they can't access your app history either. They may do that on lower versions, but it's most likely to counter buggy behaviour on those older verions and not to spy on you.
Need to find out when you last opened the app? "Get running apps"...?
The only this would get them is "how many times did a user try to get an uber without data connectivity" ...
I assume the handoff from Google Maps doesn't require any kind of check to running apps from Uber, but I am curious if it is something along these lines.
But let's say for some reason, you can't collect app-open timestamps. What could you possibly want to do with it locally? Say, "Hey it's been x days since you last used me. Thanks for coming back!"? These are stats you want in aggregate, which means sending the data back to the servers for actual data analysis. You're not going to do that analysis -- or any analysis -- on the device, since there's nothing to compare to.
We could go round and round like this. Give me a concrete use case, because for the life of me I can't come up with one that isn't simply superfluous chrome.
To me, it's pretty obvious they want to find out if you opened the Lyft app recently.
I don't really understand the point of having fine-grained permissions (like READ_CONTACTS), when the user only sees broader permission groups. Can someone shed light on this?
I imagine it's because Google recognized the general insanity of the system, and presenting fewer "scary" permissions improved conversion rates.
Then they threw the whole system out with Android 6.0, moving to a much more sane flow for everyone involved, where the user is able to grant or deny individual permissions at runtime.
> leave system broken but hide UI so nobody cares.
hopefully, it is just incompetence, not evil.
I won't be using Uber, ever.
to start... theres more
Because the way to fix "apps can demand a laundry list of permissions and users can only take it or leave it" is to sweep it under the rug?
A sane way to do it would be the way browsers deal with location data: "App [appname] is requesting permission to access [resource]. Allow always / allow / deny / deny always?"
http://developer.android.com/google/play-services/id.html
Whoever is in charge of the permission system is absolutely nuts. Or it's designed by the committee from hell. Those are the only reasons I can think of. No one sane would create this.
They actually wanted to "simplify" the permissions system and let the user have more control/understanding. You could argue they've done the first... at the expense of everything else. Half of it seems to have been introduced so "it bugs you less", which is not the point, I want to be bugged (by default) so I know what applications are actually doing. If users wants to "not be bugged" let them manually set it, don't make it default.
I've meant to write a post titled "Android 6 permissions: Still pants" after buying a Nexus 5X and being happy with the phone/camera but utterly disappointed with the "revamped" permission systems:
- Yes sure, because I granted an application "Coarse location data", just go ahead and automatically (WTF?) give it "Fine location data" permissions too, because hey, it's all just "location data" right? Not like I might have wanted to give it coarse and not fine on purpose...
- Want to write contacts? Here's reading too! Want to write texts? Here's reading too! Same as above really. Is the use-case of wanting an application to be able to add to my data (at my request) but never-ever read all my data really that hard to predict?
- You get an Internet, you get an Internet, every application gets an Internet. Because every application needs Internet right? It's not like I'd maybe want to install an application to manipulate a specific file type right now but don't want it connecting all over the net right? Maybe I don't have time to verify it's not nefarious. Maybe I just want control over what applications can actually phone home from my device?
- "Runtime permissions" is hit and miss. Some applications ask and then respect the answer. Others will just pop up the dialog over and over and over again until you accept it... which was not the point.
- READ_PHONE_STATE is still terrible. It's used by app/games to pause tasks when the user gets a phone call but... also gives away the number that's calling you! Of course, nearly every application then requests this. I don't get it, it's yet another obvious use case ("Let the application know the user is busy without leaking any data") that seems to have been glossed over. I thought by this point they'd have a proper IS_USER_BUSY permission that tells applications that you're in a phone call/whatever but doesn't leak any of your personal data *whatsoever".
At this point my next phone will be an iPhone/iOS, even though I don't particularly like them as at least security/sane permissions seems to mean something over there...
Does iOS have separate permissions for the different location resolutions or distinguish reading contacts from writing contacts?
No, and why should it? I'm a technical user and I'm not even sure what the different resolutions are. What is important is to know when an application is asking for location data. iOS permissions for location are a) Never b) Always c) While using. Those make complete sense to even normal users.
1) Has permission to read your contacts 2) You can access an OS level contact screen to choose a contact but the app can't read the list of all contacts 3) Has permission to write to contacts (remember when facebook changed contact to have a facebook email address? Would prefer no permission)
Photos. Currently it's all or nothing. I'd prefer
1) can write new photos 2) can read old photos
Taking a photos right now is "can access camera" where as I'd prefer no camera access for most non-camera apps (facebook) and just a way to launch a system camera. I don't want apps to have the ability to keep the camera/mic on without my knowledge but "can access camera" = can use constantly without my knowledge while app is running.
Yes I know I can get around some this by doing it manually (don't give app camera permission, swap to built in phone, take picture, do give permission see 100% of my photos, hope they aren't uploading my private photos, choose photo I just took).
It's not enough IMO especially in this age of the revealtion of all the apps that spy
I think 2 can be integrated into no permission passing some sort of Intent to the iOS address book framework.
Similarly, permission to read photos on a one off basis can be integrated into no permission. The user should get sent to Photos app and the photos app could ask them whether the user would like to share a particular photo or a particular group of photos with the app that sent them there and with the user's permission the iOS system app can pass the data back to the requesting app.
Sort of like what you said with
> Taking a photos right now is "can access camera" where as I'd prefer no camera access for most non-camera apps (facebook) and just a way to launch a system camera. I don't want apps to have the ability to keep the camera/mic on without my knowledge but "can access camera" = can use constantly without my knowledge while app is running.
Yes, I absolutely agree. I'd go as far as to say even Instagram doesn't need camera permission.
I've configured security for a large variety of systems and I've never heard of a write-only permission. Read-only is often seen as a lesser right than read-write.
On the other hand: Everything can now steal my data "just" so adverts can be shown. Really?!
To me that's more outrageous than the original points I listed. My device and my data are left permanently insecure, all to protect their adverts. Even though I purposefully don't use applications with in-built advertising (because they can't be trusted with permissions), I can't easily turn this off.
This really makes my phone suddenly feel like "A rented device who's main purpose is to deliver advertisements to me" instead of "Owned device that helps me managed my life and communicate".
> its a difficult business decision for Google
It's a really easy business decision: User security, user privacy and user control are king. If each application wants to tie "functionality working" along with "internet access" and "advert was displayed" than each application can implement that for themselves. It's not hard.
That this is all baked into the actual OS instead with no (easy/toggle) method of user override is nuts.
I am sure there are people at Google who are tearing their hair, screaming about these issues. But management wants more money, not security or privacy.
As long as people vote with their wallet and buy Google products, they are supporting this. Yes, "I just don't care" is implicit support.
You don't own these devices as long as someone else has root. This kind of crap is evidence that we are loosing the War On General Purpose Computation. A lot of people are scared of the power of a general purpose computer in the hands of the general public. Computers (especially internetworked computers) allow people to see throw scams, remove artificial scarcity, and work past propaganda. When middlemen feel their power is under attack, they tend to lash out in stupid ways to counterattack the perceived threat and reestablish their position.
In the end, the general purpose computer must be made back into an appliance, and the internet back into something closer to cable TV. I don't blame the average person for falling for this scam, as they are often ignorant of the underlying technology. However, a lot of people that really should know better have been distracted with shiny baubles and keep buying into these increasingly locked-down walled gardens, when they should be setting an example and working to educate others so they have the information they need when they vote with their wallet.
"By limiting access to resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data if an attacker successfully exploits security holes in your app or the frameworks it is linked against."
As such, from the developer's perspective the ideal permissions system should actually be as fine grained as possible to let the developers minimize the exposure of their apps. Android's permissions system was probably designed from this point of view.
This is why such things should be enforced in the OS, with a strict security model, and such shady permission overreach should be frowned upon.
Instead of creating a new 'access contact permission', the permissions are now bundled automatically.
That way the same manifest (where you declare a bunch of things about your app, including its permissions) can be used for both old and new devices.
As far as the manifest is concerned, it would have been easy to automatically generate the old permission list from a new permission list like {Contacts, Calendars, ...} but you would also have to create a new library to translate these new permissions to the old ones in the code (since old OS versions still only understand the permissions that existed with them) ...
It is probably easier to just keep the old permissions.
IIRC, I needed to identify a couple of states :
- when the user is on the lockscreen.
- when the user is in another app.
- when the user is in our app.
- when the screen is off.
There were business reason behind this for a complex feature, nothing to do with the user's data.
The Android team does not want android devs to access to their own app UI state because 'the business logic should not have to depend on that' ...
Fair enough in theory but in practice there are a couple of times when you just need it.
For example even the Chromecast sample uses a ugly hack to access this piece of information (put a timer behind start/stop activity events).
I remember that a coworker had to revamp this piece of code recently for Marshmallow but I don't remember the details.
Google finally has a working permission model with Marshmallow : protect the private data behind popups, everything else is fair game.
It is not perfect by any means since users still tend to click yes on any popup ... but that's the best we can do IMO.
I don't think I've changed my settings from the default and for me at least (Nexus 5, Lollipop) if an app has the same permissions set, it will update automatically, if it requests more it will prompt me to agree.
So even if the use of the permissions is innocuous now, it's bad news for the future to grant it.
If you have a nexus 5 why aren't you on marshmallow?
IIRC it even has some memory leaks ...
It is MUCH better in Marshmallow, so it is definitely worth upgrading because that's another thing where you just need to update the system.
-iOS App Permissions https://www.uber.com/legal/other/ios-permissions/
-Android App Permissions https://www.uber.com/legal/other/android-permissions/
Question: http://i.imgur.com/K1mAtiH.png
Scripted reply that didn't answer question: http://i.imgur.com/m9sWJZR.png
Also, as mentioned in the post, https://www.uber.com/legal/other/android-permissions/ doesn't mention the new permissions.
1: http://developer.android.com/about/dashboards/index.html
And google is no less: https://www.privateinternetaccess.com/blog/2015/06/google-ch...
Uber doesn't try to pull anything like this on iOS.
It's likely they don't try this on iOS because iOS simply doesn't have the APIs to do this under any permission. It's a philosophical platform difference about what the user should be able to allow apps to do.
The apps on Android should be sandboxed and not be given this kind of permissions, that's all.
The unfortunate thing is that it is bundled in the same group as 'running apps'.
I guess it is because Android's PMs wanted to limit the number of permissions groups but it means that many apps have to request it simply because they need GET_TASKS for old devices.
This is one reason why i use Firefox on Android (another being the read-it-later feature, and option to add other search engines easily).