Conversation

Replying to

and

The ONLY low-level permission that would make sense as a user facing one with the current status of them is the INTERNET permission, and it's important to note that many apps allow other apps to access the network through them to an extent, including every single browser app.

1

4

Replying to

and

There's more work to do beyond just exposing INTERNET as a user-facing permission with a toggle and compatibility support for existing apps as we do in GrapheneOS with the Network toggle. It is not adopted / enforced in a lot of the app ecosystem. We're working on that ourselves.

1

4

Replying to

and

Listing runtime permissions misleads users into thinking they are granted at install time and punishes apps which make them optional and get as much working as possible without them. For example, GrapheneOS Camera only requests Location if you explicitly enable geotagging.

1

5

Replying to

and

It only requires Microphone access if you start recording in video mode without disabling Include audio. The only permission it requires to function at all and requests on launch is Camera. Android stopped listing them at install time once they stopped being granted then.

1

3

Replying to

and

Play Store continued listing them at install time for a long time. It still hasn't been updated to stop listing them at install time for legacy apps despite the fact that on first launch on modern Android, there's a permission review screen for legacy < API 23 (Android 6) apps.

1

2

Replying to

and

Listing the low-level ones is more harmful since it misleads users in 2 different directions: they wrongly think apps can't do what those permission descriptions say without the low-level permissions (like start at boot) or they'll think the app can do it without runtime consent.

1

3

Replying to

and

API level would make sense to show at install time in an abstracted way, unlike the low-level permissions, since it impacts how the privacy model works. They could also extend the permissions review screen for API < 23 to certain new special access toggles, among other changes.

2

4

Replying to

and

You make a lot of good points, especially in regards to the caveats re: permissions like QUERY_ALL_PACKAGES and RECEIVE_BOOT_COMPLETED. But does the answer need to be less transparency and not more? Why not also link the user to a support page or doc explaining everything?

1

4

Replying to

and

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.

1

4

Replying to

and

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

Replying to

and

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).

9:41 PM · Jul 13, 2022Twitter Web App

Replying to

and

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

Replying to

and

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

Show replies