Sensor Permission
IMO a lot of these apps should be disabled by default. Calendar, Clock, etc etc.
"Carrier Communications" 😨
"Android Easter Egg" seems like the perfect place to hide weird activity. Anyway there's a lot of them that are concerning.
Maybe there could be a setting at start that defaults nearly everything to disabled, and then you handle the popups one by one? I would have wanted that kind of setup had I the choice.
- Edited
sonicbackdrop
Hi, You're perfectly right. To me it's totally ridiculous to see dozens of modules and apps with that permission active by design.
Not every one knows that Gyroscope and Accelerometer can work perfectly as a MICROPHONE. This ends the discussion.
The OS is trustworthy (to some reasonable extent of course) or is NOT.
Similar issue I see regarding that mysterious "Wireless emergency alerts" module, where I'm not allowed by the masters to neutralize "Nearby devices" function/permission.
Why, in so numerous threads, almost nobody points at the issue?
Why Graphene OS developers did nothing about that until now?
The (more than)obvious application of that service is to help spying on people. So disgusting to see a possibility of so malicious use facilitated and protected by the "privacy oriented OS".
Perhaps the only way to end that comedy is to physically neutralize BT and NFC modules. And naturally Gyroscope + Accelerometer (that personally I don't need at all, both).
CircusAround So disgusting to see a possibility of so malicious use facilitated and protected by the "privacy oriented OS".
Perhaps the only way to end that comedy is to physically neutralize BT and NFC modules. And naturally Gyroscope + Accelerometer (that personally I don't need at all, both).
The GrapheneOS project provides detailed build instructions, so people can make whatever changes they wish. Other AOSP projects provide build instructions as well. The GrapheneOS project has no way to force users who are disgusted by their security and privacy decisions to run GrapheneOS.
- Edited
CircusAround To me it's totally ridiculous to see dozens of modules and apps with that permission active by design.
The best way to address this is by quoting the website:
To avoid breaking compatibility with Android apps, the added [sensor] permission is enabled by default.
CircusAround Not every one knows that Gyroscope and Accelerometer can work perfectly as a MICROPHONE.
The fact that sensors can be used as a microphone has been mentioned more than once by project members. They mention this fact quite frequently. Even recently the project account was explaining to someone that hardware switches to kill the microphone don't actually work since all sensors have to be disabled to fully stop apps from recording audio.
CircusAround Similar issue I see regarding that mysterious "Wireless emergency alerts" module, where I'm not allowed by the masters to neutralize "Nearby devices" function/permission.
Both GrapheneOS and AOSP have blocked changing permissions for certain apps/services, and for good reason. There are many people who attempt to "improve" the privacy of their phone by changing permissions, but all they end up doing is messing up their phone somehow. Changing permissions for or disabling system apps can lead to unexpected behavior. Sometimes it can take some time for issues to start popping up, like when there are upstream changes to apps and there can be a cascade of problems. You're more than welcome to disable stuff via ADB. Nobody can stop you, but just know that if or when things start to break, we cannot help you.
I don't know why this specific app has access to Bluetooth, but there are all sorts of reasons why this permission would be necessary. The name of the permission is very vague and you can't know what the app is using that permission for without reading the source code for that app. It could be something simple like checking for wireless hotspots nearby. Just because you see a permission that has a scary name doesn't mean it's spying on you or doing anything malicious.
CircusAround Why, in so numerous threads, almost nobody points at the issue?
There are tons of threads where people ask why apps have certain permissions and we try our best to explain why, but we still end up having to address the same concern over and over again because people don't seem to trust the OS they're using for some reason.
CircusAround Why Graphene OS developers did nothing about that until now?
There's nothing to be done.
CircusAround The (more than)obvious application of that service is to help spying on people. So disgusting to see a possibility of so malicious use facilitated and protected by the "privacy oriented OS".
I really have no idea what you're talking about here. You're talking about an open source app/service that's part of an open source OS. Everything is auditable. If you actually read through the code, you'd find that there's nothing interesting going on there. Like I mentioned earlier, the permission is probably there to do something boring, like to allow the app to see if there's a bluetooth device nearby or something, maybe to avoid blowing out someone's ears when sending an alert (just an example, I don't know what the app does in this case, just to be clear).
CircusAround Perhaps the only way to end that comedy is to physically neutralize BT and NFC modules. And naturally Gyroscope + Accelerometer (that personally I don't need at all, both).
Attempting this would most likely end in you breaking your phone. I personally don't see the point of spending money on a new capable device and then crippling it. The software switches work just fine.
Final thought: Your whole post just oozes suspicion of GrapheneOS. You suspect system apps aren't trustworthy. You suspect apps are spying on you or enabling others to spy on you. There is no spying. There is no conspiracy. Please don't come here spreading misinformation based on something as small as permissions granted to system apps without fully understanding what you're talking about. If you have questions or concerns, please do so without making unfounded accusations.
de0u
I wanted to replace the word "disgusted", after I found it a bit too strong, with the word "disappoited", but unfortunately the system doesn't allow edition after a very short time.
An I'm ready to pay for using the OS, especially if a bit more reliable in security aspects than it currently is (i.e. unmanageable and persistent "Wireless emergency alerts" module).
- Edited
CircusAround I'm also into minimalism. going full snowden unsoldering all the unnecessary stuff sounds like a satisfying final solution, but unless you have the skills and the equipment you'll have to find someone you trust to do it for you. tricky.
at least the wireless emergency alerts can be disabled. even the presidential one which oddly is always on and greyed out on every other phone. the alerts are usually banal and useless but everyone getting them made me feel a bit left out so I enabled then again.
- Edited
other8026 I really have no idea what you're talking about here. You're talking about an open source app/service that's part of an open source OS. Everything is auditable. If you actually read through the code, you'd find that there's nothing interesting going on there. Like I mentioned earlier, the permission is probably there to do something boring, like to allow the app to see if there's a bluetooth device nearby or something, maybe to avoid blowing out someone's ears when sending an alert (just an example, I don't know what the app does in this case, just to be clear).
I don't see any reason to arbitrary leave the "Wireless emergency alerts" module impossible to switch off permanently, as well as the "Nearby devices" in it.
Sorry but, witha all due respect to developers (that I honestly admire), it's definitely not normal at all to have permanently such spying tool in the phone. Especially if all the rest is possible to control by the user.
Regarding your 'Final thought': Maybe, but it was absolutely not intended. Graphene OS is the system of choice for me - the only one, that few years ago I've found trustworthy enough to use, and with installation etc. feasible and understandable as a whole by a bit more advanced ("computer literate +") user. I'm a very satisfied Graphene OS user, as I explained below.
And your "something as small as permissions granted to system apps"... Please be more serious. The MINIX OS is an old example that explains what WE (not only me) mean, and the technology advances very quickly so OUR concerns are fullu justified. Remember, we're talking here about a Google's product and many of US remember the year 2020/2021 with mass deployment of agressive spyware that used BT (not only) to map locations and people's interactions, impossible to switch off. If your'e intelligent (I believe you are) and not ignorant, you know very well the trend. Some people simply can't accept or even tolerate the reality imposed by them.
Pixel was my first 'smartphone' with chimpanzee keyboard nonsense, after BB and earlier Nokia E models of course. I resisted the unwanted as lon as I could. And finally Pixel + Graphene OS. And I don't regret. I can only COMPLIMENT and pr PRAISE its DEVELOPERS and the SYSTEM itself. It allowed me to live without Google (that I abandonned fullu and for ever in 2012, wnen I fully realized what Google really is), until technical need appeared for eSIM installation (I hope I can trust the advice and delete GS without affecting eSIM func.).
I can ridicule Google/Apple slaves (and I do) honestly, although the life can get complicated sometimes without that crap, so what. I've even purchased a typical google phone only for banking. For first 3 days and nights I kept it in the storage otside the house, after configuration I made when I could see with my own eyes all "goodies" inside that system. I knew before what to expect, but trust me, I was shaken quite seriously at the confrontation moment.
So, please don't accuse me of subversion. With a couple of discussed exceptions, I'm VERY satisfied with Graphene OS. It's a brilliant example of good alternative to the stuff imposed by The Cartel. Happily we have now (finally!) more and more of such good alternatives. I highly appreciate efforts of people contributing in all aspects of the project. None the less my (OUR) uncertainty and fears ARE based.
And I repeat: If not proved or publicly declared impossible to change, it's not justified to support the current state of "Wireless emergency alerts" (and maybe 'sensor permission' by default here and there).
- Edited
P.S.
An interesting thing is the fact that the carrier has (and uses) the ability to make important changes in the system, with out our knowledge and approval. I observed it twice. The last time was after installation of an eSIM, where suddenly, out of nothing, ...the 'Nearby devices' permission appeared as switched ON for the "Phone' app.
It shows we have a real problem here.
- Edited
sonicbackdrop
Or perhaps two standards of initial settigns to choose during installation, that could be kept as a default setting for the system/phone. One with permissions as we can see now, and the other with everything OFF (except the absolutely necessary for basic functions), naturally including WLAN and BT OFF.
CircusAround I repeat: If not proved or publicly declared impossible to change, it's not justified to support the current state of "Wireless emergency alerts" (and maybe 'sensor permission' by default here and there).
What sort of proof would be acceptable?
Might it make sense for you to visit a local university and hire a graduate student to look into the explanation offered above (other8026)?
- Edited
CircusAround
You are making a big ado over nothing. Don't worry so much about the system apps! You are putting way too much energy into a purely imagined threat where nothing exists! The Phone app, the GrapheneOS dialer now has Nearby Devices Permissions! OH NO!!! WHATEVER WILL WE ALL DO! It sounds like you have a lot of paranoia combined with little technical expertise. A dangerous combination...
In reality, its not going to do anything scary with it. Don't like it? Revoke it! First thing after I flash a new factory image from my build of GrapheneOS, right after enabling memory tagging and disabling native code debugging for all apps, I then turn the sensors permission off by default for new apps. Then I go through all my user apps and revoke sensors permissions for every user app that don't explicitly need it for some functionality. That ends up leaving me with 3 or 4 user APKs, and all the system apps that still have sensors permissions. Why do I leave all permissions as they are with all system apps? It's because I trust the OS, GrapheneOS!
On the stock OS, there is the Carrier Services app, which gives your carrier system level access for your device. On GrapheneOS, they built a different system app to interface with the carrier, I don't know much about it, but I do know that it does not allow a carrier to remote lock your phone, or to set a seed in your persistent memory to prevent you factory resetting in recovery if they lock your phone due to an unpaid bill.
The GrapheneOS team is on your side. I do review the source code, as I'm getting to know GrapheneOS better through building it and rebuilding each new update. I am doing it very slowly though, as I look for ways to modify it subtly. It us very enlightening getting to know how things are done, learning the coding languages, and reading the comments in the source code, both for what is implemented and what is still planned! There's nothing worrying or malicious in there as of yet!
Lusca
In "sexurity&privacy"->permissions manager I do see that >>200 Apps have permission for "sensors", but I do not see a "default no" option.
I also do not see a way to take this permission off those 200++ appa besides taking it one by one. Is there any option to to both?
I don't see why this is default-allow. Besides navigation and fitness tracker app, which legitimate reasons exist to access such sensors?!
ToolTimeTim7 Auto-rotate perhaps?
Update: the default switch for sensors is shown under security & privacy - more security & privacy, not in the permissions manager.
@"SgtSurehand"#p
DeletedUser69 Nice idea, been t I just revoked sensor access from my browser app, restarted it and it still does rotate. So for landscape vs portrait the sensors is not relevant.
ToolTimeTim7 I don't see why this is default-allow
As explained before, because in most versions of Android, there is no such permission: apps always have access to sensors. If an app uses sensors, it is not likely to gracefully handle zeroed sensor data. Denying sensor permission will break some apps.
The GrapheneOS project made a choice in favor of compatibility in this case. You're free to disagree, and it's only a matter of flipping one toggle to enjoy your preferred behavior.
- Edited
Probably9857 If you know, it is. It is not asked during initial configuration, so now I did all the initial setup without knowing and everything is enabled.
However it says that it GOS will ask when sensors are accessed, so in fact it is rather default-as than default-on, isn't it?!
So its pretty much irrelevant that it is default-on. That is a good design, In was just misleader because it is listed as granted when in fact it is just "ask".