
Android: I don't need your permission - dopkew
http://blog.danlew.net/2014/11/26/i-dont-need-your-permission/
======
jbk
I wish it was that easy in all cases.

For VLC on Android, we need the READ_PHONE_STATE permission, in order to stop
the music when a phone call is coming in. We just use it to make pause on
incoming call. (VLC on Android is also an audio player, with a background
audio service).

The catch is, this is not an Intent you can send or request easily. We tried
so many other ways, but none work.

But on the play store it's written "read phone status and identity" and that's
really really scary for the users.

And even if we're 100% open source, so people can check the application, and
even people recompile VLC, this is a complaint we receive a lot...

~~~
iscrewyou
This. This is why I am moving to iOS.

I installed Pocket. It wanted permission Contacts and Calendar. Contacts, I
understand for sharing purposes. Calendar? Yeah, fuck off.

Maybe they are bundled together like "read phone status and identity" and
Pocket has no way around it. Maybe it is not. As a user, I should not have to
worry about that.

Contact and Calendar in no way should be bundled together.

~~~
icebraining
_Maybe they are bundled together like "read phone status and identity" and
Pocket has no way around it._

They aren't.

~~~
Oletros
They are

~~~
icebraining
No, they aren't. READ_CALENDAR is a separate permission from READ_CONTACTS.

~~~
TheQwerty
You're correct that they are indeed separate permissions but I think when
Google started putting them in buckets for displaying to the user they lumped
the two together.

For instance on one address book app the website currently shows them asking
for: Contacts/Calendar -read your contacts -modify your contacts

While the app on my phone says: Contacts -read your contacts -modify your
contacts

According to Android Police an update earlier this month to the Play Store app
appears to have separated them again:
[http://www.androidpolice.com/2014/12/06/apk-teardown-play-
st...](http://www.androidpolice.com/2014/12/06/apk-teardown-play-
store-v5-1-11-adds-support-for-discounts-through-reward-vouchers/#changing-
permission-buckets)

------
Someone1234
> If your app is closed-source then they have no way of verifying you're not
> downloading all their contacts to their servers.

That's a common fallacy. Even if it is open source someone could still be
doing that. In order to be secure you would have to:

A) Download the source yourself B) Inspect the source C) Compile the source

Just because you have the source doesn't mean what you get from the Play
Store/Amazon App store is 1:1 identical or even similar.

There is secret option D, have someone you trust do A through C and then give
you the hash of the resulting compiled file. But two programs compiled on two
machines often give different results due to library versions, compiler
versions, environmental settings, and so on.

~~~
nly
In practice you can disassemble Java apps to pseudo source code anyway. I've
done it several times to APKs to see what is going on under the covers.
Deliberate obfuscation would be immediately suspicious.

~~~
acdha
1\. How closely would you have to look to notice something like a weak crypto
setup or other “accidental” change less obvious than sending everything to
“all-your-bytes.nsa.gov”?

2\. How many people other than blackhats actually have the time to do this for
every single automatic update?

~~~
kuschku
It’s actually really easy.

I tried understanding the APIs several phone apps are using, (the apps are
heavily obfuscated), so I decompiled them and hacked my own small deobfuscater
where I could rename stuff half-automatically.

Then I went through the code of Google Apps with this, and it’s actually
really nice. Although kinda surprising how many Google Apps have hardcoded API
keys for their services floating around, for example there is one Google App
which has a hardcoded key that allows full unthrottled API access to all of
the Google Maps APIs. For free.

I just did this out of fun, as I’m mostly working on Android OpenSource apps,
but it was quite easy and interesting to see how Google obfuscates their apps.

~~~
acdha
Finding predictable things like hard-coded strings is a significantly easier
task than proving that none of the code is doing something sneaky. It's much
easier to look for something like an access key than confirm that the numeric
constants being passed to a crypto function are the correct ones or that it's
not leaking something which would make it much easier to crack.

~~~
kuschku
We’re not talking about hardcoded strings, lol.

This is encryption and obfuscation on multiple levels, classes passing each
others state through hashing and encryption schemes on multiple levels, added
bytecode hackery, etc.

