It's not really transparency, since it's not how the permission model works. Permissions are handled at runtime based on what the user has granted or revoked. Anything that doesn't have a toggle is not part of the actual permission system implementing any real privacy properties.
Conversation
One day they'll get QUERY_ALL_PACKAGES and related changes to the point that there can be a real privacy feature made out of it which could be user facing, but that's pretty far away without a clear path to it.
There's already a background restriction toggle for all that stuff.
1
3
Just worth noting that other apps can still start a background restricted app. It just can't start itself because broadcasts, jobs, alarms, etc. are delayed until the next time it's launched by another app including user launching it via a launcher (which isn't a special case).
1
3
Permissions in manifest are for static analysis of what can be requested at runtime, and a lot of them are obsolete, incomplete or otherwise highly misleading. Runtime permission toggles, special access permissions and case-by-case consent systems are the actual privacy model.
1
3
They shouldn't even have user-facing strings written to describe them in a highly misleading way. It's wrong that those even exist and are exposed anywhere. The actual permission model needs to have descriptions and guides added, but those low-level things aren't part of it.
1
3
For example, Location is often mistaken as a toggle for location services access, but it's the toggle for overall access to location information through any mechanisms including other permissions. Bunch of low level permissions are really controlled by Location / Nearby devices.
1
3
INTERNET is the only low-level permission where I think there's a case that it should be exposed, but listing it is not the right way to do that. Needs a toggle, as we've done in GrapheneOS with Network toggle, and work beyond that to deal with apps not enforcing it for others.
1
3
i.e. is the right approach is turning it into a runtime permission, providing a compatibility approach to revoking it as they've done for other newly introduced runtime toggles (which we do for Network toggle in GrapheneOS) and then work to fix the app ecosystem integration.
1
3
Almost all the other low-level permissions have existing user control and mostly require opt-in rather than opt-out. Background restriction isn't a privacy feature and isn't how background privacy restrictions are done so that being opt-out isn't a privacy issue at all.
1
2
What about the increasing number of "normal" permissions that Google Play vets, like QUERY_ALL_PACKAGES and USE_EXACT_ALARM? Should users not have visibility into which apps request those kinds of permissions before installation, or just trust Google Play's vetting?
1
3
Google vets / restricts requesting battery optimization exceptions from users even though it requires user consent. That's normally the way it works. In cases where they don't require user consent, either it has no actual meaning yet or they should be making an actual OS feature.
QUERY_ALL_PACKAGES is unfinished and has no real privacy value. I don't think their reviews accomplish much in the first place, so them reviewing something that isn't actually required to easily query all user installed apps isn't really changing much about that flawed process.
1
2
QUERY_ALL_PACKAGES has to be turned into something that actually provides some kind of privacy property because it should be exposed to users. As is, exposing it would mislead users into thinking apps without it can't query all their user installed apps. Harmful, not helpful.
1
2
Show replies