- Edited
Lots of F-Droid apps have sensor access by default. Is this required? Weather apps, maps (organic maps, OsmAnd etc.
Lots of F-Droid apps have sensor access by default. Is this required? Weather apps, maps (organic maps, OsmAnd etc.
undwersq The sensors permission doesn't exist on stock Android, it's created by GrapheneOS, and apps are not developed knowing how to handle it. Therefore it's enabled by default for all apps to avoid breaking them.
What you want to do is disable the "Allow sensors permission to apps by default" toggle in Settings > Privacy. That only applies to apps you install after disabling the toggle. The system will give a pop-up when an app with sensors permission denied tries to access one of the sensors. You can choose then to allow sensors permission for that app, ignore it, or deny always and don't show pop-up again.
what are these sensors exactly? what are they doing?
yourmother The accelerometer, gyroscope, compass, barometer, thermometer and any other sensors present on a given device. They're used by some apps, for example some games, in navigation apps, etc.
From the documentation on the GrapheneOS website:
Sensors permission toggle: disallow access to all other sensors not covered by existing Android permissions (Camera, Microphone, Body Sensors, Activity Recognition) including an accelerometer, gyroscope, compass, barometer, thermometer and any other sensors present on a given device. When access is disabled, apps receive zeroed data when they check for sensor values and don't receive events.
Shouldn't we have this information before installing all apps. Seems like a design flaw.
memyselfandi It's not a design flaw at all. The GrapheneOS website is there for a reason. Wouldn't you read the label of a product before using it?
My experience is turning them off by default works flawlessly for all apps. Only apps that I want to use in landscape (which are Newpipe and VLC) get it, and they would even work without it)
You shouldn't disable the sensors permission for system apps.
Of my user apps, the Camera app is the only one I give the sensors permission. If I disable the sensors permission, any new landscape photos I take with the Camera get displayed in portrait in my Gallery app.
Yeah sorry all user apps is what I mean.
A list of system apps that actually require sensors permission would be useful. I bet it would be a very short list.
Anonymous It would be better if most system apps did not have the sensors permission by default, except a few that actually need It. User apps can continue to have the Sensors permission by default for compatibility, and the User can disable the auto-granting of the Sensors permission to apps installed afterwards anyway.
What would be ideal, is an OS that doesn't decide permissions on your behalf, like you're a child whom needs constant hand-holding, like you're not intelligent enough to have full control of your device... it feels so condescending. Provide a manual of recommended settings for optimal functionality and security. This project is time-consuming and challenging, I know! Compiling a list of necessary and optional settings would be so simple, comparatively. Teach the people correct principles and let them govern themselves.
Anonymous The Sensors permission is added by GrapheneOS. This means apps aren't aware of it and don't have code for detecting if it's enabled and requesting it when they need it. It's enabled by default to avoid breaking app compatibility and making GrapheneOS harder to use. There's a toggle for choosing whether it's enabled by default for newly installed apps. It's your choice if you want it to be enabled or disabled by default for user installed apps. This complaint doesn't make sense.
If you're referring to system components, users aren't really meant to be changing those permissions and you're very likely to break the operating system and end up needing to undo your changes via an app preferences reset. Removing the sensors permission from components in the OS not requiring it would be internal OS hardening work with very low impact. There's a low priority planned feature for exhaustively determining which system components need the sensors permission and only granting it to those. Missing anything would break functionality and therefore shipping this has a high risk of causing regressions not just when making the initial change but any time there are new OS components requiring sensors access or existing ones start requiring it. It would be an ongoing maintenance burden. If you want the project to be able to implement more of our planned features, you should contribute. There are hundreds of planned privacy and security improvements. Many of those planned improvements are a lot more significant than this would be. The system components come from GrapheneOS and the benefit of removing unnecessary access is hardening against exploitation, since an attacker who exploited one of those components is limited to what it has available in the sandbox. There's no real world privacy or security benefit since in reality attackers aren't using code execution exploits to get limited sensor access. They're going to target privileged components and attempt to take over the OS as a whole, not simply gain very limited access within the sandbox for an unprivileged system component.
The system components implemented as apps are the high level parts the OS. We don't bundle third party apps so every system app is from GrapheneOS. There are a tiny number of regular user facing apps bundled into the OS but the rest are parts of the OS itself. You can't see most of the access available to system components via the permission settings. You can only see the standard user facing settings available to regular apps. Most of the access available to system components is granted via privileged permissions only available to system components based on them being included in the OS as a priv-app, platform permissions requiring the platform signing key, custom SELinux policy for their app id / signature, having their app id on a specific allowlist such as the Vanadium WebView or other mechanisms. It's simply misguided to look through these app-based high level OS components in the way you're doing. You're only looking at a certain kind of OS component and you're only looking at which standard permissions they use which is not the main way system components are given the access they require.
GrapheneOS Thank you for taking the time to address this. I understand what happens when you delete things that have integrated dependency and then you break functionality and have to reset and start all over again, and again, and again, etc. I have also found that there are a lot of android apps that can be excluded safely. Most people don't go through their phones with a fine tooth comb as I do and many aren't as paranoid... though, to be fair, the paranoia is not without merit. I am happy to learn from those whom are more educated than myself and I understand why the complaint doesn't make sense... it is a layperson's complaint as humanity is offered less and less ability to control things in their lives. The complaint isn't directed specifically at GrapheneOS, it's more of a general question as to why people aren't just allowed to brick their phones... they paid for them! You've done a great job answering a question that is difficult to answer. Most people, myself included, just aren't that tech savvy. So, yes, toggle them off for user installed apps, but don't toggle them off for system as we simply don't know which apps require them and which don't at this point of development, correct?
Anonymous and also just to add a little off topic, it doesn't make sense trying to externally remove (i.e. via adb) system components as many attempt to do and mention it in various threads. It may break functionality and integrity of the OS and you are only likely to find them back where they were after the next OS update if you enrolled which you should.
Anonymous What would be ideal
What I think would be ideal if people spend the time to read forum, previously answered questions, educate themselves about topics they know nothing about first before assuming and doing dumb shit
f13a-6c3a I'm often strucked by people's reluctance to read official (and very good) documentation and yet not hesitate to create yet another account somewhere to ask a question that's already been answered elsewhere on the forum.
f13a-6c3a and [deleted] Have you read every thread? Because based on the titles, there is nowhere I have found that would indicate this had already been addressed. The referenced post with the so-called answer, was in regards to someone other than myself or the OP of this thread's assumption and no one actually addressed, directly, the ability to remove it. SO, what would be ideal and impressive and refreshing, would be if only those with a straightforward solution, specific to the question(s) asked, would be kind enough to not make assumptions about someone else's discovery due diligence prior to asking for help, and simply and directly, answer the question so that everyone can learn in an environment free from the gratuitous opinions of egotistical know-it-alls with impulse control deficit and a penchant for belittling others. I.e., if you don't have something constructive to say, sit down and shut up, stop wasting people's precious time. I ask questions, no matter how stupid they may seem, so that I can continue to evolve, and I hope comments like yours and other similar commentators, don't dissuade others from doing likewise. The only stupid question is the one that was never asked.
Anonymous I can only refer you to the two posts further above by GrapheneOS account. Read carefully and don't tamper with OS. You trusted them enough to install it in the first place.