DeletedUser161 GrapheneOS is exempt then, is that what you are implying? Sorry just trying to understand .
"modern applications use necessary permits", can you explain what you mean hear pleaae? are you suggesting apps dont need to request permissions because they are modern? or that permissions dont apply to modern applications or something else enrirely?
missing-root not needed? like any app can do whatever it wants if from GOS store? I would think people might want to know which data that they are consenting to. Even if they're following the grouped permissions model.
i thought users have come to expect a certain minimum standard is upkept. otherwise why bother with permissions at all? Teach futility?
DeletedUser161 oh you mean because they're web apps right? and web apps work how users come to expect while browsing any website or document/pdf/image....
nullable the GOS store only includes apps from GrapheneOS, 5 apps mirrored from Google, and Accrescent.
Those are all either trusted or Google stuff that simply is Google stuff.
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)
nullable Which authorizations should be displayed ? In reality, it doesn't really matter, F-Droid displays them and it's misleading, you just have to set the permissions in the application settings, for example, just because an application asks for the microphone's authorization doesn't mean it can access it, you just have to reject the authorization. As written above, applications in the App Store are only trusted; if this wasn't the case, then it wouldn't make sense to use GrapheneOS.
missing-root 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...
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.
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.
That isn't advocating for privacy or security. It's enabling a bad practice, period.
Xtreix how about the standard practice of a common application/package manifest? Could step it up and add dependencies with known list of libraries too.
"Authorizations".. Why use that word in particular? Do you play/work with IAM (identity) services?
It seems like a step in a different direction to not mention ATLEAST as much as any other place is doing.. People are generally pretty DUMB when it comes to their phones.
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...
nullable the point is that the apps either have little permissions, or they are Google which is all or nothing.
It makes sense when more proprietary apps are installed.
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.
Follow the traditional practice of informing users which permissions apps have prior to installing them.
The practice you're referring to is incorrect and wrongly lists all the standard permission requests in the manifest as if they're access granted to the app based on installing it. It misleads users about what apps can access and how the permission model works. It essentially punishes apps for supporting features requiring permissions even if they never request them without going far out of the way to use the functionality requiring them. The descriptions of these permissions presented to users are also highly inaccurate.
Fdroid does it. All their forks i know of do list permissions as well. Google condenses the information for Play Store apps, but they still offer a courtesey glimpse to which grouped permissions those may be.
Other app stores misleading users about how permissions work and about what they do isn't a legitimate justification to do the same thing. Google tried to phase it out for modern Android but kept it due to pushback from people who don't understand it. They wanted to do the right thing in regards to this but chose PR over it.
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.
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 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?
