Hacker News new | comments | ask | show | jobs | submit login

There's perfectly reasonable explanation for almost all of these permissions, and there's nothing in this analysis that suggests they're doing otherwise. The only one that I couldn't think of was WRITE_SETTINGS

Permissions

ACCESS_COARSE_LOCATION & ACCESS_FINE_LOCATION: Fairly obvious, they need to figure out where to pick you up

ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE , INTERNET: They need to figure out if you have internet and use it

WAKE_LOCK: Keep the network running so you can get real-time updates about your driver

GET_ACCOUNTS, USE_CREDENTIALS, MANAGE_ACCOUNTS: For logging in with Google

CAMERA: You can take a picture of your credit card for easier entry

CALL_PHONE: So you can call your driver

MANAGE_ACCOUNTS: So they can add your uber account to your phone

READ_CONTACTS: Probably for inviting friends or splitting ride costs

READ_PHONE_STATE: Legacy analytics reasons

WRITE_EXTERNAL_STORAGE: Probably unnecessary, but they are probably just storing data

VIBRATE: For notifications

The rest are for push notifications

As far as the roottools, I know Crashlytics checks for root so they can provide that data in their console for crashes. It's a pretty useful thing to be able to weed crashes from rooted devices out. They usually make very little sense and violate the advertised behavior of the SDK.




So, let me disagree with a few of those:

- CAMERA: there's an intent for that, you don't need the permission, although it will require tapping the "take a photo" and "ok" buttons

- CALL_PHONE: ditto, although it will require tapping the dial button.

- READ_CONTACTS: again, there's an intent for that, allowing you to select only the contacts you want to share with the app.

- READ_PHONE_STATE: either they want to be compatible with a very old version of Android, or they want to uniquely identify your phone, permanently. They might also want to know who you're calling or who's calling you in real time

Regarding MANAGE_ACCOUNTS, etc: some apps do that, and it seems to be all the rage. Unless you have multiple apps sharing a common account, I don't see the point. It's just leaks all your configured accounts on the device.


Having implemented the first three: various manufacturers release dialer and contact apps that do not implement the Intent in the same way as the AOSP/Google apps. For example, the HTC Sense contacts application does not grant you the single-record permission when you select a contact via the ACTION_PICK_CONTACT intent, so your app will generate a permission error and you will not get the contact data without READ_CONTACTS.

Similar issues abound with the myriad of camera applications.


Interesting, how recent are those HTC Sense phones? Any pointers to such bugs? I agree it's a shame that it isn't implemented properly. It should be part of CTS.


The CTS isn't quite as comprehensive as it should be. I worked on a music player that replaced the stock music app for a while. At one point, we discovered it wasn't issuing some of the required intents. Went unnoticed for over a year.


You can't use sync adapters without using account manager. That's the primary reason for it, not for sharing credentials between apps.


Hum, are you sure you can't do without ? If not, it's quite a mistake of Google's part.


Side note: Wouldn't it be good if Google required all apps to explain why each permission is necessary, similar to this?


It would also be good if users could install the app but without approving the full set of permissions. Developers would have to catch an exception, but it's worth it. (Supposedly with one of the recent Android releases this feature was planned and made it to some users but Google quickly reverted.)


The system in iOS is still not enough because the app knows if you declined, so it can keep asking you ad-nauseam until you either accept or until you uninstall the app. For example Facebook's messenger asks for being able to show notifications every time you load the UI.

It would have been good if there was a way to lie to the app. For example if it wants access to your contacts, it could get a blank list.

Of course, it is much easier to not use such apps in the first place. Uber is not alone in doing this and personally I take it as a signal of how I'll be treated as a customer.


On rooted Android phones, there's XPrivacy, which can do just that--send fake data to an app.

https://github.com/M66B/XPrivacy


That's how Apple handles the iOS permission model, as I understand


iOS really has 3 levels of access for things like this.

For the most sensitive things like location, contacts and photos, it prompts for user permission.

There's a lower category for things like background processing, you declare to Apple that you want to use them, and they are enabled by default. Some of them can be disabled by the user after the fact.

Then, there's things like internet usage which there is no permission system for.


Because of iOS's sandboxing, it's really hard for apps to get info outside of their own "container" of sorts, so it doesn't matter much if they can access the Internet. Keyboards from third parties are an obvious exception to this, so these require explicit permission to access the Internet.


> so it doesn't matter much if they can access the Internet

Unless you have a limited cellular data allowance, or pay for data by actual usage. iOS allows you to disable cellular data for certain apps. It would be great if it could somehow figure out when I'm using a mi-fi when abroad, and treat that wifi access point as 'cellular'.


Android can be told to treat certain APs as limited usage, which means they're not used by apps that are set to WiFi only, or for which you've disabled mobile data.


> there's nothing in this analysis that suggests they're doing otherwise

The article included a decompiled code snippet showing it running methods like "sendMMSLog" and "sendPhoneCallLog", apparently logging a bunch of private data and sending it back to Uber.


No, it shows that there exists a method that calls a bunch of methods. However, as others have explained these methods appear to be from a library that's been loaded in wholesales, and it doesn't show that the method is ever called or that any data is ever transmitted.


The method is named sendMMSLog. The body of the method is not shown. Is it logging the messages sent to & from Uber? Or the messages you sent to your girlfriend. The difference between those two is massive.


This is like saying we should give everyone root access because there are legitimate situations where that is warranted and not misused.

I mean, I might trust my neighbor with the key to my apartment, but I'll still call the cops when he comes in and trashes the place.

Similarly, maybe there are valid reasons for Uber to have these permissions. That doesn't mean they can upload a dump of whatever data they can find to their servers.


There's a difference between checking if root access can be granted and gaining root access. If Uber were to use this access, the superuser app would prompt the user to approve it. The user would then have to grant permission.

There's no proof in this article that they are uploading this data to their servers, just speculation. The snippet of some methods he showed doesn't even make sense, because they don't ask for permissions for your SMS, MMS or other permissions required for these things.


That was a metaphore. Also, as you are certainly aware, Android apps don't ask for permissions through code, they request them in various metadata manifests.


You need READ_PHONE_STATE for the Android ID, so it is pretty common to include just to get a unique identifier for the device.


No, you don't. Android ID is stored in Settings.Secure and can be read without any permission. READ_PHONE_STATE allows the app to read the IMEI/ESN/MEID of the device.


According to Uber, WRITE_SETTINGS is used for "We use this permission to save data and cache mapping vectors, which helps power our app in 45+ countries and make Uber the world's most reliable ride."

https://m.uber.com/android-permissions


Can people really not be bothered to enter their CC number?

Also, you can initiate the dialer without the CALL_PHONE permission, the user just has to hit the dial button.


Why are you bothered that other people might prefer to snap a picture of their credit card rather than type the numbers? I've used Uber's CC scanning on their iOS app, and it works really well.


Because, with Android's silly all or nothing permissions, it means the Uber app want access to my camera which it doesn't really need.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: