Since the website is currently down, this person reverse-engineered Uber's Android app and discovered it has code that will "call home" aka send data back to Uber with your:
- SMS list [edit: see other comments re SMSLog, SMS permission is not currently requested]
- call history
- wifi connections
- GPS location
- every type of device fingerprint possible (device IDs)
It also checks if you're phone is rooted/jailbroken and if it's vulnerable to Heartbleed... which it also calls home.
From my understanding, which the author somehow missed, is that it is using http://www.inauth.com SDK which provides 'malware detection'. This SDK is popular in the 'mobile finance industry' and the banking sector. Also notably one of the founders is former DHS/FBI.
Two possible theories: it is being used for fraud detection and/or an intelligence gathering tool.
- PhoneCall (call duration, called at, from number, phone call type, to number)
- SMS (from number, service number, sms at, sms type, to number)
- TelephonyInfo (cell tower id, cell tower latitude, cell tower longitude, imei, iso country code, local area code, meid, mobile country code, mobile network code, network name, network type, phone type, sim serial number, sim state, subscriber id)
- Root Check (root staus code, root status reason code, root version, sig file version)
- Malware Info (algorithm confidence, app list, found malware, malware sdk version, package list, reason code, service list, sigfile version)
Or, put differently, I really don't see any reason for Google not to immediately remove this app from the store permanently and ban whatever developer uploaded it. There should probably be legal action.
Edit: I've augmented the various types of data retrieved (ie: there is capability in the source to read, save and transmit this data) from the inauth framework sources.
Now hold on a sec -- I'll buy that the Uber app appears to have a library compiled into it that could do all of that, which is worrisome enough, but as far as I can see, that blog provides no evidence that Uber is actually phoning home. Anybody up for doing a tcpdump?
Even before this disclosure, the Uber app required a nauseatingly long list of permissions.
I wiped an old Android phone, configured it with a dummy Gmail account, and then installed the Uber app there.
So it's a dedicated Uber-only phone with no contacts, no personal data, powered off until I need a ride. It's a giant pain in the ass.
Kinda happy to see this article, it validates my paranoia in some small way.
Now the real question is, why use Uber at all if they're this cavalier with my personal information? Good question, I may not need to power-on my Uber-only phone any more.
Nothing provided by the OP shows what is actually being sent. The linked text document of the code only shows the creation of an instance of the SMSLog class, which itself is defined in another class (not provided or discussed by OP). This is the same for most of the scary bits, which is unfortunate as seeing the code itself (or the MITM'ing the app and seeing the data) would be very interesting.
Yikes, uninstalling now. I haven't used Uber for a while, but it's been useful to have just in case Lyft is +200% and Sidecar doesn't have anything available... Now it's not even worth it to have the software on my phone. Thanks for the summary and link to the decompiled source code.
This is not something new. I've had LinkedIn and Facebook do this with my personal contacts.
I use disposable emails for every site (www.spamgourmet.com). After installing LinkedIn and Facebook Android apps they started recommending adding old coworkers that I have 0 mutual friends / connections with.
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.
- 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.
> 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.
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.
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."
Recall that PUT / DELETE aren’t official HTTP requests, rather extensions implemented via WebDav. Modern applications don’t bother with these requests since its easier / more secure to perform those same actions with a server side language.
Apparently the author has not ever heard of REST. I'm a little shocked by that.
Yeah I noticed that as well, it makes me wonder about the rest of his technical assertions that I'm less able to judge.
Just in case anyone was wondering here's the HTTP 1.1 rfc: https://www.ietf.org/rfc/rfc2616.txt A simple search will show that it does include PUT and DELETE.
Uber says the camera permission is required to take a snapshot of your credit card. The phone call permission is required to call your driver. The get accounts permission is required to enable single sign-in (Google Sign-In, Google Wallet).
The Uber app doesn't, according to the gironsec.com post, request Android's READ_SMS permission, so pointing to a "sendSMSLog" code excerpt by itself doesn't mean much. And so on.
As <andymcsherry> pointed out elsewhere in this thread, there's a "perfectly reasonable explanation for almost all of these permissions" except WRITE_SETTINGS. Uber says in its Android permissions post that: "We use this permission to save data and cache mapping vectors."
It seems as though it would have been useful for the author of the gironsec.com post to read what Uber has to say -- or, better yet, contact the company before posting a critique. If Uber PR can't cough up a good explanation, it makes the final critique more powerful.
As an Android developer, I don't want to have to ask for as many permissions as I do. I have 1 button buried on 1 screen that allows you to call customer support. 99.9% of users never click the button. However, I have to make every single customer accept the CALL_PHONE permission.
There are a bunch of permissions required for basics like autocompleting the users email for login, or checking the network state so you can adjust the app behavior based on connectivity.
Not to mention the incentives are all wrong in the Play store. Changing permissions murders your update rate, so you want to do it as little as possible. So when you are forced to add a permission, you grab a bunch of extra ones you 'plan' to use later to avoid having to get over that hump again. It's really awful.
A LOT of this stuff is pretty easily explainable. They want access to SMS and phone calls because the Uber app uses those things.
Camera doesn't seem terribly implausible. IT could be an incoming feature that allows you to take a photo of where you are so that your driver can find you more easily.
The WiFi stuff is probably related to location.
edit: as pointed out below, this is so that you can take a photo of your credit card so you don't have to type it in.
This seems like "hydrogen hydroxide KILLS" scare mongering.
> I don't see the big OMG SECRET MALWARE scariness.
This is the definition of malware:
n. Malicious computer software that interferes with normal computer functions or sends personal data about the user to unauthorized parties over the Internet.
I'm all for people taking responsibility for their privacy but this is basically what you are saying to people:
"Hey you accepted that list of permissions (or Terms of Service)! What? you didn't expect that your Taxi app is not going to retrieve and store your call logs and other personal information? How silly of you."
This rational among tech people is why there is zero privacy. The myth of consumer choice in the matter. The average person doesn't reasonably expect Uber to be mining this information about them. Merely assuming it is a function of the application.
We in technology know that they can but the average user? Who has responsibility here then? Noone? Uber has an ethical responsibility not to actually abuse this trust from their users IMO. Which is why the inclusion of this library deserves scrutiny.
There's a general trend of mobile apps that ask for everything: camera, microphone, sensors, access to local files, WiFi, etc. These are apps (like Uber) with no good reason to need access to such things.
In most cases I can think of no good reason for this except either a desire to surveil customers for indirect monetization, or participation in government or private surveillance grid efforts.
I've got Lyft on my Android phone, but not Uber. I look at its permissions and the only dubious looking one is "access to take photos / videos." Is this perhaps for signing up as a driver and photographing yourself and your car? I don't see anything else that doesn't make sense.
It's a common practice to do this "just in case" you need the permissions later on. When first installing an app users are likely to hit Ok to whatever, but when permissions change on an update they are hit with another screen that tells them the specific thing you are now asking permissions for.
It's worth noting that the quick summation of Android permissions given to users isn't quite accurate. There are a limited number of permissions, and many of them (such as SD card read/write access) are very broad. So the summary Google uses is a lay description of the worst possible thing an app could do with those permissions, which may be much more invasive than what it actually does.
Yeah, my T-Mobile account app wants to know about my Photos and wifi status. Of course, after that my automatic photo upload stopped working and I have to sttart Google voice manually because they want me to use a T-Mobile app for international calling via Wifi and buy a new SIM card for the privilege. T-Mobile talks a big game but treats its customers little better than its competitors - I may go back to MetroPCS but I think T-Mobile bought them already :-/
Checking for root access is actually really useful from a developer standpoint. I've seen countless bugs on Crashlytics that are 100% on rooted devices which often is because the user has xposed or some other system level hacks that break my apps. This allows us developers to spend more time focusing on real bugs instead of chasing down these rooted device problems.
Yeah, when I posted it, I realized the title wasn't ideal - but figured the safe bet was to adhere to the "post with the author's published title" rule.
I've contacted Uber in Australia, and requested a copy of all personal data they have collected. This is my right under Australian law; it'll be interesting to see how they proceed.
One way to deal with this is to filter all outbound requests and not let the requests that you've identified as "phoning home" to complete. Then, you test the app, if it still works you can continue using it. If it doesn't, you find a different service or you consider re-adjusting your restrictions.
Outbound filtering can quickly highlight any app that tries to call home. Luckily, many apps continue working if you block those calls. YMMV.
Sadly, filtering is a privilege only rooted Android users may enjoy despite there being a perfectly functional iptables/ iptables6 instance on every phone.
The first thing I do after rooting is install a front- end to iptables and set it to whitelist mode. Any app that has a genuine need to access the internet can then be authorised; everything else is denied.
It frustrates me greatly that the ' common user' is denied this protection.
I do find it funny that despite all the other allegations, absolutely reprehensible business practices, and general malice they've put in the world that this is a surprise to anyone. I'm quite surprised that they still have so much business, but then again, morality isn't a one-size fits all sort of deal. What bothers me, may not bother other folks, or may seem as smart business tactics ( :sadface: ).
I don't see that Uber has permissions to my SMS, however, after going through the other list of granted permissions, I went to the settings and modified the permission and also enabled privacy guard for the app. You can go to Settings -> Apps -> (scroll down) tap on Modify - screenshot http://i.imgur.com/AVXLqgh.png
[+] [-] dmix|11 years ago|reply
Since the website is currently down, this person reverse-engineered Uber's Android app and discovered it has code that will "call home" aka send data back to Uber with your:
- SMS list [edit: see other comments re SMSLog, SMS permission is not currently requested] - call history - wifi connections - GPS location - every type of device fingerprint possible (device IDs)
It also checks if you're phone is rooted/jailbroken and if it's vulnerable to Heartbleed... which it also calls home.
From my understanding, which the author somehow missed, is that it is using http://www.inauth.com SDK which provides 'malware detection'. This SDK is popular in the 'mobile finance industry' and the banking sector. Also notably one of the founders is former DHS/FBI.
Two possible theories: it is being used for fraud detection and/or an intelligence gathering tool.
Edit: here is a copy of the decompiled source code http://www.gironsec.com/blog/wp-content/uploads/2014/11/InAu... note the name "package com.inauth.mme"
Edit #2: here is a screenshot of Uber's permission request https://i.imgur.com/4MmYrJH.png no SMS on the list
[+] [-] revelation|11 years ago|reply
- Accounts log (Email)
- App Activity (Name, PackageName, Process Number of activity, Processed id)
- App Data Usage (Cache size, code size, data size, name, package name)
- App Install (installed at, name, package name, unknown sources enabled, version code, version name)
- Battery (health, level, plugged, present, scale, status, technology, temperature, voltage)
- Device Info (board, brand, build version, cell number, device, device type, display, fingerprint, ip, mac address, manufacturer, model, os platform, product, sdk code, total disk space, unknown sources enabled)
- GPS (accuracy, altitude, latitude, longitude, provider, speed)
- MMS (from number, mms at, mmss type, service number, to number)
- NetData (bytes received, bytes sent, connection type, interface type)
- PhoneCall (call duration, called at, from number, phone call type, to number)
- SMS (from number, service number, sms at, sms type, to number)
- TelephonyInfo (cell tower id, cell tower latitude, cell tower longitude, imei, iso country code, local area code, meid, mobile country code, mobile network code, network name, network type, phone type, sim serial number, sim state, subscriber id)
- WifiConnection (bssid, ip, linkspeed, macaddr, networkid, rssi, ssid)
- WifiNeighbors (bssid, capabilities, frequency, level, ssid)
- Root Check (root staus code, root status reason code, root version, sig file version)
- Malware Info (algorithm confidence, app list, found malware, malware sdk version, package list, reason code, service list, sigfile version)
Or, put differently, I really don't see any reason for Google not to immediately remove this app from the store permanently and ban whatever developer uploaded it. There should probably be legal action.
Edit: I've augmented the various types of data retrieved (ie: there is capability in the source to read, save and transmit this data) from the inauth framework sources.
[+] [-] jpatokal|11 years ago|reply
[+] [-] panarky|11 years ago|reply
I wiped an old Android phone, configured it with a dummy Gmail account, and then installed the Uber app there.
So it's a dedicated Uber-only phone with no contacts, no personal data, powered off until I need a ride. It's a giant pain in the ass.
Kinda happy to see this article, it validates my paranoia in some small way.
Now the real question is, why use Uber at all if they're this cavalier with my personal information? Good question, I may not need to power-on my Uber-only phone any more.
[+] [-] tetrep|11 years ago|reply
Nothing provided by the OP shows what is actually being sent. The linked text document of the code only shows the creation of an instance of the SMSLog class, which itself is defined in another class (not provided or discussed by OP). This is the same for most of the scary bits, which is unfortunate as seeing the code itself (or the MITM'ing the app and seeing the data) would be very interesting.
[+] [-] brotchie|11 years ago|reply
It doesn't ask for permissions to access anything SMS related, or call history related.
I'm assuming they've included the entire InAuth SDK, but not used most of the functionality.
[+] [-] ericdykstra|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] wting|11 years ago|reply
I use disposable emails for every site (www.spamgourmet.com). After installing LinkedIn and Facebook Android apps they started recommending adding old coworkers that I have 0 mutual friends / connections with.
[+] [-] lotsofmangos|11 years ago|reply
[+] [-] andymcsherry|11 years ago|reply
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.
[+] [-] Aissen|11 years ago|reply
- 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.
[+] [-] MarkMc|11 years ago|reply
[+] [-] alec|11 years ago|reply
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.
[+] [-] revelation|11 years ago|reply
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.
[+] [-] lnanek2|11 years ago|reply
[+] [-] archon810|11 years ago|reply
https://m.uber.com/android-permissions
[+] [-] lsaferite|11 years ago|reply
Also, you can initiate the dialer without the CALL_PHONE permission, the user just has to hit the dial button.
[+] [-] andrewvc|11 years ago|reply
Apparently the author has not ever heard of REST. I'm a little shocked by that.
[+] [-] iolsantr|11 years ago|reply
Just in case anyone was wondering here's the HTTP 1.1 rfc: https://www.ietf.org/rfc/rfc2616.txt A simple search will show that it does include PUT and DELETE.
[+] [-] mcav|11 years ago|reply
[+] [-] sumnulu|11 years ago|reply
[+] [-] declan|11 years ago|reply
Here's what Uber says about its Android permissions -- the page isn't that difficult to find: https://m.uber.com/android-permissions
Uber says the camera permission is required to take a snapshot of your credit card. The phone call permission is required to call your driver. The get accounts permission is required to enable single sign-in (Google Sign-In, Google Wallet).
The Uber app doesn't, according to the gironsec.com post, request Android's READ_SMS permission, so pointing to a "sendSMSLog" code excerpt by itself doesn't mean much. And so on.
As <andymcsherry> pointed out elsewhere in this thread, there's a "perfectly reasonable explanation for almost all of these permissions" except WRITE_SETTINGS. Uber says in its Android permissions post that: "We use this permission to save data and cache mapping vectors."
It seems as though it would have been useful for the author of the gironsec.com post to read what Uber has to say -- or, better yet, contact the company before posting a critique. If Uber PR can't cough up a good explanation, it makes the final critique more powerful.
I've posted here on HN criticizing Uber before (https://news.ycombinator.com/item?id=8383854), but before rushing to judgment here let's check our facts first.
[+] [-] krschultz|11 years ago|reply
There are a bunch of permissions required for basics like autocompleting the users email for login, or checking the network state so you can adjust the app behavior based on connectivity.
Not to mention the incentives are all wrong in the Play store. Changing permissions murders your update rate, so you want to do it as little as possible. So when you are forced to add a permission, you grab a bunch of extra ones you 'plan' to use later to avoid having to get over that hump again. It's really awful.
[+] [-] driverdan|11 years ago|reply
[+] [-] blhack|11 years ago|reply
Camera doesn't seem terribly implausible. IT could be an incoming feature that allows you to take a photo of where you are so that your driver can find you more easily.
The WiFi stuff is probably related to location. edit: as pointed out below, this is so that you can take a photo of your credit card so you don't have to type it in.
This seems like "hydrogen hydroxide KILLS" scare mongering.
BTW, this is all available in the app permissions: https://lh3.googleusercontent.com/-FVPu6x-F5SM/VHUZgU47m-I/A...
I don't see the big OMG SECRET MALWARE scariness.
[+] [-] dmix|11 years ago|reply
This is the definition of malware:
n. Malicious computer software that interferes with normal computer functions or sends personal data about the user to unauthorized parties over the Internet.
I'm all for people taking responsibility for their privacy but this is basically what you are saying to people:
"Hey you accepted that list of permissions (or Terms of Service)! What? you didn't expect that your Taxi app is not going to retrieve and store your call logs and other personal information? How silly of you."
This rational among tech people is why there is zero privacy. The myth of consumer choice in the matter. The average person doesn't reasonably expect Uber to be mining this information about them. Merely assuming it is a function of the application.
We in technology know that they can but the average user? Who has responsibility here then? Noone? Uber has an ethical responsibility not to actually abuse this trust from their users IMO. Which is why the inclusion of this library deserves scrutiny.
[+] [-] 2xlbuds|11 years ago|reply
[+] [-] benigeri|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] api|11 years ago|reply
In most cases I can think of no good reason for this except either a desire to surveil customers for indirect monetization, or participation in government or private surveillance grid efforts.
I've got Lyft on my Android phone, but not Uber. I look at its permissions and the only dubious looking one is "access to take photos / videos." Is this perhaps for signing up as a driver and photographing yourself and your car? I don't see anything else that doesn't make sense.
[+] [-] rco8786|11 years ago|reply
[+] [-] alexbecker|11 years ago|reply
[+] [-] anigbrowl|11 years ago|reply
[+] [-] akanster|11 years ago|reply
[+] [-] georgeott|11 years ago|reply
[+] [-] guelo|11 years ago|reply
[+] [-] monort|11 years ago|reply
Does such sandbox exists?
[+] [-] makeramen|11 years ago|reply
[+] [-] dpiers|11 years ago|reply
[+] [-] dang|11 years ago|reply
[+] [-] uptown|11 years ago|reply
[+] [-] duncan_bayne|11 years ago|reply
[+] [-] click170|11 years ago|reply
Outbound filtering can quickly highlight any app that tries to call home. Luckily, many apps continue working if you block those calls. YMMV.
[+] [-] dingaling|11 years ago|reply
The first thing I do after rooting is install a front- end to iptables and set it to whitelist mode. Any app that has a genuine need to access the internet can then be authorised; everything else is denied.
It frustrates me greatly that the ' common user' is denied this protection.
[+] [-] msoad|11 years ago|reply
http://webcache.googleusercontent.com/search?q=cache:6rWGz01...
[+] [-] rubyn00bie|11 years ago|reply
I do find it funny that despite all the other allegations, absolutely reprehensible business practices, and general malice they've put in the world that this is a surprise to anyone. I'm quite surprised that they still have so much business, but then again, morality isn't a one-size fits all sort of deal. What bothers me, may not bother other folks, or may seem as smart business tactics ( :sadface: ).
To me, it's just more icing on the cake.
[+] [-] aikah|11 years ago|reply
I personally believe Uber app on android fits the definition of a malware.
[+] [-] zeus180|11 years ago|reply
[+] [-] wpnx|11 years ago|reply