
CyanogenMod Adds Support For Revoking And Faking App Permissions on Android - DanielRibeiro
http://www.androidpolice.com/2011/05/22/cyanogenmod-adds-support-for-revoking-and-faking-app-permissions/
======
kelnos
So I'm really disappointed. It appears that the post has been updated to note
that this patch set will never make it into CM, and the people commenting on
the code review request are openly negative about it, citing concerns about
pissing off Google/app developers/carriers, and making it more likely that
manufacturers will make it harder to root/unlock devices.

Of course there's absolutely no evidence that any of these things are true,
though I'll grant that they're valid concerns, to some extent.

It still pushes the notion that, despite being an open-source platform,
Android isn't really "ours". It belongs to Google and the wireless carriers,
and our ability to run our own version of a supposedly-open mobile OS is
entirely at their whim.

I absolutely love CM and have been running it on my N1 for close to a year
now, but it just sounds like they're too afraid of backlash to add features
that could (with some refinement) really protect users.

~~~
guelo
Well I don't think CM is necessarily "ours" if you are referring to users. I
would bet that every major CM contributor has their own apps in the market, so
obviously they're interests lie much more on the vendor side than the user's.
That's why you see here more interest in accurate data collection than in
privacy.

------
njs12345
I did something quite similiar last summer - we got it published
([http://www.cl.cam.ac.uk/~arb33/papers/BeresfordAREtAl-
MockDr...](http://www.cl.cam.ac.uk/~arb33/papers/BeresfordAREtAl-MockDroid-
HotMobile2011.pdf)) but we never looked at getting it into CM. I guess they're
more receptive to the idea than I expected them to be!

The whole faking data thing works quite well - every app we tried with our
implementation basically worked as intended (i.e. if you prevent the app from
accessing the internet, everything still works apart from functionality which
explicitly depends on accessing the internet), which is a nice consequence of
apps being written for mobile devices where access can't be taken for granted.

~~~
mdwrigh2
I find it interesting (but not all that surprising) that so many people
developed a similar concept. The research professor I was working with this
past year actually published a similar system:
<http://www.csc.ncsu.edu/faculty/jiang/pubs/TRUST11.pdf>

~~~
njs12345
That does look pretty similiar to what we did. I've emailed Plamen about it -
hopefully we can integrate all this stuff to give CM users full control over
what apps do with their personal data :)

TaintDroid is pretty awesome as well: <http://www.appanalysis.org/>

------
ck2
This alone makes my android device feel 100x safer and now I can finally start
trying more apps. Google should implement this in the core asap (as well as a
firewall).

Some apps have some crazy requests that need explaining!

Does the iphone have any such granularity control for permissions? (official
or unofficial)

~~~
PassTheAmmo
I would also like to see that developers were required to state why each
permission is needed and present this to the user at install time.

~~~
AretNCarlsen
But users might actually read the developers' explanations, in which case they
would need to be true. If no 3rd-party verifies the permissions explanations
before the app is released, then the only value is as a legal agreement
between the developer and end-users. I would expect that to devolve into a
30-page EULA per app ... which has already happened, for many apps.

@ck2 is performing as thorough of a verification as possible without source
code access. If I were a malicious app developer, however, I might program my
app to wait a week before transmitting any user data.

------
ydant
I've wanted something like this to be part of the OS, although it causes a
bunch of hassles in BlackBerry (from a developer's perspective).

There was a discussion on Android-Developers about this (as a core OS
feature), in which (I think) Dianne Hackborn (one of the Android developers)
came out strongly against the idea of allowing users to choose which
permissions to allow/disallow for an individual application. (Edit: I think
this is what I was remembering: [http://groups.google.com/group/android-
developers/browse_thr...](http://groups.google.com/group/android-
developers/browse_thread/thread/eae545087448b1b1/9833ebc8a343674b))

I think it's a good feature to have in some cases. Some applications, for
example, the Yelp application, request features I'd rather not give, but I'd
still like to use the application in general. It's not that I feel the
applications are openly hostile - I would never trust the permissions library
in that case, but I have no desire to give my contacts list to the Yelp app.
This is just one example - I'm sure a lot of people would try to disable
Internet on apps that use Internet solely to show ads, for example.

~~~
rhizome
I would love it if this was combined with the UX of NoScript so that I could
greenfield my perms and allow them selectively, granularly, and optionally
permanently. At any rate, hopefully this is the beginning of the end of the
PII giveaway.

------
mcantor
This is super-neato, but what I am really waiting for is a way to fake device
capabilities in the market, so I can finally use the RememberTheMilk app on my
rooted gTablet!

~~~
angryasian
alter your build.prop file

------
topbanana
Don't the apps just fall over when they try to perform a revoked operation? I
doubt they'd expect it

------
cjkarr
As an Android app developer, I'd totally support this as part of the native
platform. While I haven't gotten an e-mail from a paranoid user asking why
Fresh Comics needs their location data, I've gone ahead and done a small
writeup on why my app needs the location permission, why I need that data, and
what I do with it afterwards:

<http://freshcomics.us/support/privacy-location-information/>

In my role as a developer, I'd support a way that I could specify these
details in a more standard & concise way and allow the user to enable &
disable permissions as needed without having to make an all-or-nothing
decision whether to install the app.

As a user, I'd appreciate it even more. :-)

~~~
StavrosK
I can understand why fine-grained permission selection would be an onus to
developers without really providing much of a benefit for the average user,
but I would love seeing brief explanations under each permission ("needs
internet because: downloads ads", "needs to read messages because: analyzes
text").

------
AretNCarlsen
@everybody: "This way we can disable Internet access on apps and games that
are just downloading ads."

In The Business, we call this "piracy". Unless, of course, the developer is an
altruist who did not intend to monetize their app, but accidentally dropped in
an ad window.

Like web browser ad blockers, I expect that developers will ignore this UNLESS
it begins to eat into their general user base. Then will come the code
libraries that try to guess whether the permissions are accurate or not (e.g.
timeout on internet connectivity downtime).

Or fewer free apps, I suppose. Either solution fits the new game theory
equilibrium. My money is on "Google is not going to martyr their ad-supported
app developers by rolling this into their Android OS builds", with a distant
second to "faux-permissions detection libraries".

~~~
aw3c2
Imagine you were visiting a free art exhibition and someone was constantly
shouting "BUY THIS PURSE BUY IT NOW!" into your ears. Probably a bad analogy
but maybe you get my mindset.

If you cannot sell your product, well, maybe it is not worth running after
profit. If you do not feel like sharing it for free, maybe someone else will.

I do not consider anything with advertisements (or "submit your mail adresse
to get the download link") to be free. The ad publisher is getting my
attention, personal data or whatever, it is not free of drawbacks for me.

Disabling parts of an application can hardly be considered piracy.

~~~
daeken
Let me play devil's advocate here for a moment.

You say that you don't "consider anything with advertisements (or "submit your
mail adresse to get the download link") to be free", so you consider your
agreeing to these things to be your payment for the software/service/whatever,
right? If so, by not viewing the ads, giving your email, etc, you're not
paying the price for the product and are thus pirating it.

You use a service that charges your credit card when you use it, but you
realize that you can block the call to the server that does the charging and
use it just fine. Is that acceptable? It's technologically equivalent to ad
blocking in reverse and blocks payment; the only difference is that the
currency is USD or EUR rather than eyeballs.

~~~
aw3c2
Ha, good catch. My argument crumbles to dust.

