We have half of the solution required for this - there exists a per-feature based permission model that the applications are already using.
The second half is simple but requires a change on the device side - if an application needs feature X, Y and Z, then the choices shouldn't be limited to grant access or not install the application, but there should be a third choice per each feature called "fake that access being granted".
If an app claims to need access to my SMS messages, then there are two reasonable options:
1. I want the app to read my SMS, as it does something that I want with them; so I enable that feature.
2. I don't want the app to read my SMS for whatever arbitrary reason that doesn't matter and doesn't need to be justified to anyone. If the app cooperates with the refusal, then it stops at that, but if the app wants to read my SMS against my will (and, say, tests this ability to enable some unrelated feature) then that's hostile behavior and all of my hardware and software should assist me in thwarting that hostile behavior - e.g. by simulating fake data to the app, by falsely claiming to have sent SMS / made a call, etc.
The other options (including the current scenario where my device cooperates with the app developer against me) aren't reasonable and should be eliminated.
One of the reasons behind this is location, where there are a class of apps which could conceivably rely on you not being able to lie about it. (The existing mock location facilities explicitly notify apps they are mock for this reason).
However, the use of this feature for it in practice is . . . non-existent.
Google also famously went crazy when Motorola almost used Skyhook as network location provider for the Droid, on the basis that such information feeding back into their systems might be inaccurate and thus pollute their data collection activities. (They use Android devices as modern proxies for the WiFi slurping the streetmap cars used to do). As such Google have absolutely no incentive to resolve this problem as they are reliant on you not lying to them about where you are.
What's fun is J2ME got this right. Apps couldn't just assume they had permission for certain tasks, and users would be asked when the app wanted to do something. If the user refused you'd get an exception, but you were expected to handle it gracefully. It really wasn't that big of a problem, except for the user experience of the prompts some manufacturers chose to implement being fairly horrible.
Android could shift to revocable "a la carte" permissions just easily, and could ease the transition by granting sets of permissions for old apps, but substituting, for example, an empty Contacts database for the real one if the user opts out of that permission.
Google couldn't even argue that getting fake data is harmful, as long as the data is forthrightly null or unavailable. Location apps have to deal with the lack of location data. Apps that access SMS have to deal with devices that don't get SMS messages.
I hope alternative Android distributions mature to the point that some OEMs will choose to provide more-private "remixes" of Android based on these distributions and on ecosystem partners like DDG.
>where there are a class of apps which could conceivably rely on you not being able to lie about it.
I don't think having 'mock' data is the right approach, but as you mentioned below, it's enough that the relevant API simply throw a security exception and let the app handle it gracefully.
>If the user refused you'd get an exception, but you were expected to handle it gracefully.
And that's absolutely the right approach.
>It really wasn't that big of a problem, except for the user experience of the prompts some manufacturers chose to implement being fairly horrible.
That should be handled by the OS, which would completely negate this issue.
Exceptions are not a solution - instead of the OS request "grant permission X to install the app" you get an app request "grant permission X to run the app".
This is the exact scenario that needs to be avoided - if the app developer wants something that I don't want to give, then you can't rely on cooperation from the app.
The whole point is that if a flaslight app wants to read my SMS, then I shouldn't have to choose between using that app and keeping my privacy; the OS is perfectly capable of keeping that app in an ignorant bliss thinking that it read my SMS and can turn on the light.
I got so frustrated with flashlight apps asking for Internet access to show ads and getting stuck when there is no Internet (typically the same time when I need a flashlight) that I wrote one and made it completely permission free:
I'll also note the TeslaLED app as another good one - it requires camera permissions to control the LED, plus screen drawing and sleep control - I suspect around the minimum that would be needed for a flashlight app.
This is what I've always used. LampA doesn't work on my Galaxy Nexus. I was hoping it would start up quicker because my biggest peeve with Tesla is that it takes time not only to open the app but there is a hundreds of ms delay in turning on the LED. I assume the complexities causing this are also what prevent LampA from working.
hey, this looks great, but it's not actually working on either on either of my nexus 5s, is that a known issue? There's no crash or anything, the flashlight just doesn't actually turn on.
because using system flashlight app is too edgy, huh? Why you need extra app for thing you have just build in Android ? Check your widgets for "Assistive light". Problem solved.
I'm in the "let them fake it" camp, but at the same time I think the exception throwing version could work, with a single tweak borrowed from iOS: Let the app ask for the permission once, and only once. That way repeatedly bugging the user for the permission won't work as a strategy.
The original article gives flashlight apps as an example - all of the top 10 flashlight apps had such features; so "downrating the app and moving on" wouldn't be productive at least the first 10 times.
A feature that could disable certain permissions for a single app was briefly introduced in an earlier version of 4.3.x, but was removed again shortly thereafter. Apparantly, most apps were written to expect permissions to be granted and crashed pretty hard if they didn't get their way.
It is available for rooted phones running Stock Android through the Xposed framework. There it is called "AppOpsXposed".
I can understand that disabling permissions the app expects will fail, but faking the service the app expects permission for sounds like something that should work, and would be very valuable.
Yes, definitely. XPrivacy can fake data, so that works even better than AppOps, but is harder to set up.
I also miss the possibility to give slightly fuzzed/offset values for certain things, like GPS granularity (Do you need to know my exact location, or just my country?) There's however an eternal struggle between the API devs wanting to make the permission system simpler, and the APP devs wanting it smarter and more refined.
> "as CM and google got more in bed that feature vanished for a while."
Is there any evidence for that? My impression (from following blogs, G+, Gerrit, etc) was that CM simply couldn't keep up with adapting their features to new Android versions for a while, and the only reason the CM11 branch is reasonably stable is because KitKat has been out a full year.
If the app is not willing to function when being denied SMS access it should simply not be allowed on the app store. I have yet to meet an app on my iPhone that shuts down unrelated function because I denied it access to my calendar, SMS or phonebook.
I think "fake it" is a fabulous option, but I'd like a "tell the app it's denied" option as well. The latter would let honest developers provide a better experience. Also maybe an "ask me each time" option.
The problem with faking the data is that users are likely to pick that option, forget that they did and then when the app fails in some way they will give it a 1* review.
I would rather have fields where the app developer can justify why they need each permission.
The current problem cases are those where either the app developer can't justify it (flashlight app example in the original article) or is ready to write up actively misleading justifications (purpose-created apps with malware).
Your proposal would help only in combination where after seeing the justification, users can still choose to fake the data anyway. And if the justification isn't obviously acceptable, then a 1* review is a feature, not a problem.
Wouldn't the justification in the case of the flashlight be that they need to mine the data to keep the app free, which would at least be honest. Though gutting misleading apps from the store would be difficult.
I'm concerned more with the problems an app with a legitimate use for the data might have when the user tries a certain feature and it doesn't work properly or worse causes a problem by doing some important operation with the junk data.
If the app doesn't have my consent to have the data, then any attempted use of this data is illegitimate. If I don't want a flashlight app to view my private data, then they don't have my consent no matter what bits the phone and OS sends the app.
That's the key point of system ownership - if the developer of the program wants it to do A, but the owner of the system wants their phone to do B, then doing A is a bug that needs to be worked around. Even if it was explicitly designed and implemented that way, from the viewpoint of the user this is an anti-feature; and the current system architecture that favors the will of the app developer over the will of the user is certainly feasible, but it explicitly means giving up control over the system. And that, IMHO, needs to be fixed.
It's similar to opt-out permissions for email marketing - if some company managed to get "permission" without meaningful consent, it doesn't give any permission and their actions are still immoral and, in some places, illegal. Or click-wrap agreements "signing away" basic consumer rights that (in some places) can't be signed away - again, formal "permission" doesn't imply real permission.
The issue is that an unsophisticated user is unlikely to understand the relationship between permissions required and functionality that can be provided, let alone recalling which permissions they gave to which applications months later. Leading to confusion about why an app doesn't work. The worst part is that junk data will cause the app to fail silently and misbehave in unexpected ways.
The business model now is that despite buying a device outright, you never really "own", it, it is always controlled by the vendor. It started with DVD players that you might have physically owned, but would refuse to e.g. skip over the ads on a DVD. This is just the next level. Your hardware and your OS are NOT on your side, haven't been for years.
> If you have any doubts, then I recommend you download DCentral1 (A Future Tense Central product) from Google Play, and let it scan your Android phone or device. It will tell you exactly what every app you have downloaded has asked permission to do – and you will be shocked. DCentral1 is my own app, and it asks for no permissions, as you will verify prior to installation.
I'm surprised that looking at the permission settings of other apps does not require permission. Knowing which apps someone gave permission to access their sensitive data can tell a bad guy which apps to try to exploit to get the user's sensitive data. It probably also leaks some information about the user. I'd not be at all surprised if there were correlations between permissions granted to specific classes of apps and things like the user's age or gender.
I'm surprised that looking at the permission settings of other apps does not require permission.
I'm surprised getting a list of installed apps does not require permission. The access settings for each app are the same for everyone and public anyway (99% of the time).
It defaults to a silently fail permission policy, and notifies you when an app is requesting access. You can then chose to deny, allow, deny always, or allow always.
It's the antidote to Android's insane security model where all users see is "do you want to be able to run this app?".
Second this. Privacy Guard in CM11 solves this and is quite simple to configure. Add to this Droidwall and whitelist only the apps you need and you have a fairly god setup.
The interesting thing is that while we now think all required permissions are ridiculous, there used to be no permission system at all. None of the popular desktop operating systems offer any permission model beyond limiting a user's account (and I myself certainly want to have access to my own contacts - but do all applications?).
So it's a very good step that there is a permission model at all. Now it's time to refine it, iterate improvements, and make it the way it should be. Broad permissions like filesystem access merely to save or open a file (such as a document) could be removed altogether if there is a basic system component that lets the user pick the location themselves. Or access to the camera could be asked for by the OS every time an app requires it, or at least it could be logged and display a notification.
To be fair, Desktops don't have as much of detailed look into our lives. SMSs are very intimate, location data can pinpoint you at almost any moment, and ( for me ) i know my address book on my phone is 10x the size of the address book I had on my computer before my phone started syncing contacts across. I think it's a great direction, but one that is now more necessary than ever.
Currently it's Location, Contacts, Calendars, Reminders, various internet accounts (Twitter, Facebook etc) and Accessibility - which is required for an app to read/control what's on screen.
A lot of game launchers (Origin, WoW at least) ask for accessibility permissions to do their anti-bot/cheating checks.
As said above, mobile apps have had permissions systems for a while. Besides J2ME, my pre-iPhone Nokia S60 already asked me if I wanted to allow access to my files, contacts, etc.
This is the primary argument for Apple's AppStore and App submission guidelines, and the evaluation (much of it automated) that Apple does upon submission.
This is also why iOS prompts the user before disclosing information to the App, such as location, contacts, photos, etc.
People hate the review process, but there's a reason for it.
Maybe if we make a habit of it, it’ll help a little bit. I think most devs say “give me all the permissions” out of expediency, and most users say OK for the same reason.
Is there such thing as graceful degradation here? If I say yes to Location, but no to Contacts, the app should still function but the bits that need the Contacts would be unavailable.
Or, it asks for those permissions when, and only when, it needs them.
This is an app for booking doctors appointments online? But you don't think it should have access to your id, location, wifi? Why is that unreasonable. The only strange one is the photos access.
Hey! You know the really neat thing about the Internet Of Things is that manufacturers really could start requiring all kinds of things in their TOS to use the physical item!
Why, you could have the device only work in certain regions, requiring new fees for new regions if you move!
You could enable features only if additional fees are paid! Free2CooK (broiling available for just 60 credits)!
Monthly subscription fees!
You could cross-market, requiring access to read information on your pocket computer (phone), in order to control your device!
Oh man, The Internet Of Things is gonna be so awesome!
The door refused to open. It said, "Five cents, please."
He searched his pockets. No more coins; nothing. "I'll pay you tomorrow," he told the door. Again it remained locked tight. "What I pay you," he informed it, "is in the nature of a gratuity; I don't have to pay you."
"I think otherwise," the door said. "Look in the purchase contract you signed when you bought this conapt."
...he found the contract. Sure enough; payment to his door for opening and shutting constituted a mandatory fee. Not a tip.
"You discover I'm right," the door said. It sounded smug.
If applications from the play store reading your SMS messages bothers you, then I can recommend using something like CyanogenMod's Privacy Guard (which exposes a feature called App Ops that seems to be a part of Android, yet hidden), or Xposed framework's XPrivacy (which gives you very fine-grained control over what information/permissions apps can and cannot access).
XPrivacy is difficult to configure without reading the documentation.
The idea with Linux is that you contribute your time to the project or helping others. That's how you pay. If you don't do anything of that, you are freeloading.
True, however it should also be common sense. Too many people expect something for nothing. The entitlement mentality. When a company that makes their money on target advertising offers you a free email account, it doesn't take a rocket engineer to understand that there's likely some reason for that "free" account. But, I'm convinced that 65% of the general population is as dumb as a box of rocks. That's the only thing that can explain why the Jersey Shore and the Kardashians made so much money.
"those who give some freedom for security will have none of both" or so.
you gave up the hability to install apps from anywhere (to the point that if im at yelp own site for example, all the links to install their own app only takes me to app or play store) in exchange of the false premise that the downloads would be verified by apple/google as to not harm you. in the ens you just lost your freedom to do as you wish and now you are more exposed to threats because you assume they are safe since they came from the "official" place.
On Android you don't lose that ability. There's even a repository of FOSS apps (F-Droid). All you need to do is toggle a checkbox in the Settings menu.
I think the fundamental problem is that Android permissions (and privilege controls for most other platforms) are far too coarsely-grained.
I'm perfectly happy to allow an app to save files to a specific named folder on my device. I'm perfectly happy to grant access to my camera when specifically prompted for barcode scanning or what have you. I'm happy to allow an app to check whether I'm on 3G or Wifi to save on data costs. Android permissions are currently far too binary. Permissions need to be more specific and explicit, atomised down to the finest possible gradations; The permissions dialog needs to clearly explain precisely what is being accessed, with extra resources available to help the user understand the privacy and security implications.
This frustrates me both as a developer and as a user. As a user, I avoid all sorts of apps that are probably requesting permissions for good reason, but that I don't really trust. As a developer, I find myself leaving out potentially useful features so that I don't present the user with a laundry-list of permissions.
I fastidiously explain exactly why my apps require permissions in the app description, but I shouldn't need to and my users shouldn't need to trust me - I should be able to specify the exact subset of functionality needed by my app and my users should be able to grant me that and only that.
Users should be able to reject or falsify any API request at will, and the SDK should be designed around this; Appropriate and flexible exception handling for API calls should be mandatory, with UI to alert the user if functionality is unavailable or unreliable due to their privacy settings, and with the option to allow specific access on a case-by-case basis.
As an industry, we need to look past our short-term lust for analytics data and ad impressions, and think about the future of computing. I think we are grossly underestimating the importance and urgency of user trust, which is hard-earned and easily lost. With the increasing ubiquity of computing and recent revelations about surveillance and leaks, we need to be making bold decisions to empower users to control their own data and devices. The future of computing is truly bleak if we cannot truthfully convince users that they are the masters of their devices and not the servants. Without decisive action, we risk a catastrophic and wholly justifiable collapse of trust that could set us back decades.
For a crazy guy I like what McAfee is doing :-). The "FM Radio" app which Motorola installs on the Moto-G wants to upgrade on my phone, but it wants "Device ID & call information, Camera/Microphone access, and 'other'". Really? Why does an FM radio need my camera and microphone? And who I call? And my device's id? And what the hell is "other"?
No. Government isn't the answer to most problems and certainly not this. The market fixes this. If you don't like the terms, don't use the app. As soon as "legislation" gets involved, then suddenly app developers are now under the same type of regulation that covers medical devices, etc. That's a huge burden. Imagine the patent trolls -- they use patent legislation to attack developers (often small indy shops) that "potentially" have infringed on some patent, despite the fact that the developer didn't even know a patent existed and the technology involved is sufficiently ambiguous as to be case based more on the financial resources of the participants rather than the merits of the claim.
With this permissions legislation, an app that does legitimately request a permission might have increased lawsuit exposure because of someone's interpretation of what the permissible purpose of that permission might be. Even if the developer is "right" they still have to spend thousands of dollars they likely don't have to defend themselves. We have patent trolls -- what's next, permissions trolls?
The free market is the answer. However, education of the public is necessary for them to realize the tomfoolery in which some apps engage. However, all the education in the world is unlikely to help -- this "general public" we're talking about is the same crowd that plays Farmville and Candy Crush.
iOS is a bit more "safe" in the privacy regards because each app must explicitly request permission for a specific use and Apple is rather rigorous when you attempt to use a permission outside the scope of the app. I don't know anything about Android, but if it covertly enables a permission without the user's knowledge, then that's something Android should fix. But legislation? Hell no. I don't trust legislators to paint white stripes on the road correctly, let alone pass laws about technology about which they are demonstrably ignorant much of the time.
There is no law of nature that suggests a free (laissez-faire) market fixes anything. More specifically, that style of pure capitalism only has one inherent trait: capital tends to become accumulated. While I, personally, think this kind of unidirectional focus is not healthy in the long run, the amount of regulation needed to mix into a market is a difficult and open questions.
> might have increased lawsuit exposure
Yes. That would be the entire point of regulation. You follow the legislated regulations or you get hit with some sort of lawsuit or fine or similar.
> because of someone's interpretation of what the permissible purpose of that permission might be.
I agree! This is a very difficult problem to describe in a clear, reliable manner. I suggest that the industry should be proactive on this; it would be a lot better if the people with the technical knowledge came up with some sort of permission scheme that avoided ambiguity and more accurately reflected what types of permissions the applications actually use.
The alternative is to wait for some well-meaning but technically inept legislation, and all the idiocy it implies.
> education of the public is necessary
Absolutely. This is always of vital importance.
> I don't trust legislators
Neither do I - which is why it is important to beat them to the punch with your own solutions and legislation.
"we had to create the future, or others will do it for us"
- Susan Ivanova, "Sleeping in Light", Babylon 5
I dont install app which requests excessive permission. My Lenovo phone has application firewall, everything is blocked, except two white listed apps. My /etc/hosts has 3000 lines...
This reminds me of the infamous HN response to Dropbox's launch 5 years ago:
> you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem
I remember my blackberry would ask all kinds of permission prompts whenever I installed a new app. It was a pain, but now I see how bad it can get when you don't do it that way.
The second half is simple but requires a change on the device side - if an application needs feature X, Y and Z, then the choices shouldn't be limited to grant access or not install the application, but there should be a third choice per each feature called "fake that access being granted".
If an app claims to need access to my SMS messages, then there are two reasonable options:
1. I want the app to read my SMS, as it does something that I want with them; so I enable that feature.
2. I don't want the app to read my SMS for whatever arbitrary reason that doesn't matter and doesn't need to be justified to anyone. If the app cooperates with the refusal, then it stops at that, but if the app wants to read my SMS against my will (and, say, tests this ability to enable some unrelated feature) then that's hostile behavior and all of my hardware and software should assist me in thwarting that hostile behavior - e.g. by simulating fake data to the app, by falsely claiming to have sent SMS / made a call, etc.
The other options (including the current scenario where my device cooperates with the app developer against me) aren't reasonable and should be eliminated.