DeletedUser161 missing-root nullable nullable That is not how the app sandbox and permission model work. Installing the app is not consenting to granting it any sensitive access.
Graphene's app store is the only store that doesnt
Permissions also dont matter that much, as you need to manually enable most if not all of the relevant ones, only on GrapheneOS (sensors and network)
There isn't low-level manifest information on whether an app uses access to the sensors covered by our Sensors permission. Those app stores do not list whether an app uses sensor access. They do list a whole bunch of highly misleading and inaccurate descriptions of low-level permission declarations which are handled via runtime and special access permission toggles or case-by-case requests.
true but we're not talking a measly 5 apps with a dozen permissions. Just one of those (play store) has well over 150 last i checked. Others like GSF enable Google to do even more than that...
No, this isn't how the permission model works.
IF ANYTHING, i'd hope to see more transparency into what these apps are capable of doing, but u seem to think it's generic or not worth a common courtesey practiced in EVERY other market place or app store. Apkmirror and any of the mirror sites offer it, not just fdroid.
The existing transparency has misled you into believing things work in a way they do not and you have a completely incorrect understanding of it. What those repositories are doing is misleading users with a highly inaccurate and misleading list of what the app lists as what it can request at runtime. You wrongly believe it's a list of what's granted to the app by installing it. No, that's not how it works.
I do understand what you are saying though.. That permissions are generic. Most people dont care. Dont look at them, or seem to understand most any of it.
You do not understand the basics of it but are acting as if you're an expert on it criticizing others who understand it far better than you do.
That isn't advocating for privacy or security. It's enabling a bad practice, period.
You're promoting a bad practice: misleading users about what apps can access and how the permission model works.
I get it. Permissions dont really work in the sense most ppl think they do.. But if the overall intent here is to free people from the burdon of a rapidly evolving thing, it isnt doing anyone any favors...
No, they don't work in the sense you wrongly believe they do. It is you who doesn't understand the permission model. You wrongly believe it's based around the low-level list of what an app can request at runtime being granted to the app because you chose to install it. You do not in fact have to look through this list and decide whether you want to use an app based on it. It doesn't actually make sense. Everything sensitive is controlled by the runtime permission toggles, special access toggles, the battery optimization mode or case-by-case access requests. The descriptions you're reading for these low-level permissions are highly misleading and not accurate from the perspective of it being what is or can be granted to the app. They are not the user-facing permission model and are not designed to be treated that way.
the point is that the apps either have little permissions, or they are Google which is all or nothing.
Sandboxed Google Play does not receive any special access or permissions. It cannot do more than what other regular apps can do. Permissions being listed in an app's manifest does not mean it gets granted access to those things. That is what the runtime permission toggles, special access permission toggles, battery optimization mode and case-by-case requests are there to handle. None of these must be granted to sandboxed Google Play to use it, although most people will want to give it Unrestricted battery mode. If people want to use it to install apps, they have to enable that by toggling on support for installing apps and even then it still requires case-by-case consent for each install and uninstall along with unattended updates being limited to apps the user explicitly approved it installing where it's still the current installer package.
It makes sense when more proprietary apps are installed.
It really doesn't. It's not how permissions work.
Note that most permissions are not granted by default. Also note that the internal permissions of apps dont do anything if the external, choosable permissions are not granted. So the internal ones (like the dozens of internet permissions) may confuse people and are all disabled if the bigger external (here internet) permission is not granted.
All of them confuse people and there's no need regular people need to look through them since it's not how access to anything sensitive is handled. It mainly just serves to mislead people who see it in app stores listing it or the "App permissions" menu in the OS and then wrongly believe all those things are granted to the app at install time. It's a UI which misleads power users and gives them a misunderstanding of how permissions work. It's a very bad thing and creates lots of misconceptions and misunderstanding. It is not something we want to replicate more. The "All permissions" menu in the OS is misdesigned and so is anything mimicking it elsewhere such as the Play Store. The lists shown by F-Droid and Exodus are even more misleading and more outright inaccurate.
A proper user interface for it would have things clearly grouped into runtime permission toggles, special access permission toggles, battery optimization mode and case-by-case requests. It would also not mislead people into believing listing QUERY_ALL_PACKAGES gives an app the ability to query information all packages in the same profile when that can be done either with or without it. That's a nice example of how it's thoroughly misleading. Only a couple of the ones without a toggle or case-by-case request actually do anything relevant and that's mainly the ones like VIBRATE. People get a completely incorrect understanding about how all of this works by the terrible user interfaces used by several app stores and various sites. It is certainly not something we want to replicate. The "All permissions" menu should be replaced with a list of what apps can request that's properly explained. We could put warnings into the OS about app stores showing inaccurate permission lists if we ever get around to replacing that misleading/inaccurate "All permissions" menu.
GrapheneOS added the Solved tag .
GrapheneOS The "All permissions" menu should be replaced with a list of what apps can request that's properly explained. We could put warnings into the OS about app stores showing inaccurate permission lists if we ever get around to replacing that misleading/inaccurate "All permissions" menu.
It might be easier and more meaningful to simply place a warning in the "All permissions" menu and then link it to a more comprehensive explanation on the GrapheneOS website, if one doesn't already exist there.
I think you replied to a lot of things but not what I said?
The default sensors permission seems to not cover the Pixel thermal sensor, which is odd. Instead it will be installed as a system app by default, not needing a user facing toggle
Staying on topic:
Woudnt it make sense that apps from withing the "apps" app asked for permissions the same way all other app installs does. Google was fined before being forced to implement this in android version xxx.
Not any distrust towards the GOS team, just a step more towards transparency
missing-root The default sensors permission seems to not cover the Pixel thermal sensor, which is odd.
My understanding is that the thermometer that some Pixel devices contain is handled specially -- I think it's because there's only one application that knows how to use it, and it needs a very specific kind of access?
missing-root Instead it will be installed as a system app by default, not needing a user facing toggle
Is it really installed as a system app? I don't have a device with that sensor, so I can't check.
If the situation is indeed that only the one app can access the Pixel temperature sensor, then it's not clear what would be gained by adding a toggle: users who don't want the app to access the sensor can just skip installing the app, and based on what I've read other apps don't have access to the sensor, so there isn't a way for other apps to have a toggle.
Is there a specific change you would like to see based on a specific need or potential threat?
Duckduck You're completely wrong about this. There are no automatic permission grants for apps from our App Store. It works the same way as apps installed another way. You seem to be confusing the bundled apps with it having something to do with the App Store. Android grants Camera/Microphone to the system Camera app, etc. so that basic OS functionality works. Other apps would not work by default if the system camera app. We're of course not going to remove that and provide a worse experience for no reason at all.
missing-root They made a dedicated API for it only meant for usage by the Pixel Thermometer app rather than putting it in Body Sensors, perhaps for regulatory reasons. We don't know why that's the case. Pixel Thermometer is never installed as a system or privileged app on GrapheneOS but rather we added special functionality to grant it access to this specific API when installed. Installing it is a choice to grant it.
GrapheneOS guess we all learn a little everyday. Thanks for the clarification.