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.
After all the recent scandals in Uber, how has Google not pushed for a complete overhaul of Uber's leadership already? It has become pretty clear the current leadership has some "issues".
Well I mean, is it actually causing any problems for Uber?
Uber has what's pretty close to a monopoly in what it offers, apart from a few cities in the US where Lyft also operates. I would say most people that user Uber are not interested in using the regular local taxi service.
I spoke to a Lyft/Uber driver today in NCY. He said that Uber's losing drivers every day here — about 5% (I don't know where he got those numbers from). He also mentioned that Uber are flat out lying about how much drivers earn, and in some months drivers that aren't on Uber's "favourites" list end up owing Uber for renting the gear instead of earning money.
This reputation is definitely damaging, and it's common knowledge here. Drivers bitch about it. They recommend Lyft.
I'm always very cautious of taking what opinion from HN (and others in 'tech') and extrapolating them out to the general population, so I read what you say (and my own opinion) with a grain of salt.
But like, Uber is in 230 cities around the world. Here in Australia I believe they added over 1000 new drivers over the past month. Here, Uber is the alternative. There is no Lyft or Sidecar - mainly because alternatives are too scared of legal action from government - ridesharing is essentially illegal here, but Uber plays the we're-waiting-for-the-law-to-catch-up card regardless.
I'm sure the turnover for Uber is high. I would expect that for that type of job, regardless of the apparent ethical makeup of the company's executives.
> 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
The original article is down, but do they somehow bypass the Android permission authorization process? Or the user still has to authorize the app to access all the resources?
They do need to ask for these permissions at install time. But as another user here pointed out, they do have legitimate reasons to ask for most of them to provide the functionality of the app.
The issue is that they're phoning all this information home, when the user might only be expecting it to be retrieved while the app is in use and only as needed.
Seriously? You mean, information that 1. Google makes available via API and 2. You agreed to when you installed the app is now means for Google to take legal action?
You're deluded. If you don't like this, stop using Android. I did.
That doesn't mean it's good for users or for users or for Android's reputation as an app ghetto. Some means of scoring apps down for needless permissions would be a good thing.
Yeah, it does suck that you need to install the app before you can rate it. I mean...I understand why they would do this in an attempt to limit review gaming but in this case I often have to install something if I want to give it a bad review. In reality, I just don't install it and move on.
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?
It may not be ok, but it's completely different, imo. If they're not using the libraries, they can change it and no big deal. If they are using the libraries and stealing all this information that doesn't belong to them, that feels criminal to me (or ought to be).
So...I'd love to know...are they really doing this?
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.
Beats the alternatives. Worlds better than any experience I've ever had with a taxi (and more importantly with trying to obtain one).
Android isn't perfect (case in point: it should support saying "yes I want to install the app, no it can't have the permissions it asked for"), but at least it isn't iOS; I'm not going to stick with a feature phone until someone comes up with the perfect smartphone OS. If someone comes up with a service better than Uber, I'll switch. (For instance, I do plan to try Lyft next time I'm in a city it supports, to see if the experience is better.)
You must live in an area with good to great taxi service.
There are areas where taxi service is so spotty as to be scary, were simply getting a cab is a huge pain (IE: called and ordered) and flagging one down is a non-starter. Even after calling in a cab, they often end up being no-shows (get a better fare en-route, etc)... it is scary when you can't get dependable public transit home from a location (stuck alone, outside, waiting for sometimes hours).
Uber started and initially flourished in areas were taxi service was insanely poor due to bad regulation and/or corruption. Uber was basically a response to the godawful taxi situation in SF.
I know I feel far more comfortable when the people I care about are able to get an Uber/Lyft/(similar) service.
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.
It takes all of a minute to download the APK from the store and check for yourself. I just did and SMSLog is present in it and does grab all your SMS metadata starting with the most recent ones, saving for each message:
- checked at (timestamp when read?), to number, service number, sms at (timestamp received?), sms type
Now I can't tell you if it does actually transmit that data, but the remainder of the code looks for the world like it. In the end, of course, it doesn't actually matter. That's like arguing if malware that lies dormant actually exists.
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.
It's not always them knowing your contact list. Sometimes (most times) this will be powered from the other side, as in someone you know has uploaded their contact list and it's matched you as you registered
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.
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.
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.
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.
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."
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.
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.
> "... it makes me wonder about the rest of his technical assertions that I'm less able to judge."
What technical assertions? From what I can gather, he's just pointing out what he sees in the code and what he thinks it might be doing. None of that feels like technical assertions (apart from the statement about PUT and GET).
He also implied that the presence of PUT and DELETE alone demonstrate that the app is using WebDAV and not a standard REST API via RFC2616 et al.
He also stated that WebDAV isn't a standard (ie RFC).
He also stated that you don't need PUT or DELETE because it can be done 'on the server'. (I'm not sure how you get your data to the server without HTTP verbs, but..)
With that said, his other work looks spot on; you don't always have to know how to architect a service in order to figure out what's broken with it. He's done a service to the community by taking this thing apart and seeing what makes it tick.
In that a WebDAV implementation wouldn't make use of them? I assumed that a WebDAV implemenation would use them, but the WebDAV spec doesn't need to define them because the HTTP spec it references already did...
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 guess: The call might show up in the phone logs if it's made through the standard Android Phone app. If the call is made directly from the Uber App, then perhaps this means that Uber can hide the phone number from the user. I can think of a number of reasons why they'd want to do that if they could.
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.
So then, how do you define "unauthorized parties"? All these permissions are explicitly authorized by the user, and I don't see any evidence that they're being used in unreasonable ways by Uber.
> The average person doesn't reasonably expect Uber to be mining this information about them.
Then it sounds like you would predict that, if you showed this article to the average Uber user, they would be upset and would stop using the app. Would you predict that? I think that is extremely unlikely, and that the vast majority of people wouldn't be interested and couldn't care less.
"Explicitly authorized" might be debatable. There's no way to pick and choose what permissions to authorize; your choice is solely whether to install the app or not. If you could specify permissions and you did (and opt in, not opt out), then that would be explicit authorization for all of those permissions.
It's a matter of looking at everything Uber right now with wariness in the light of multiple, public comments that indicate a complete lack of respect for their customers, their privacy, 'oppo' journalists, and even their competitors.
This is not simply a matter of capitalism at its best, or competitive assertiveness. This backlash could be viewed as a market correction against a company that has actually gone out of its way to bully everyone around.
Can you imagine what will happen if Uber gets the monopoly it's after? The entrenched taxi companies will seem positively benign. Even Microsoft never did the things Uber is explicitly stating that it is doing or trying to do.
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.
I have a lot of issues with iOS, but I think Apple's UX here is clearly superior: it asks you about each individual permission an app requests (not on install, but when the permission is first used), and allows you to deny it.
As usual, Microsoft did it first, but got the UX all wrong. Apple comes along does something very similar, but because of the App Store and the infamous review cycle, can enforce some semblance of control over the app ecosystem.
Notice: Apple only does this fairly granular security on iOS, and OSX is much more similar to how Windows it.
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.
The permission model is broken. I should not give permission at install-time, it should be asked at runtime, at OS-level, and I MUST be allowed to say no anytime .. if I trust the app enough, then I should be able to say "allow the app to do that thing for this hour/day/month/always"
why mobile OS authors haven't learn anything from the web security model yet?
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 :-/
I like his image at the bottom that tells you to put in your credit card number and expiration to see if its been stolen. Upon inspection, the onclick just pops up an alert that says "Dumbass!" haha
I know that at least Cyanogen exposes something similar inside settings > privacy. I believe it comes from the hidden app permission manager built into Android.
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.
It's not a user's fault they have to root to regain some control over a piece of hardware they own. Your app shouldn't crash under xposed - test for it.
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
Isn't it possible to route all traffic to/from an Android device through a MIM proxy, run the Uber app, and then see exactly what data is being sent to Uber HQ?
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