6 ms·
CyanogenMod Adds Support For Revoking And Faking App Permissions on Android
- njs12345 15y agoI did something quite similiar last summer - we got it published (http://www.cl.cam.ac.uk/~arb33/papers/BeresfordAREtAl-MockDroid-HotMobile2011.pdf http://www.cl.cam.ac.uk/~arb33/papers/BeresfordAREtAl-MockDr...) 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 15y agoI 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 http://www.csc.ncsu.edu/faculty/jiang/pubs/TRUST11.pdf
- njs12345 15y agoThat 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/ http://www.appanalysis.org/
- ydant 15y agoI'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_thread/thread/eae545087448b1b1/9833ebc8a343674b http://groups.google.com/group/android-developers/browse_thr...) 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 15y agoI 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.
- wzdd 15y agoI remember that interaction. It seems like a feature that will work really well 95% of the time and give confusing errors the other 5% of the time -- a good trade-off for techies, but would result in many confused users if it were a core OS feature ("I just thought I'd see what it did...").
- mcantor 15y agoThis 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 15y agoalter your build.prop file
- AretNCarlsen 15y ago@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 15y agoImagine 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 15y agoLet 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.
- ck2 15y agoThis 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)
- ShabbyDoo 15y agoIt would be interesting to add logging shims to the APIs along with a GUI by which semi-technical users could audit apps' behaviors. Why does Game XYZ need to access the internet? To download new levels or for some evil purpose? A listing of domains it hit would be a telling sign.
- there 15y agowhispermonitor adds a littlesnitch-like gui to android to show and filter network connections: http://www.whispersys.com/whispermonitor.html http://www.whispersys.com/whispermonitor.html it requires changes to the framework though, so it's only available in their own "whispercore" rom: http://www.whispersys.com/whispercore.html http://www.whispersys.com/whispercore.html
- PassTheAmmo 15y agoI 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.
- ck2 15y agoI've seen some apps in the android marketplaces that do have descriptions which attempt to explain the permissions. I've also seen apps that have a "lite" version with much fewer permissions needed. But what I really want is the marketplaces to allow direct apk downloads because I always want to examine the file first on an emulator.
- baconner 15y agoAs a developer I've often wished for this. You can stick it in the app description but it'd be nicer if it was on the permission screen. Marking permissions optional would be helpful too.
- cjkarr 15y agoAs 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/ 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 15y agoI 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").
- topbanana 15y agoDon't the apps just fall over when they try to perform a revoked operation? I doubt they'd expect it
- kelnos 15y agoSo 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.
- aw3c2 15y agoIndeed, what a shame. Well, I hope some other ROM will integrate it then.
- guelo 15y agoWell 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.
- harshpotatoes 15y agoWell, the problem isn't that Android isn't 'ours', you can still do whatever you want with it. The problem is that the hardware you buy is never really your, thereby making it more difficult to install custom android onto.