With the launch of the Data Safety section on Google Play, which will be mandatory for all apps in 1 week, it seems the app permissions list is going away in both the mobile app and the web.
Conversation
Before:
2
2
36
After:
2
2
41
There are pros and cons to hiding the permission list. The con is that the info in the Data Safety section is given by the developer, so what's shown there is up to them. Eg. Telegram's is light on details about what the purpose of its data collection is:
2
2
37
The pro is that the list of permissions might be confusing/seem scary to the average user. This is mainly due to the way that Google Play displayed permissions - their titles/descriptions were not very helpful in explaining what each actually allows for.
2
1
32
This could be solved by providing better explanations to users about what each permission actually allows for, and when that permission is granted (install versus runtime).
1
3
43
For privacy-conscious users, you can still inspect the list of permissions an app needs *before* installing it by using the Aurora Store, a FOSS Google Play client, since Google Play is still storing that info. Alternatively, you'd have to inspect the app's Manifest...
3
2
47
Replying to
Or even after installing inside App Permissions > All permissions, since the app is restricted to automatically launch anyways.
1
1
It's problematic that they expose those directly. They either require user consent on a case-by-case or one-time basis despite not being runtime permissions or they have no real privacy model. Low-level permissions exist for static analysis of what apps can request at runtime.
1
5
7
For example, request install packages allows the user to allow it as an app source and then approve app installations on a case-by-case update. Only thing that can be done without case-by-case consent is updating an app again after the user authorized an install initial/update.
1
2
Another example is that QUERY_ALL_PACKAGES has no actual privacy model at this point. It would mislead users into thinking that apps without it can't query all the user installed apps when they can if they list queries for common intents like the one used for launcher activities.
Or as another example, the low-level permission for starting at boot is completely meaningless. It only controls being able to listen for the boot completed broadcast and register persistent jobs. You can listen for locked boot completed instead or start countless other ways.
1
2
There's a working background restriction toggle which disables all the ways an app can start itself without another app in the same profile starting it, such as FCM via Play services. Could go through every single low-level permissions this way. They should not be user-facing.
1
3
Show replies