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.
- 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.
Similar issues abound with the myriad of camera applications.
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.
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.
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'.
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.
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 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.
Also, you can initiate the dialer without the CALL_PHONE permission, the user just has to hit the dial button.