Some users would never even install apps that asked for too many static permissions on the Play page.
But now, if an app seems to meet their needs and they aren't sure, some of them will go ahead and install it just to try it out. How much can one run hurt after all? Due to unresolved questions or sunk cost dilemmas, they may even grant dynamic permissions. How much can one run hurt after all?
So this will manipulate a percentage of reluctant users into data-providing users by hiding a reason for their reluctance. I'm inclined to suspect it'll benefit Google's ad impressions business and that's the actual motivation, not "feature parity" with Apple.
> Some users would never even install apps that asked for too many static permissions on the Play page.
This, so much!
Like 90% of the apps on Play ask for an insanely excessive amount of permissions.
It was the #1 indicator for sorting out garbage apps.
Example: Some time ago I needed a kitchen timer app (stock one had some issue). The great majority of them wanted permissions like contacts, access to my files, GPS location, and on top of it internet to upload all of this probably. Even though a kitchen timer shouldn't require any private data at all!
Now think about this:
Even if you're asked by Android before it actually gets the permissions, why would you WANT to run code from someone who does such shady stuff as having a kitchen timer require access to private data? Won't those people probably take any opportunity they can get to do shady stuff with things for which Android doesn't require permissions yet? And even if they don't - isn't it likely that their app just doesn't work properly and has a lot of bugs because they don't care about the user at all?
And this isn't just such utility apps. It's basically ALL apps which are flooded with this garbage.
What Google did here to me personally is the last nail in Android's coffin. I cannot acquire software anymore like this.
Problem with free software is that very often good programs are orphaned by original authors (looking at andOTP), and that creates more forks with usually even shorter lifetime. It would be wonderful to have some sort of organization for essential applications that provide crucial applications, but only with very limited feature set and only required updates for new Android versions.
> Example: Some time ago I needed a kitchen timer app (stock one had some issue). The great majority of them wanted permissions like contacts, access to my files, GPS location, and on top of it internet to upload all of this probably. Even though a kitchen timer shouldn't require any private data at all!
That's completely legitimate. It needs those permissions to tell your guests when dinner is ready, where it is being served, and what is being served.
More seriously though, I bought a tablet many years back which shipped with a simple word game that had insane permissions. Among them was access to contacts. When I pointed that out to people they would claim it was required for multi-player support. When I pointed out that one could add the contacts manually, most of the people thought I was insane even though this was at a time when people usually added contacts to desktop applications manually. They didn't understand that some people viewed it as impolite to share contacts of others without their permission (never mind the privacy implications). They didn't understand that most people would only play the game in single-user mode because it was a single play game with a "multi-player" mode tacked on. The multi-player mode was literally tacked on to harvest marketing data.
I've never seen that in any menu or prompt. I don't think Android has this. Which is a shame bc i mostly use offline apps and would love to know if an app is all offline
Understandably, I don't think Google cares about the offline use of their OS. It doesn't align with their business interests
What they really need to do is to simulate data for permissions that are rejected.
For example, if I reject location permissions, then play back a random GPS trail in a randomly selected city on the planet, complete with simulated error and drift. If I reject Wi-Fi scanning, then show a constantly changing set of fake access points. If I reject camera, then play back some cartoons or deepfaked video as a camera device.
The app should never have to know its permission request was denied.
This would be a nice option to have, but it's only useful for a small number of tech affine people who know what they're doing. If the location doesn't agree with the IP address, the app would know it's not real. And if this is used with banks or payment services people are going to get their accounts disabled.
In general, I'm not sure spreading random fake news about yourself is such a great idea unless everybody does it. And everybody doesn't do it, because if everybody cared so much about these things the problem wouldn't exist in the first place.
If you do that, some users are going to land in a weird purgatory where they’ve denied camera permissions to their camera app or something, and be completely unsure of why the app is acting strangely or how to fix it
On a related note, I don't understand why apps are permitted to require you to enable certain permissions or refuse to run. What is the point of giving users control of their privacy if large popular apps are a able to essentially opt out of the optional part. I'm looking at you Kakao.
This case is clearly better on iOS. The AppStore guidelines require that your app functions regardless of whether the user consents to permissions. None of this bullshit “oh you denied this flashlight app contacts permission? Fuck you exit(0)”
The Google Photos app on iOS is still an egregious abuser of this, requiring access to all photos to run at all, rather than just selected photos or no photos at all. I’m still not sure why it would need that if I only intend on using it to access shared albums in the cloud, download photos, or view selected photos on my device, but it’s Google so I’m not terribly surprised.
Agreed for optional permissions, but not sure what you'd expect a browser to do that doesn't have internet access or a camera app that is not allowed to access the camera
Allow you to open the app still and go through the menus, maybe you just want to export your data? Maybe you want to check the T&C again (which should be available offline from the menu)? Perhaps you wanted to see the design/ergonomics of the app before allowing it? It could be a thousand reasons. Photo app can display "No camera permission granted, click here to setup" instead of the visor or something, and the browser can also inform the user of the situation with a static page.
It's like proper exception handling: Do not just close the app, fall back gracefully and allow the user to retry.
I'd expect the browser to behave the same way it does when the device is in airplane mode: display a message about being offline, while still letting me play with the UI, adjust settings, navigate to local files and cached pages, and so on.
For the browser, view local HTML pages via file:// URLs. For the camera, look at previously-taken photos through the built-in mini-gallery that most support.
In the example of Kakao, it lists the contacts permission as optional and the app will install and open without it. But it won't let you past a nag screen without it first verifying that you have given it access to your contacts.
Really anything involving personal data should be up to the user. Especially something like your contacts.
As much as I have a problem with Apple’s monopolistic control over the App Store, one benefit is that behaviour like this doesn’t make it past review.
I’d love to see a button on the contacts permission window to give the app a list of AI generated fake contacts. (And fake GPS coordinates, and so on).
Philosophically, your phone should be your user agent. It should act on your behalf, not on behalf of some tech companies.
Xiaomi's newer phones do have this functionality, albeit in a rudimentary form (only empty list is returned so the app can still detect it given how few people have empty contacts).
There should be a simple standard way to fake/limit all permissions.
For example, the app wants to access your contacts. Instead of "yes or no", you choose a subset of contacts that the app is allowed to see: could be all, could be none, could be a selected set (perhaps a special set of fake contacts). Whatever you choose, the app is told that these are all the contacts that exist on your phone.
If the app wants to access the camera, the options are: actual camera, always black pixels, a selected static picture, a selected picture that is shaking to add extra realism. Whatever you choose, the app is told that this is the actual camera.
If the app wants to access the disk, you could specify that a new directory should be created and the app would be told that this directory is the entire disk. Etc.
I know this doesn't help the average user, but https://exodus-privacy.eu.org/en/ does their own analysis of apps and lists permissions and sensors. You can check here first. There reports are integrated into the Aurora Store.
What I always found very confusing is that apps on Android can either read all of the SD drive or nothing. Wouldn't the normal approach to gate applications from each other be to give each one the right to access a single directory?
The way it is, all apps want to "READ_EXTERNAL_STORAGE" so they all can read all the data I save.
This is being clamped down on, at least for apps on the Play Store. How it works now is the app has unfettered access to its own internal and external storage directory, and can prompt the user to select another one to give access for saving additional data. There are some rough edges for implementors, though; for example, getting your content to show up in media player apps requires usage of a completely separate API, you can't just save data in the Music or Pictures directory.
The basic idea is okay, but the practical implementation is terrible. There's additional overhead which slows down operations that need to touch lots of files, they've broken access via the standard file APIs while at the same time other Android APIs still only support standard files, the much touted media store mainly only caters for standard media file formats (i.e. images/audio/video), plus some standard "document" file formats, but good luck if your file type is too exotic (at least on my – admittedly somewhat older, though – phone even .EPUB files are already too exotic to be indexed by the media store), they've broken simple file sharing between multiple apps and effectively encourage apps to create their own private copy of such files, which is bonkers and for larger files unnecessarily takes up time and storage space, they've especially broken sharing multi-file file formats between apps (especially including the case of using a file manager app to browse through your storage and then directly open such a file in another app), …
I suppose the most common "regular user" scenarios sort of mostly work (except possibly for some performance overhead in some cases), but for more "power user"-like usage scenarios it's all too easy too run into all sorts of edge cases, limitations, and bugs that break your workflows.
Apps haven't needed this permission for most use cases for 5+ years now... only now is the ability to request it being taken away from the last ones (unless they have an exception based on a legit use case like file managers)
Funnily enough, that's exactly what Apple started with on iOS: each app only has access to its own sandbox. And it was derided by Android fans for being too restricted.
This is the new "security". Phone needs access to camera and storage although it cannot make video calls or record a conversation. Messages needs access to camera and microphone. Play Store needs access to everything. All the time.
Working some jobs at Google, Microsoft, Facebook and Apple must be a pedophile's heaven.
> To give users more control over their files and to limit file clutter, apps that target Android 10 (API level 29) and higher are given scoped access into external storage, or scoped storage, by default. Such apps have access only to the app-specific directory on external storage, as well as specific types of media that the app has created.
If you really want to get into the weeds, previously you could work around scoped content requirements with the manifest property "requestLegacyExternalStorage"
But it's not respected if your app targets the latest version of Android, and new uploads have to target a recent enough version that the loophole is closed.
This is one reason I switched to F-Droid a while ago. Among other things, F-Droid is very strict about reporting potential anti-features, which (ironically?) makes me much more comfortable installing apps from that app-manager.
What they really need to do is to simulate data for permissions that are rejected.
For example, if I reject location permissions, then play back a random GPS trail in a randomly selected city on the planet, complete with simulated error and drift. If I reject Wi-Fi scanning, then show a constantly changing set of fake access points. If I reject camera, then play back some cartoons or deepfaked video as a camera device.
The app should never have to know its permission request was denied.
There's two ways Google could solve that: either make better fake data that isn't trivially detectable, or make a rule that trying to detect that gets your app banned from the store.
That would be a fun challenge: given access to all sensors except for the camera, write an app that creates fake camera data.
If Google worked on that, results could be fairly creepy for those who store their data in their cloud. They can probably infer what you look like from your photos (you’re the one appearing in selfies most), know what weather it is locally, know that you’re, for example, looking at the Eiffel Tower, and maybe even have a photo from 2 minutes ago made by another user from the same place.
I think Google certainly could make a fake address book that’s creepy for many users by looking at the address books they have.
The permissions list on the play store was completely useless from a privacy standpoint. Even power users could to just about nothing with the info.
The situation now where you approve or reject permissions as they are used in the app is vastly better than the original android model of being shown a wall of text with the options to either give away all of your data and security or not install the app.
I used them as a signal of the developer's intentions. An app that asked for too many that I couldn't logically relate to the app's features was a red flag.
There was no reason to remove them from the store page. In general, there's no reason to remove additional information, that too info which was already hidden behind an obscure button that only a few power users ever checked. The dynamic permission model is the better runtime one but there's no good-faith justification at all to delete information about permissions. The latter is like the documentation for a feature and removing it is like hiding documentation.
The permissions list allowed you to make a better-informed decision before you download the app, even though you can't change what permissions an app requires you could shop around for apps without specific permissions. This was never incompatible with ad-hoc approving or rejecting permissions either.
This only works for utility apps which are really the minority of apps that users install. There is only one app to access my bank account, there is only one app to stream netflix on, there is only one app to access government services on.
Outside of flashlight and QR scanner apps, there is basically nothing the user can action aside from completely rejecting the wider service over some ambiguity in the permissions list.
Aside from utilities many games have lots of similar competing products where you can differentiate on permissions/ads/in-app purchases/etc: crossword puzzles, sudokus, games for younger kids like dress up or coloring in stuff.
> The permissions list on the play store was completely useless from a privacy standpoint. Even power users could to just about nothing with the info.
This is not true. I avoid apps that require unreasonable permissions. I don't expect regular users to know what is reasonable or not, but hiding this information would definitely make installation process less convenient for me. Then again, I no longer use Google Play store and I install very few apps anyway, so maybe I'm not exactly their target user.
you bet I'd never install a TODO app that needs to read my phone contacts in the past. It's not even possible to see if apps have in-app purchases anymore on Google Play.
It was only useless for you, I don't have time or KB to waste on my data plan.
I remember the situation where Google used to bundle permissions in illogical ways. it's been too long to remember specifics but it essentially meant an app had to request the ability to access unnecessary things and required the dev to explain in the release notes as to why.
Usually they weren't illogical but they were hard to understand for the user. Bluetooth scanning for example requires the location permission for example, which seems illogical until you find out that advertisers worked out they could put bluetooth beacons all over the place and track the users location by checking which beacons are in range.
So apps have to request all these scary permissions so they can do regular things. But there is really no alternative.
One example I remember is that music players used to require reading the phone status in order to be able to pause playback during a call. I think these days you can mostly get by using the audio focus APIs instead, but historically that wasn't the case.
I teach digital literacy courses for seniors. The Play Store is such a nightmare for me. What used to be a lesson on basic app installation has now become a safety lesson on how to be careful in the Play Store. It's a minefield of scammy apps.
This is similar to either the Microsoft Store or Apple App Store (can't recall). You used to be able to see what in-app purchases were available, to determine if you weren't ripped off downloading this app. Now you can't.
in unix, xattr and setfattr drive me crazy. As a PM, I do sometimes realize that the UX drive here would be "lets just remove these extended attributes, people hate them" instead of thinking about what they do, and how people (mis)understand them.
I think Android permissions are like xattr. its the noise behind chmod, it shows up in odd ways like when you can't move or delete a setuid file, or in ls -<flags> contexts if you tickle it right. its the nitty gritty, the details. Not "does this s/w respect my privacy" but "of 100+ distinct attributes, data items about 'me', can I atomically grant/deny access or apply some conditionality to them"
So I think the same thing about AWS Privs. My god, theres a million of the suckers. Do I want Amazon to simply remove the pane? God no. I just want to understand it better.
Why can't google "do both" and have a path to see these, but feature-parity with Apple and simplify it on the surface?
That first time you think you've upgraded your BSD operating system and three mysterious files refuse to go away.. which is precisely how I first found this, as you say, immutable file problem.
My idea to improve the issue is the following: an app asks for permissions and you as a user get two choices: grant the permission or grant mock permission. Mock permission gives access to some random data that like stock contacts/stock photos/whatever.
Every app is required to work correctly with the mock data or is removed from the store. You could even have mock folders in the photo app or mock contacts on your phone so you as a user can see how the app works on those without giving it access to the real stuff.
Example: a parking app asks for access to your contacts and ability to call, you give it a mock permission. It just works. When it tries to call someone you see info: "app XYZ calls mock contact A". When it tries to read your contacts it just gets a stock list. If it tries to tell you it needs real contacts you report it to Google and it gets removed.
right, since the popup for permissions is in the app when its requested
I would like more permissions to be different than all or nothing though. I wish you could segregate contacts. like, if I don't tell people around me that I know a high ranking official, why should a random app just because one of us uploaded our contact list.
That's only for 'dangerous' permissions as defined by Android.
As an example: NFC is defined as a 'normal' permission.[0]
As far as I'm aware [not an expert here], there's nothing stopping an app developer from updating their app with the ability to steal credit card/passport information (if the card is tapped against the phone).
Credit cards can not be duplicated wirelessly. I’m not familiar with passports but if they can then I’d say that’s a flaw of the cards rather than phone permissions. It’s possible to read nfc cards from quite a distance with a high power reader.
Someone else can probably give the technical details but from my understanding, all but the most primitive NFC cards use a challenge/response system rather than just an ID. So there is no way to actually clone the secret stored internally as this is never transmitted.
I'm willing to bet that video is just plain fake. Especially given it only has 2k views.
I mean Apple still manages to list all IAPs even those only happen on prompt.
The thing users want isn’t what permissions the app could possibly request, but what permissions are required to use what specific features of the app.
Absolutely! And if the features are at all usable/trial-able or need an in app purchase, and is useless without. I feel tricked so often. Currently I need to install an app and try it before I can have much idea if it does what I need. Reviews are of limited use.
I very much appreciate apps where I can trial or subscribe for a short period for a small price. If they do what I need I always end up buying or not cancelling the sub.
This sounds a little contradictory (too tired to word it better right now) but I hope the general feeling is conveyed.
I want to know if an app will launch itself on device startup, and I can't see that any longer with "data safety". There are other permissions that are now similarly hidden. I appreciate that less tech savvy Android users might benefit from a simplified view, but I wish they'd give the advanced user an option to view details (and, ideally, the ability to reject ANY permission).
Google made scoped storage mandatory in Android 11 and later[1], this can restrict to just the app's own directory but people usually want to share media from outside the app's directory so they request the additional access.
The basic use case works, but quite a few things beyond that are broken. None of the various sandboxing attempts (not just Android, but everything) properly handles multi-file file formats [1], so that alone is very much not a solved problem!.
Keeping an LRU list for files that were opened from outside of your own app becomes needlessly complicated [2].
Access gained that way isn't directly compatible with things expecting classic File API access (and sometimes those things are outside of your immediate control, like external libraries and even parts of the Android framework itself), and unfortunately the easiest workaround to that problem is just copying the file into your own private storage.
[1] As far as I'm aware, only macOS attempts to at least handle related files that only differ in their file extension, but even that still doesn't cover more complex file formats like playlists, or HTML or DWG files or whatnot that can reference arbitrary other files.
[2] If the same file is shared via different apps, the way things have been implemented on Android it becomes more complicated for the receiving to check whether those two incoming file shares actually refer to the same underlying file or not. Plus for an LRU list to make sense you need to try persisting the file permissions so you can still access the file later on [3] and also especially take care not to leak those permissions when you clean up the LRU list.
[3] Which also leads to some strange scenarios like when you switch to a new file manager and uninstall the previous app, all LRU entries in other apps that were originally opened via that previous file manager now suddenly become invalid.
It would be interesting to look at historical data for permissions - what permissions are apps adding in the last few months compared to further back? Could make for some nice graphs and a blog post if you happened to have that data lying around :)
I expect a lot of crapware authors are currently adding permissions that they've wanted to but couldn't justify to their users, now that Google has stripped their users of visibility and recourse.
E.g. last time I looked at this a lot of obvious crapware was requesting the "ACTIVITY_RECOGNITION" permission for God knows what reason - a permission that can't be denied by the user.
As a rule Google only gives users the option to disable a permission after it has been widely abused, or maybe not even then. It's downright hostile to take away one of the only ways users have to spot spyware before they install it.
Huh? Apple has always had permissions; Apple calls them "entitlements". Some of them are granted on install (like Game Center or Siri intents); some of them also require explicit user permission (like push notifications or contacts access).
What Apple doesn't do is list entitlements in the App Store. This is because users don't generally need to be aware of them; entitlements with significant security or privacy implications are always coupled with an explicit permissions prompt, and many entitlements represent internal details of how an app works which users don't need to be aware of.
I use iOS and I don’t think I’ve ever seen one of those lists in the App Store. I don’t insta a lot of apps, however, so maybe I’m not the typical user, but one thing that Apple has is that the actual permissions are off by default.
I had Instagram for a while as an example, because I liked to look at miniature painters, but Instagram never had access to my contacts, images, location data and so on. It would ask for permission of course and I would decline.
Does Google do something similar or are permissions on per default? I mean, the info is still a nice feature in the App Store to help people make better choices, but the real protection for people like me is the “This app would like to access your pictures, will you let it?” box that pop ups when you run the app.
Not presented in the App Store; both android and iOS still have a permission system, but you need to download the app before you can see what permissions the app has asked for.
Probably some combination of inertia, future-proofing, and because it might facilitate some sort of internal bookkeeping inside the OS and/or the app store. After all there are quite a few more of those permissions around that have to be declared, but which are automatically granted and not specially surfaced within the UI.
"Permission" system is broken to begin with. Every app should get all the permissions they want, but the user could choose what kind of data to actually provide, none, some, all or even fake.
Honestly, these days I feel like it's dumb to deploy on a platform you have no control over, unless you have enough money to pay lawyers to get Google's/Apple's attention.