~~~
acdha
Exactly my point – it's unreasonable to expect that higher level of reverse
engineering will be done reliably for every release of even a small percentage
of the apps being published.

------
robert_tweed
> Case in point: android.permission.CALL_PHONE. You need it to initiate phone
> calls from your app, right?

This kind of thing is why I can't see myself switching to Android as my
primary mobile OS any time soon. If anything, I can see a bright future for
Microsoft. In spite of the fact Windows Phone exists, Android is very much the
Windows of the mobile ecosystem.

Permissions on Android are horrendous for developers. But they are even worse
for users. If a developer can't tell the difference between ACTION_CALL and
ACTION_DIAL, what chance does the average end-user have?

And when every app requests at least half a dozen permissions, how many users
are going to carefully review each and every permission and how many are just
going to give up and grant all requested permissions to every app the way that
everyone reflexively clicks "agree" to every online ToS? Even if Android
actually had a working method to deny individuals permissions, nobody ever has
any idea which permissions are essential to which classes of app and which
should be treated with suspicion.

Compare this to iOS, where you may occasionally get asked to grant an app
access to contacts or location - this is a rare occurrence and you can choose
deny every time with no negative consequences (except for restricting that
functionality).

The comment by jbk illustrates just how big a mess permissions on Android are,
beyond just being confusing. On top of that you've got custom intents, which
while a great idea on paper, just pile more complexity on top of a broken
foundation of complexity and obfuscation.

This IMO is the single biggest thing wrong with Android, which Google should
prioritise fixing like Microsoft in 2002. Never mind signed-app stores like
Play: the fundamentally broken security model is the reason why Android is the
only mobile platform to have a problem with malware. It's also a brilliant
case study in over-engineering with a complete failure to consider human
psychology.

~~~
tripzilch
I' an Android (Cyanogenmod) user and agree with your point, this could--and
should--be done a lot better.

I am not familiar with iOS and iPhones at all. You state iOS apps only rarely
need to be granted permissions, how do they make that work? I can see only
three ways that could happen:

Either the app can do most things without asking permissions (bad for the user
--there'd be malware). Or the app simply can't ask for permission to do a lot
of things (bad for the developer, and ultimately the user--because less
functionality). Or it's a combination of the first combined with the iOS App
Store's walled-garden quality check approach (bad for everybody, and the
biggest reason I got an Android instead of iOS device).

I could be wrong but I'm guessing it's the third option?

I'm going to try to be objective here, crazy how I can just _feel_ that seed
of fanboiism in my head, let me just leave it at me being idealistically
opposed to the walled garden approach for reasons that have been rehashed on
HN for ages now :)

 _That said,_ there's also a few practical things the iOS walled-garden App
Store could improve upon. First one being the $99 developer fee. I teach kids
computerstuff and one time a particularly clever 11-year old needed some help
setting up Eclipse, I didn't have a smartphone myself back then, I wasn't sure
what he was trying to do, so I just helped him navigate the English menus,
install the proper Java things and let him at it. Sure enough, an hour later
he proudly showed me his Android phone. "Hello World", it said.

