stub for READ_PHONE_STATE, GPS and other permissions

[alexmo1997]

GrapheneOS has Contact and Storage Scopes, which solves the problem of apps getting unnecessarily broad access to contacts and user files.

This problem applies to other issues as well, however. The big issue is location tracking, as some apps refuse to start without being given location access. Thus it would be great to be able to give the apps e.g. a specific location without revealing your actual location.

The same is true for READ_PHONE_STATE. WhatsApp, for instance, requires READ_PHONE_STATE in order to take WhatsApp calls, and thus gets access to some data it does not at all need.

Those are the most pressing examples I think, but in general it would be nice to be able to make apps think that they have certain permissions, but when trying to use those permissions those apps would just be given empty data. This would prevent them to force users to give them access to sensitive data that isn't required from a functional standpoint.

[xx-5]

yea Whatsapp now require phone permission for calls, it started few month ago arround the time that they started to target api 33 if i remember and previously it was not requiring it, what a shame😠 I'm still wondering if i allow that for Whatsapp located in Work profile then can it see phone numbers of incoming and outgoing phone calls?

[ATGUAG]

This problem applies to other issues as well, however. The big issue is location tracking, as some apps refuse to start without being given location access. Thus it would be great to be able to give the apps e.g. a specific location without revealing your actual location.

Android has a developer option with label "Select mock location app" which already implements this part of the issue coupled with the proper app for mocking location. It works as you intended at least for the main profile; check:
https://github.com/mcastillof/FakeTraveler

[secretmango]

yes thought about that too. Fake GPS location could be bundled with IP address (when using a VPN) to make the fake more realistic.

Providing some generalized value may result in things like VPN blocks, as that location could then be blacklisted.

[OliverSpeak]

The same is true for READ_PHONE_STATE. WhatsApp, for instance, requires READ_PHONE_STATE in order to take WhatsApp calls, and thus gets access to some data it does not at all need.

To expand on the phone permission, apps can request to read the device's phone numbers, which is particularly problematic for devices running multiple profiles. The phone permission makes it easy for apps to link profiles together, potentially de-anonymising them in the process.

That said, this is only the case when a sim/esim with a number is registered on the device, otherwise the phone permission does not return any numbers, so it's not like apps can't accept no phone number on the device even with the permission granted. Perhaps this functionality can be leveraged to prevent apps from viewing phone numbers regardless of whether the device has any or not.

[MichaelDevon]

Is a "Turn Off Automatically" feature like with Bluetooth considered also for Location?

[thestinger]

@MichaelDevon No, since apps can just keep it active by using it.

[thestinger]

Recommend granting on time session access instead of relying on the global toggle.

[MichaelDevon]

Recommend granting on time session access instead of relying on the global toggle.

Having Location enabled wont use battery if no app is actively utilizing it?

[thestinger]

Having it enabled won't do anything if nothing uses it. It just makes it available for usage.

[thestinger]

Closing in favor of #4075 and #4076. Specific feature request issues are needed for each permission that's proposed to be covered rather than a single one.