
Permissions asked for by Uber Android app - uptown
http://www.gironsec.com/blog/2014/11/what-the-hell-uber-uncool-bro/
======
dmix
_TLDR_ : Uber's Android app is literally malware

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](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...](http://www.gironsec.com/blog/wp-
content/uploads/2014/11/InAuthManager.txt) note the name "package
com.inauth.mme"

Edit #2: here is a screenshot of Uber's permission request
[https://i.imgur.com/4MmYrJH.png](https://i.imgur.com/4MmYrJH.png) no SMS on
the list

~~~
revelation
Just for completeness sake and judging from the function names, this is the
list, with attributes stored for each:

\- 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.

~~~
madeofpalk
> I really don't see any reason for Google not to immediately remove this app

Apart from Google being an investor in Uber?

~~~
higherpurpose
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".

~~~
madeofpalk
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.

~~~
tonyhb
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.

~~~
madeofpalk
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.

------
andymcsherry
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.

~~~
Aissen
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.

~~~
tadfisher
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.

~~~
Aissen
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.

~~~
andymcsherry
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.

------
andrewvc
_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.

~~~
iolsantr
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](https://www.ietf.org/rfc/rfc2616.txt) A
simple search will show that it does include PUT and DELETE.

~~~
amirmc
> _"... 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).

~~~
jamiesonbecker
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.

------
declan
I'm not sure the criticism in the linked post is justified.

Here's what Uber says about its Android permissions -- the page isn't that
difficult to find: [https://m.uber.com/android-
permissions](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](https://news.ycombinator.com/item?id=8383854)),
but before rushing to judgment here let's check our facts first.

------
krschultz
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.

~~~
driverdan
Why? All we have is a tel: link that opens the phone number in the dialer.
They can choose to initiate the call or not, no permissions needed.

~~~
pja
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.

------
blhack
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.

BTW, this is all available in the app permissions:
[https://lh3.googleusercontent.com/-FVPu6x-F5SM/VHUZgU47m-I/A...](https://lh3.googleusercontent.com/-FVPu6x-F5SM/VHUZgU47m-I/AAAAAAAAJuQ/STPzA9cJdQ4/w668-h1186-no/14%2B-%2B1)

I don't see the big OMG SECRET MALWARE scariness.

~~~
dmix
> 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.

~~~
baddox
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.

~~~
jamiesonbecker
"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.

------
api
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.

~~~
rco8786
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.

~~~
api
Sounds like classic poor security UX design -- it encourages people to allow
everything, and encourages apps to claim everything.

~~~
TillE
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.

~~~
dvhh
Wasn't that almost the same approach with UAC ?

~~~
r00fus
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.

------
akanster
Google cache:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://www.gironsec.com/blog/2014/11/what-
the-hell-uber-uncool-bro/)

~~~
profinger
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

------
georgeott
Pro Tip: Unintall the Uber App, and use m dot uber dot com inside Chrome.

~~~
guelo
I do this with Facebook also.

~~~
skeletonjelly
Won't that mean that Facebook will know what sites you visit that run FB's
beacon/SDK?

Better off using Tinfoil for Facebook (if Android)

[https://play.google.com/store/apps/details?id=com.danvelazco...](https://play.google.com/store/apps/details?id=com.danvelazco.fbwrapper)

------
monort
Android needs a sandbox, which will provide apps with empty contacts, call
history, fake location and so on.

Does such sandbox exists?

~~~
cle
XPrivacy?

[https://github.com/M66B/XPrivacy](https://github.com/M66B/XPrivacy)

~~~
dserodio
I'm devastated that it doesn't (and apparently, never will) work with
Lollipop.

------
makeramen
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.

~~~
MrGunn
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.

------
dpiers
There's an article here explaining what the permissions are used for:
[https://m.uber.com/android-permissions](https://m.uber.com/android-
permissions)

------
dang
We've attempted to change the baity title to something accurate and neutral,
but if anyone can suggest a better title, please do.

~~~
uptown
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.

------
duncan_bayne
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.

------
click170
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.

~~~
dingaling
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.

------
msoad
Google cached

[http://webcache.googleusercontent.com/search?q=cache:6rWGz01...](http://webcache.googleusercontent.com/search?q=cache:6rWGz01vSDoJ:www.gironsec.com/blog/2014/11/what-
the-hell-uber-uncool-bro/+&cd=1&hl=en&ct=clnk&gl=us)

------
rubyn00bie
Definitely uncool and a great article.

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
archive [https://archive.today/CR3eW](https://archive.today/CR3eW)

I personally believe Uber app on android fits the definition of a malware.

------
zeus180
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](http://i.imgur.com/AVXLqgh.png)

------
wpnx
Mirror in google cache:
[http://webcache.googleusercontent.com/search?q=cache:6rWGz01...](http://webcache.googleusercontent.com/search?q=cache:6rWGz01vSDoJ:www.gironsec.com/blog/2014/11/what-
the-hell-uber-uncool-bro/+&cd=1&hl=en&ct=clnk&gl=us)

------
lukasm
[http://webcache.googleusercontent.com/search?q=cache:6rWGz01...](http://webcache.googleusercontent.com/search?q=cache:6rWGz01vSDoJ:www.gironsec.com/blog/2014/11/what-
the-hell-uber-uncool-bro/+&cd=1&hl=en&ct=clnk&gl=uk)

------
hartator
Down for me.

[http://webcache.googleusercontent.com/search?q=cache:6rWGz01...](http://webcache.googleusercontent.com/search?q=cache:6rWGz01vSDoJ:www.gironsec.com/blog/2014/11/what-
the-hell-uber-uncool-bro/+&cd=1&hl=en&ct=clnk&gl=us)

------
bndw
If you're interested in exploring this, and other Android app's permissions, I
built [http://appethics.org](http://appethics.org) last weekend.

The goal was to easily surface what permissions a given app requires, and what
they mean.

------
gasull
This is outrageous. Write a review at
[https://play.google.com/store/apps/details?id=com.ubercab](https://play.google.com/store/apps/details?id=com.ubercab)
and link to the article. I just did that.

------
chc
imperialdrive, if you happen to read this, you appear to have been hellbanned.
Just FYI.

------
rrrrr
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?

------
first_account
Uber doesn't know who does the ride of shame based on pickups and drop offs,
they just monitor the phones of their customers!

------
stesch
I don't have Android 5.0. Is it now possible to block certain permissions per
app?

~~~
fstephany
No.

------
djabatt
Clearly aggressive and not in a way that improves UX.

------
aosmith
Looks like it's time to turn on memcached...

------
pkaye
Wonderful! Just last week, Samsung did an update on my phone software and
installed the Uber app automatically. Glad I removed it after that.

------
thisjepisje
As a dumbphone user, why people even allow an app to get information like this
is beyond me.

~~~
dvhh
Some people find it acceptable to give up information for "convenience", or
even worse : bragging

------
ape4
Uber: nice idea, evil company.

