tjk It's important to note that if it can do that, it also requests accessibility permissions, in which case, see above regarding the dangers of that.
FR: toggle flashlight with long press powerbutton with display off
matchboxbananasynergy I see. That makes a lot more sense why that feature is built into so many other roms now. If im understanding things correctly, your concern has to do with a compromised version of an app with accessibility permissions? Maybe, if the concern is great enough, GrapheneOS could provide a similar app through its own distribution channel in the same way as android auto etc? Then it would just maintain the same chain of trust as the os. It could just be a fork of torchie or torchie redistributed from graphene. Maybe another app would work better too, i dont know.
Almost every android user I know, graphene or otherwise, uses either torchie or their rom's builtin flashlight toggle from the button. It is a really handy feature regardless. I think that is a decent solution to the whole problem anyways. Let me know what you think!
tjk
The concern is that granting any app the ability to act as a accessibility service opens a huge hole in the security of the device and is best avoided if at all possible. The serious consequence of granting this to any app is why Auditor app checks and reliably reports if this has been granted.
GrapheneOS will not be contributing to people believing that its normal and acceptable for apps to ask for the opening of this massive security vulnerability to preform relatively mundane tasks.
For years there have been repeated requests to add this button press flashlight shortcut to GrapheneOS. So many that the team now almost considers it a meme.
The response is always the same. As GrapheneOS is focused on security and privacy any use of physical button press shortcuts would be for a privacy or security features.
There is a long list of work the team plans to implement which has higher priority than adding button press shortcuts.
Personally I am more missing the ability to turn the flashlight off using the power button (MIUI has this feature). I learned to "overcome" this limitation by turning on camera (which automatically disables flashlight), but it's a bit annoying.
As for the power button, considering it may be unsafe granting accessibility permissions to an app (although if the application is opensource and trusted, why not?), it would be very nice to have a possibility to assign various privacy-related (and others) toggles to the hardware buttons (which can be picked from a menu in settings?) on the OS level.
traveller It would be very nice to have a possibility to assign various privacy-related (and others) toggles to the hardware buttons (which can be picked from a menu in settings?) on the OS level.
As mentioned above (Carlos-Anso) many users have reported that it would be nice, but the project has determined that some nice things are unlikely to occur in the foreseeable future.
The project provides detailed instructions for people who wish to build private forks of GrapheneOS incorporating features the project is not shipping generally.
- Edited
Carlos-Anso So any app that uses the accessibility services opens security holes? What if I am 100% confident that the app is not malicious? Are there still security holes that could be exploited outside of the application by lets say another app or some outside device?
Why not provide some sort of way to achieve this sort of functionality securely? It seems like a lot of users rely on these accessibility services in one way or another, and if these services are opening up security holes it sounds like something that GrapheneOS (with its focus on security and privacy) should at least hold at some priority IMO.
Im not trying to demand that this gets put in the pipeline anytime soon of couse, im just curious about all of this. Thanks
[deleted]
tjk the project team has not reacted on this, above mentioned comments are opinions of community moderators. It would be nice if it came with an explanation as to why an app that works with literally no permissions but requires an accessibility service poses a huge security concern and is a bad idea to use.
[deleted]
Dumdum yes, that is possible but not a fact. The fact is that we a being recommended to eat a diet that makes us all sick so that Big Pharma can benefit from management of our health issues instead of addressing the root cause. Anyway, the thread is marked solved. No further input necessary.
- Edited
tjk What if I am 100% confident that the app is not malicious?
There is no 100%.
App developers could turn malicious or their machines could be exploited. Could also sell or pass the app to a new malicious developer. Same things could happen with the developers of any libraries the app uses. Theres numerous recorded cases of these things happening with all kinds of software.
Whoever builds the version of the app you use could be malicious or compromised.
As a final possibility the app on your device could be exploited.
An app granted accessibility services has more control of the device than the user. It is much more dangerous than granting an app all the standard permissions as it can block the user from doing things, operate the device, use apps and display whatever it likes on the screen to hide what is really happening.
tjk Why not provide some sort of way to achieve this sort of functionality securely?
By the nature of the privileges required to perform the accessibility tasks there is no way to easily make a more secure implementation.
Unless you need genuine accessibility aids its not hard to avoid using apps, or the functionality within apps, which require it being granted the ability to act as an accessibility service. That is the way to address this security concern.
Carlos-Anso There is no 100%.
App developers could turn malicious or their machines could be exploited
True but that could be said of any software in existence including GOS. Thats why I mention a "chain of trust" in my suggestion of GOS providing an app like this in their store. In that scenario, the only way that app would be untrustworthy is if GOS got compromised, in which case we would have bigger problems than an app just exploiting the accessibility settings lol.
I understand your point about the accessibility settings better now though, and your points make a lot of sense, thanks for the info.
Maybe providing an app for this wouldnt be advisable because it could give certain users the idea that they could trust different apps from other developers that request accessibility permissions, but there seems to be quite a few users (including myself previously) who use these permissions without being aware of the security issues with them. I know this doesnt rise to the level of being an urgent issue, but in my opinion it seems that something should be done about it one way or another. Maybe some sort of accessibility scopes feature (like the other scoped permissions) where the end user could have finer control over which accessibility features an app is actually allowed to use. Im sure that would be a lot more difficult that the other permission scope-ing features so far, but im interested to hear if that is at all viable. Thanks!
I'd say, it's a security concern, if you first have to illuminate and blind yourself and focus on your phone before you can illuminate and blind whatever's around you and focus on that.