None of the above. It is a hard UI problem to present the plethora of different features that need access control to the user such that they can meaningfully engage with each one.
For example: which of the following permissions does the Facebook app currently get on Android?
I bet you don't know off the top of your head, and I'm certain that fewer than one in a hundred users do.
This is not because Android team is lazy. All of this information is already surfaced to those who care to look, right there in the play store app. There's a spectrum of options between removing capabilities, presenting them in more detail, and providing a UI that doesn't make people's eyes glaze over. There is a constant tension among these three poles, and no matter where you are, there will be some use case that isn't served well.
No, permissions were done in a substantially more granular way on iOS from the beginning of permissions. Contacts, photos, location, notifications all with their own permission request API to be fired at will.
Android started off with a blanket permission screen required to even install an app — all or nothing.
I don't think granular is the right word here. Android defines something like 150 permissions, so granularity is there.
The issue is (in old versions of Android) you cannot be selective about which ones you grant.
The relevance is that when it comes to transparency, the big dialog of all permissions can disclose a fair amount of detail to the user about exactly what they're being asked to allow.
iOS isn't more granular, it just defers permission requests to the app rather than the app store. In proper practice that app then only asks for permissions when the user is performing an action that requires them, which at least helps the user to understand why they are being asked. Android has now shifted to this model too, but as always, old versions of Android persist.
There is some truth to that, but it's not that hard of a problem. Start by making a dependency tree, and only displaying the top nodes. "Do you want to share anything with app X?" yes/no and go from there.
Often the "it's too complicated" excuse is really a cover for "we make out money off your data and fund the development of this software to harvest it".
No, "it's too complicated" also recoils on consumers. I don't think your proposal would change behaviors.
Mass market customers don't read contracts and readily give out SSNs, credit card info, and other personal identifiers.
As a law prof. at NYU said,
>“For the most part [having read the contract] doesn’t matter,” she said. “Things don’t usually go wrong — except when they do. And then it matters.”[0]
Permissions are not long contracts, they fit in a single sentence. My super obvious suggestion further simplifies it. There's no reason a dep tree cant be made. The "people are too X" does not work.
My point's intent was to argue that consumer behaviors (not just those of firms) also shape these outcomes.
Do you have any studies or sources that support a permissions dependency tree approach for mass market customers?
I like "just-in-time" permissions (i.e. This app wants to use your location. yes/no?) That way, you aren't faced with accepting or not using the service at all, at the outset. [0]
RE studies: As far as I know it has never been tried. Dependency trees are common elsewhere in the software world.
This "just in time" stuff is awful, in it's simple form, the user only has to click incorrectly once. The obvious way is a dep tree. Start with:
"should any app be able to download your contact list?"
if no (global!!) -> "can I have one contact right now" and tag that information for the provider "I don't expect you to keep this" or "please keep this info and use it to market to me". Really, it's mostly just excuses, there is no reason to upload the data 99% of the time, only the local software "needs" it for a instant, and even then, that's because the OS stack is designed wrong. I don't want new law to mandate this stuff, I want users to demand it with existing contract law.
Making it "per app" instead of global settings with very deliberate and specific (one time unless instructed otherwise) exceptions is exactly what I would do if I wanted to design a system to maximize my user data snarf ability.
Android is new, nothing is "great" at first, I'm not expecting it to be right yet, but ignoring obvious fixes like this going forward is (hopefully) going to give it's forks more power.
I'm confident that you would not consider it so easy if you had ever meaningfully engaged with this problem. The simple fact is no one has cracked the nut yet, and not for lack of trying. Either it it is hard, or everyone who has worked on mobile device capability systems is evil or incompetent. I think the former is more likely.
Ok but then I really don’t want to read any more crap article about why Apple is lagging behind because their approach to privacy is restraining them to harness the full power of machine learning bla-bla-bla
It is fine to want things. These articles are as well founded as those that complain about the way Android does permissions. In that, they inform us about the spectrum of possible preferences among users. But inevitably every user considers only their use case, not how fixing it might break other use cases.
Are you claiming that there is no dep tree to be made? That's trivially false if so. Feeding apps fake data (for example to make them work with no data perms) has been suggested too many times to count.
Did you mean to respond to some other comment? In this thread, we are talking about cell phone permission systems. We are not talking about a "service," and the system in question is not something one buys or gets for free on its own.
I'm sure, there's cases where they just didn't want to have too many prompts, as that would result in people not reading them either.
But in other cases, this is also just Google that we're talking about. There's for example a presentation [1] where a Google dev introduces this new permission system and afterwards someone from the audience asks, if it's also possible to block internet access with it.
And the Google dev responds in the most innocent of ways that it doesn't need to be possible, because clearly the rest of their permission system works so flawlessly that no critical information one could want to upload to the internet would be available to apps anyways.
I know, never attribute to malice that which is adequately explained by stupidity, but it's not like the guy should be able to be this ignorant in the position that he's in. And Google does have reason to be malicious here. Without internet permission, their ads can't be displayed.
Especially the example in the video of the flashlight app is one where the permission system falls completely flat. In order to toggle the flashlight, you need to ask for full access to the camera, meaning you can take pictures as you like. And since you have internet, you can actually do something malicious with those pictures, too. Clearly, the user did not intend for their flashlight app to take pictures and much less so for it to upload them to the internet.
^this. As long as Google remains an advertising company with some incidental technology projects - they'll be hard pressed to ever fight internal culture/revenue enough to take meaningful steps towards privacy and security.
Just being able to write an app (code on the device) and deploy an ad (code on the Internet - possibility to run "code" like fonts, or trigger calls to site/unique.jpg) - would make preventing data exfiltration and/or tracking absurdly hard while continuing to cater to advertisers aka the paying customers.
The Android permission scheme is slowly becoming more granular. I'm not sure what the reason was from the beginning to have such generic permissions.
When you saw large lists of permissions on apps before marshmallow, you had to accept them all, now it requests for each on first use but I'm still not a fan of apps that want everything.
Android is a decade old. Our expectations of what apps would and wouldn't do, and would and wouldn't be capable of doing has changed. Back when the apps on my phone were in the range of being 400 KB to 600 KB, I don't think people even fathomed the complexity and power our devices are at right now, and their ability to secretly handle ever increasing amounts of our personal data without having a meaningful impact on device performance.
I never expected pine to upload my contact list (or email) to some third party server - or BitchX to steal my chat logs. Yet both programs could have done so.
The difference is that before Android, in the world of windows - we already had a culture of spyware bundled with freeware - as well as viruses/RATs - and plain malicious software -
that made it plain that simply allowing random code to execute in a context where it could read data and/or sensors (gps,mic,camera etc) would be a disaster.
There were to workarounds: stewardship (the Linux distro model, like software in debian main etc) or sandboxing.
Android chose too little of each, which essentially amounted to a false sense of security. And here we are.
It's not meant to be an excuse, Android has not aged well, and Google has done a poor job putting security at the forefront of their platform. Apple's taken a lot of flack over the years for making developers jump through new hoops all the time and having such heavy restrictions on their platform, but its clear the users have benefitted in other ways.
iOS had it's own issue, where Path uploaded a user's entire contact list without needing to ask permission for it. That was a wakeup call for Apple, and it should have been for Google too.