Another thing, this iOS App Store review process, it's done by humans yes?
Does it scale? From what I've heard, even though I mostly heard it in the form
of complaints, you get rejected by _actual humans_ , yes? That's obviously
never going to happen to Google's Play Store. But then again, the Google Play
Store isn't quite as deeply engrained into Android as the iOS App Store, you
don't _need_ to use it, you can even completely step out of Google's ecosystem
and still use Android (though it's hard, a bit like using Linux 15 years ago).
Does the iOS App Store also use scanners and automated tests for new
applications? I bet they do, do we know what kinds? Like it could test for
certain kinds of API calls so the human reviewers know what sort of thing to
look for.

One funny thing is, I used to have to explain people what "repositories" are
in Linux, what they do, what they're used for and why they're so much cooler
than (Windows) having to download .exe installers from all sorts of websites
to get your software. Nowadays I can just tell people "it's pretty much like
an app store", and they know all they need to know. That Ubuntu Software
Centre even _looks_ like an app store, with all the stars and ratings (blegh).

However, the repositories in Linux, are _not_ quite like either the Google
Play Store _or_ iOS App Store. They obviously do not have the walled-garden
approach, it's entirely open. Linux software from the repositories doesn't
need to ask for permission for anything (except sudo). Still, there is no
malware in the repositories, at all. I admit I am a little bit vague on how
this works too, perhaps I'm missing something obvious, but how do they do
that?

~~~
masklinn
> I could be wrong but I'm guessing it's the third option?

Nah, it's a combination of two things:

1\. Applications are granted internet access by default. It's possible to
disable _cellular_ access on a per-application basis, but not networking in
general

2\. Permissions are asked for at point of use with a big allow/deny dialog.
This has several consequences

* it's easier for the user to understand why the application would want to e.g. access their contacts

* the user only gets the dialog if they're accessing a feature which claims a need for it, no paying a privacy/permission cost for stuff you don't do

* the more stuff an application wants access to the more scary dialogs they'll prompt, so application developers have tended to not go overboard

Also all permissions can be revoked (or granted) afterwards, aside from
cellular they all live in Settings > Privacy, and inside each permission is
the list of applications which asked for it, and whether they're allowed or
denied access

~~~
tripzilch
Thanks, that makes sense. Better option than what Android does too, IMO.

Especially if the permissions are also more granular than they are on Android.
Otherwise I could imagine an evil app prompting a type of permission in the
context of something completely innocuous and reasonable (say, to pre-fill
contact data to some input field), only to use that very same permission
immediately afterwards for something evil (sending all contacts data to their
servers).

------
habosa
There are two additions to the permissions API that I think would be very
helpful:

1) Incremental Authorization - let Android apps ask for permissions only as
they need them. So if you never use the phone dialing feature, they never ask
for the permission. 2) One-time auth - allow an Android app to do something
once. Say, scan your contacts one time. This gives you a little more control,
so you know the dev isn't monitoring your phone at 3am.

Here is the problem though: most people don't actually care. The vocal
minority cares, but most Android users don't know what a permission is if you
ask them. So all that developers get for trying to work around permissions is
less people using their app or less features in the app. Sadly there is no
real incentive for a developer to be sparing with permissions for apps that
target the mass market.

~~~
Aldo_MX
1) Incremental Authorization - let Android apps ask for permissions only as
they need them. So if you never use the phone dialing feature, they never ask
for the permission.

Not only incremental authorization, but the ability of denying specific
permissions.

~~~
habosa
Well with incremental the developer would put what is 'required' into the
manifest for install-time prompt and incremental the rest.

You can't expect a developer to allow you to deny any permission, the whole
app would be a giant if-statement spaghetti accounting for all of the
permission combinations and workarounds.

~~~
Aldo_MX
As a user, I don't care if your app will self-destruct if you don't get access
to permissions like "read and send SMSs". I simply don't want a free to play
game to scan my SMSs for advertisement purposes.

