That is part of why simply the existing "All permissions" view is harmful. It should only be there if you enable developer options. They should also either remove the highly misleading user facing strings entirely and only show the permission names or give actual descriptions.
Conversation
The actual descriptions would be for developers. At most the low-level INTERNET permission is something that should be a user facing runtime permission, and one day QUERY_ALL_PACKAGES + queries could be user facing but not as a permission toggle since it's more complex.
1
3
Aside from that, they are entirely missing any kind of permission for most sensors access. They have restrictions on what can be done in the background, but that's it. There is absolutely no low level permission for stuff that can be used to record movement / direction or speech.
1
2
We add Network and Sensors permission toggles in GrapheneOS. It would be nice to at least get Sensors in Android itself, especially since the lack of even a low-level permission for it means we have to mark all apps as requesting Sensors with a Sensors toggle for all of them.
1
4
The only way to make QUERY_ALL_PACKAGES + queries work as a user facing permission would having a permission which fully disables BOTH of them and draws no distinction between intent-based queries and QUERY_ALL_PACKAGES because there is really no actual difference in practice.
1
3
These are some pretty good points. They all seem based on the viewpoint that permissions = privacy/security feature though. Is that ALWAYS the case? I can't think of anything off the top of my head, but I imagine some permissions could be used for controlling device behavior, etc
1
I'm also generally averse to the idea of hiding things from users. I'd much rather have an explainer for things and expose it to users than hide it simply because a user might not understand it.
1
The vast majority of this is already user facing. The low level permissions enable the user facing toggles. That's how it works for all the runtime permissions and also most of the supposedly install time ones despite them actually requiring consent and having toggles.
1
2
The user-facing functionality is not only for privacy, security and battery life. It covers control over the device too. Also, the simple fact is that listing stuff an app can do at install time is wrong since the user should be able to deny it and still use the app.
2
2
Android knows it is wrong and has completely stopped listing things at install time itself since instead of gives runtime controls over everything that has been deemed to matter with INTERNET being essentially the only exception that's very questionable (and not just incomplete).
1
2
Which low-level permission is there that is actually relevant in some way to users due to actually controlling whether something can be done but is not already user facing with a toggle to either opt-in (most of them) or opt-out (a few like exact alarms / restricted battery use)?
Other than the INTERNET permission, at least, but the proper solution to that is clearly making it a toggle not listing it with no way to avoid it beyond not using the app. Many apps can optionally use internet access but work without it, and as stated before, why punish that?
2