------
CSDude
This is the another reason I use CyanogenMod. It has Privacy Guard and I can
disable the nasty permissions as I please. If you have Android 4.3+, you can
also install it indivudally
[https://play.google.com/store/apps/details?id=com.findsdk.ap...](https://play.google.com/store/apps/details?id=com.findsdk.apppermission)
(requires root I guess)

The most helpful one, even if you are not privacy/security concerned is to
disable wake up/keep awake requests, which Facebook and FB Messenger used it
apporximately 6800 times since I installed my clean rom 1 week ago.

~~~
dozy
I love CyanogenMod (or at least the concept...I'm over dealing with the
headache in practice), but the reason I used it was certainly not for improved
stability and security.

Not that I particularly trust OEMs/carriers, but the only way I'd feel _more_
secure with CyanogenMod is if I had time to audit the source _and_ build the
kernel and OS binaries myself, and that includes whatever code is used to root
and unlock your device in the first place. If you do that though, more power
to ya.

Also, disabling permissions at runtime is a foolproof way to make an app
crash, as the _vast_ majority of apps will assume they're granted the
permissions hardcoded in the manifest at compile time.

One last point - rooting your phone and granting apps root access just to
disable crucial permissions such as holding a wakelock seems pretty reckless -
have you personally seen the source code for that app? At least the dev's
website seems legit: [http://www.findsdk.com/](http://www.findsdk.com/)

EDIT: Even better, looks like the author of App Ops, or at least the owner if
the findsdk.com domain, is in China :)
[https://who.is/whois/findsdk](https://who.is/whois/findsdk)

~~~
dmix
Privacy Guard does not require rooting your phone and can easily be enabled in
stock ASOP Android phones:

[http://www.guidingtech.com/23409/enable-android-
permissions-...](http://www.guidingtech.com/23409/enable-android-permissions-
manager/)

It is really a shame that Android doesn't provide this feature enabled by
default anymore (as they did for at one point). It could easily be provided
with a warning that this might break your apps and use with caution.

Security often has a UX trade-off, that doesn't mean it can't be handled well
by good design.

As someone who is working on a (secure) Android ROM, I don't recommend trying
to build the kernel from source unless you're serious about doing it, the
Android repo build system is a mess and will take you hours to get working
right.

~~~
untog
Unfortunately you do need root as of 4.4, IIRC.

------
JoshTriplett
This makes it all the more egregious that so many applications ask for
permission to access contacts and similar.

Perhaps Android should rephrase these permissions as, for instance "direct
access to contacts without your knowledge", as opposed to "access to user-
selected contacts upon request" (which, as demonstrated, does not need
permission).

~~~
digi_owl
Given that Google has gone to lengths to obfuscate the permissions further in
Play, i don't think that is likely to ever happen...

------
avz
I would be very happy if instead of preventing me from installing apps which
require a given permission, Android would let me install them at my own risk
in a sandbox which provides the app with dummy data and interactions (whether
from a sensor, contacts db, camera etc).

It would be even better if the framework explicitly supported running apps
without the necessary permissions and simply threw some sort of
PermissionException. This would cripple some functionality while preserving
the rest.

Developers could of course write the apps to not work under such reduced
conditions, but Google Play could reject such apps.

~~~
brk
This sounds like a great way for paranoid but uninformed users to break lots
of apps, and then blame the developer/phone/carrier (in any random order).

We sometimes forget that really with smartphones the manufacturers are trying
to produce something for the masses. This would also seem to include reducing
the amount of security consciousness the user needs to have in order to have
an "acceptable" experience with the device.

~~~
eslaught
And yet, the iPhone basically does this for a number of permissions (location,
push notifications, contacts access, etc.), and for the most part it seems to
work for even uneducated users of iOS.

For most permissions, you might not want this, but for some of the more
sensitive and personal-information rich sources, this is a really highly
desirable feature.

------
bndw
I made app ethics[1] a while back in hopes to surface what some of the android
permissions mean.

[1] [http://appethics.org](http://appethics.org)

------
_s
Crazy theory but stick with me please -

Why aren't we as users allowed to fine grain the data on our device that we
want the app to have access to?

A benign example would be a camera app; it wants access to my camera and mic,
perhaps the local storage. It may have further features to store images in
it's cloud service, assign the image to a contact and so forth.

But as a user I only want the app for it's picture taking ability - the app
requests at the point of installation the permissions it requires, and I only
grant it access to the camera.

It's then down to the app / developer to handle the exceptions and offer a
message saying "You have taken a picture, but the app doesn't have permission
to save it to storage. Please allow access by clicking here, otherwise this
feature will not work/be unavailable".

A bit more of effort on the developers part, no question - but a user than has
complete control over what an app can access.

I'm not an app developer, but skimming over how intents work and chiming along
with this article - I don't think it would be a significant change to the
underlying structure of android to hand back specific permission controls to a
user.

~~~
berkut
I guess the app would have to handle not being allowed permission to do these
things gracefully.

That's possibly a tall order based on my experience with apps these days,
although for a difference reason: a lot of them assume there's internet
connectivity, which isn't always the case, and a lot of apps don't handle this
gracefully at all, even for doing things like opening maps, finding location,
turning data off, going to another app, then back to maps again, and it takes
ages for it to display because it's expecting to have network access.

------
digi_owl
Best i can tell, quite a few requested permissions do not come from the
developer. Instead it is the defaults of some framework or other the developer
used to handle some of the nitty gritty details, like the ads.

~~~
rogerbinns
Another angle being missed is that Android won't auto-update apps if they have
new permissions (modulo some minor details). The developers I worked with
always added more permissions to their initial app versions for things they
weren't using, but might in the future.

~~~
digi_owl
That is a Play thing, not a Android thing, iirc.

Still, with the latest change in permissions handling in Play, it will happily
auto-update an app if the new permission(s) are in the same category as a
previous one...

------
blacksmith_tb
Another reminder of how eagerly I await Xposed / Xprivacy on ART for 5.0...
that said, his examples are fairly benign, I agree that if your app needs to
initiate a call, it should show me the dialer to see if I would like to do
that now, or some other time (including never).

~~~
delecti
If you're just waiting for permission controls, App Ops [1] should work just
fine on 5.0. There are other comparable apps that also don't require Xposed.

[1]
[https://play.google.com/store/apps/details?id=com.findsdk.ap...](https://play.google.com/store/apps/details?id=com.findsdk.apppermission)

------
clumsysmurf
In the case of bluetooth, you can either (1) request BLUETOOTH_ADMIN
permission and enable BT yourself, or (2) ask Android to show an "Enable
Bluetooth Dialog" (BluetoothAdapter.ACTION_REQUEST_ENABLE) which doesn't
require that permission.

But #2 has been busted for a while
[https://code.google.com/p/android/issues/detail?id=60002](https://code.google.com/p/android/issues/detail?id=60002)

They didn't fix it, and marked it obsolete. So I guess we need BLUETOOTH_ADMIN
after all.

------
Fando
Good article. As good as Google's permission system is, it lacks obvious
features. Maybe I'm missing something, but I think that Android permission are
overly general and not specific enough in a majority of apps.

~~~
DeepDuh
As good as it is? I find it pretty terrible, at least for me it singlehandedly
makes me not want to use Android.

------
swatow
This is interesting because it's essentially the same security model as the
web.

Your app runs in a controlled environment, and it has the option to nest
another app (on the web, in an iframe) which it can send messages to, but
can't affect the code _or UI_ of.

The fact that the UI cannot be manipulated by the nesting app, is crucial,
since it allows the security model to tie certain user actions, like pressing
dial, to certain actions, like making a phone call.

------
tn13
I think all apps should be given a choice to have ephimeral permission. For
example I dont want someone to find an exploit in my app and steal my user's
contacts.

I would only take contacts permission when I need and keep it for a short
duration and then willingly give it up. User can be explicitly prompted.

Also, Camera and Microphones should have only this sort of permissions other
than for those which are explictily whitelisted by Google.

------
jonalmeida
In the example about the phone call, you could give the user the option to hit
the call button, but once this is complete a dialog should popup saying, "Do
you want this to happen automagically henceforth?" which would then take full
use of the Phone permission. This would also allow permissions to be toggled
on/off, which a feature I really want in Android.

------
stevebot
Just curious though for these specific examples as it says "if you read the
source", could these intent's change in future releases, or is it documented
outside of the source and accepted that using these intents is not relying on
Android internals that could change?

------
blueskin_
This is why I love xprivacy. It gives me a popup when an app tries to access
something, and I can whitelist or blacklist it, either on a temporary or
permanent basis. Unlike google's halfarsed attempt at a privacy layer, it also
doesn't give an exception when an app tries to access restricted data as that
can cause apps to crash; it just sends back fake data (device ID is DEFACE,
contacts are empty, location is christmas island, etc.). It also covers just
about every permission you can think of, unlike app ops/privacy guard that are
just a few.

Although really, what needs to change isn't just in android itself; it's also
developer behaviour. Stop _trying_ to do intrusive things like prefilling
forms, as it doesn't benefit the user in any real way.

~~~
mcherm
> Stop trying to do intrusive things like prefilling forms, as it doesn't
> benefit the user in any real way.

Speak for yourself -- I find prefilled forms to be a time-saver.

However, I don't want apps trying to read through my contacts in order to do
it. What I want (but haven't actually configured) is xprivacy configured to
make contacts appear empty.

~~~
blueskin_
When an app tries to read your contacts, it gives a popup showing contacts as
the item accessed; uncheck 'once' and click deny.

------
ww520
This is classic privilege elevation via a 3rd party privileged process. I
thought Android's permission system carrying the security context from app to
app through Intent. Guess the assumption is wrong.

In most OS, the security token/context of the initiating process is carried
over to the target process when it's asked to do something on behalf of the
initiating process via IPC so that the target process runs at the privilege
level of the initiating process even if the target process has a higher
privilege to start with.

------
ctz
The same goes for android.permission.INTERNET. Apps can open arbitrary URLs in
the browser (which load without user intervention).

~~~
tjbiddle
However that's not the only use case for android.permission.INTERNET - you
need it for anything that does networking on the internet, such as API calls
to your web application.

~~~
lucas-be
So the entire computer world had run like this for decade. why are people
complaining about that now? Because Apple is doing strict verification of your
code behaviour?

Yesterday adobe pdf viewer tell me that an update was available both on my mac
and pc! So without asking my permission, this computer application (and many
others) are querying the web...

~~~
sharjeel
The PCs didn't sit in your pocket all data with sensing GPS location, mic,
camera, footsteps, discovery of bluetooth and wifi devices around you; neither
were they single point of communication with the rest of the world.

~~~
lucas-be
Not as long as you have not synchronized your phone with a cloud service
(ICloud, Google drive, etc.) on which your PC/MAC is connect too.

------
Fradow
The theory seems great. The reality is not.

When you do that, you delegate your UX and proper functionning of your app to
a third-party app.

The UX can vary according the app. One thing is certain, it won't always be
consistent with your app. It is also going to be more complicated for the user
(more actions to make, more choices, just because you don't want to add
permissions).

The proper functionning is even worse. Did you ever heard about the
fragmentation of Android? Well, Intents are where it's worse. Some apps
plainly don't work, or are buggy.

Intents are great to save time prototyping something. However, if a feature is
central to your app, you are better off ensuring yourself that it works well
and is easy to use, something that Intents can't guarantee.

Of course, the permission system is far from ideal, and some people will not
install your app because you ask for some permissions. I'd say that's a price
to pay for developping on Android.

P.S.: some examples of Intents that don't work so well:

1) sending a mail. Good luck finding how to properly use an Intent that is not
handled by text apps and allow you to put attachments

2) picking a photo from gallery and resize. A lot of photo apps are plain
broken for that Intent. And I'm not talking about some obscure device on a
rooted Android, I'm talking about Google's Nexus, with stock apps.

~~~
Pxtl
Thinking like this is what led to so many terrible '90s windows apps eschewing
the Common Dialog box for file management.

We all eventually accepted that you should let the OS do its native thing.
Android is no different.

------
snake_plissken
I recently got a Moto E as my first smart phone, ever, and after checking out
some apps, I was astounded and befuddled by the access permissions that it
seems every app needs.

Take ESPN's fantasy football app, which requires: device and app history -
whats apps are running, browsing history, bookmarks identity - accounts on the
device, profile data photo/media/files - access to files on the device and the
device's external storage wi-fi connection information - whether wi-fi is
enabled, names of connected wi-fi devices device ID and call information -
determine the phone number and device IDs, whether a call is active, and the
remote number connected by a call

I can understand why it might need access to the file system to, for example,
upload an avatar. The access to wi-fi seems innocuous, although I would expect
something like network connectivity and status to be delegated to a kernel
module or background daemon with which an app interfaces.

But is there any legitimate (i.e. some non-financial oriented mine as much
data as possible) reason it needs to be able to see what other apps are
running, my browser history or who is on the other end of a call? There might
not be any reason, and ESPN could potentially build the app to have as many or
as few permissions as they deem valuable, because people want an app to manage
fantasy football teams first. While this example might not be the best, since
ESPN is a huge brand and there is no alternative if they are hosting your
league, the situation was the same with so many other apps; just absurd
permission requirements.

None were installed.

