(For those who haven't been following along: this whole affair started with phishing. People were social-engineered into installing an app and a little later their bank accounts were empty. A big issue in various poor countries.)
(For those who haven't been following along: this whole affair started with phishing. People were social-engineered into installing an app and a little later their bank accounts were empty. A big issue in various poor countries.)
This is also the argument they use to try to convince app vendors to add their keys to the allowlist, because the app makers can trust that their DRM will be active (if Netflix sets a "no screen recording" flag, you the user cannot circumvent it by e.g. reading /dev/fb0). It should have broader compatibility than other FOSS Android builds (when running the officially signed version of course, you can't compile it yourself and expect such apps to run there)
One of the core tenets of truly free software is that I as user must be able to run, access, edit, and view everything.
That's such a fun statement.
Any security measures taken always remove agency from one person and give it to another.
iOS takes my control away, and in turn gives that control to Apple. GrapheneOS takes my control away and gives that to the GrapheneOS developers.
The "security" you're talking about doesn't prevent certain data from being accessed, it just changes who controls the access.
If the user cannot be trusted with their own data, then there is no solution anyway. They'll just tell their private data to a scammer on the phone instead.
There is no solution against a user that wants to give their own data away, but if you try to prevent that, the only thing you'll accomplish is destroying general purpose computing.
Security isn't binary. Putting up barriers makes it harder for scammers to steal money. There's a reason why they exploit malware to steal money, rather than asking their victims to send them crypto directly.
The vast majority of scams literally work by them asking their victims to buy cryptocurrency or gift cards directly. Malware is exceedingly rare.
You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
Modern society has created far too many situations where people need to react without being able to think through the consequences.
The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
Source? This article suggests otherwise: https://www.economist.com/interactive/asia/2026/04/10/scam-i...
Moreover it seems to be limited to south east asia for now. Just because you're in the US and all the scams you're getting is cold calls from microsoft tech support, doesn't mean scams with smartphone malware doesn't exist.
>You know what would really help against scams? Avoid putting people in situations where they need to decide right now or they'll face punishment.
>The only reason scams work is because there are enough actual situations with unnecessary life-or-death decisions.
In other words, "if we had world peace and everyone could hold hands and sing kumbaya, then we won't have to worry about scams!"
With a proper security model and verified boot, you can be certain you, the user, are running exactly the OS you expect to run. You can also properly revoke permissions to software and gate access as you see fit. With root, you cannot guarantee you are running what you expect and apps have to exploit much less to get root access, or just keep root access if given by the user. You cannot revoke godhood, it can just lie and say you revoked it. There is nothing enforcing any security features.
The user must be the administrator of their own device. Whether that's a laptop, desktop, PDA, mp3-player, smartphone, tablet, cyberdeck, netbook, or any other kind of computing device.
The user must be able to overrule any and all decisions. That's the definition of ownership.
Like, this was the reason why GNU was founded, and before that was the plot of the movie TRON.
Its really funny because Tron, or at least Tron Legacy, is a great example of why godhood is dangerous and why a user and a program having root access is catastrophic.
> You can build and sign the OS with your own keys, without undermining the security of your device, and adding whatever functionality you want with the principle of least privilege.
Building a version of the OS and flashing that removes everything currently on the device.
So if I ever need to overrule a restriction an app has set, I must have already granted myself the power to do so ahead of time.
Which means there are only two viable paths forward:
1. If I assume that software is perfect, and I will never need to overrule a restriction software sets, I can use stock Android or Graphene OS
2. If I assume that at some point in the future I might someday need to overrule any restriction, I must grant myself root permissions from the start.
Also, I don't need to grant root permissions to random apps.
All that's needed is for the adb and the native file manager to be able to enter sudo mode and read any file, so that in worst case I can always pull all data off the device, and flash a version of the OS with my changes instead.
If we want to go one step further, and want to apply the practical definition of the FSF rights of free software, you should also be able to replace any file using the builtin file manager in sudo mode.
Installing your own build does wipe the device when you unlock the bootloader, yes, but updating it with a locked bootloader does not. It would be a one time transfer if you have official images already installed.
Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
The randomness of an app is irrelevant and apps need to jump through significantly less loops to obtain root access without your input. And even if they didnt do that, and you permitted root instead, the app can lie about you revoking it later in either case.
This is blind ideology over safety and real ownership. Root is a hacky shortcut for proper functionality, and is not a prerequisite to ownership in the slightest.
Okay, so once I install grapheneOS, how do I update it with my own custom build while keeping my data intact?
> You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands.
You haven't read anything of what I've written, it's incredible.
You're continuing to use the term "root" to mean granting full power to random apps.
I'm using the term "root" in Linux terminology.
It's not advisable to run random software as root, no matter what platform you are on.
But the OS' native file explorer and shell, in this case com.android.documentsui/com.android.files and adb, should allow the user to authorize themselves as root and read/write to any file.
Its not advisable to run anything as root, at all. Or expose access to it in any form.
You can make userdebug builds to access a form of root that doesnt undermine the entire security model, in ADB. Afaik this lets you access apps internal directories but is not recommended for production devices.
Awesome, so you're advising against installing GrapheneOS for anyone that wants control over their own data.
Sorry for twisting the words slightly, but that's the essence of the issue here, isn't it?
> Its not advisable to run anything as root, at all. Or expose access to it in any form.
And then you advise for exposing access to it in pretty much the same form I asked for before.
It'd be funny if it wasn't so exhausting.
Regarding the security model: So adjust the security model.
Any access that an app can have, should also be available to the user. Importantly, they should be able to access and modify any data.
The system documents/files app already has special permissions for that, there's no reason why it shouldn't have access to all files (accessible through the same unlock system as e.g. the security settings)
To be clear, I am NOT advising root access. I am not contradicting myself. I am telling you it is dangerous but still telling you how it can be done in a less terrible way. To withhold that info would be senseless gatekeeping. GrapheneOS supports being built as a userdebug image but that will not stop them from telling you how bad an idea it is to use it on a production device.
GrapheneOS will not be rolling back aspects of the security model. That would be a massive step backwards for privacy and security.
An app developer getting access to send my files to a random server somewhere? That's just a simple permission prompt, no unlock needed.
But me getting access to my own files? That's an absolute no-go. Even with adb and unlock, absolutely impossible
Seriously, you need to explain the difference. Because I don't see how apps being a one-way street (they can access my data, but I can't access theirs) is in any way reasonable.
That's GrapheneOS users and developers every time the topic comes up. I'm reading the thread and really admire the matter-of-fact tone you keep while calling out the illogical parts of each new attempt at justifying why GrapheneOS doesn't grant users full device access. Thanks for seeing this thread through!
But no one said we have to copy that flawed concept. macOS and Linux already have a good solution, requiring your full unlock password in a privileged dialog to authorize changes.
It's ridiculous that changing the settings on my device is protected 10× more than transferring all my money to a random person.
You use operating systems that have significantly worse security than GOS, iOS and even stock Android as your examples?
Also you literally are the owner with GrapheneOS, lacking security is not "full ownership." You can create your own build of GOS, you can modify it ahead of time, you can literally see all of the source code it's running.
Claiming GOS isn't true ownership is like complaining that you can't change your car's wheel alignment while driving it and saying it means you don't truly own your car.
It kind of is. A locked box with no key, is a very secure device with no utility. If I can't unlock the box ever, just because someone could steal my key and unlock it as well, doesn't make the box an example of a perfect security model.
The issue with taking away root access, and providing no alternative for modifying installed apps, it's just taking away rights from user. An app can modify its own data (which is fine), but a user modifying the data of an app is somehow a big no no. GOS also provides no proper firewall solution, other than the stupid VPN-based solutions available on Android.
If the intention of GrapheneOS is to serve the app developers and not the owner of the device, it should just say so.
The mind bending people get into to prove GrapheneOS' statements right. Do you realise GrapheneOS is a third party as seen from yourself? Their system updater can sure as hell install (and cause to run) any code they like
If you can't give yourself root but a third party holds all the cards, you don't have more agency than a scenario in which you can issue commands at the same permission level as the OS
That'd still allow you to free your data.
Ideally though the native filemanager should just have a sudo mode that can be entered to access everything, if desired.
Yes. For example if you install an apk from an unknown source (like a random website via browser or messenger) it will warn you what you are about to do and what effects that has.
You don't need to block stupid behavior. Just make sure users are well aware of their actions as long as they actually read warnings.
This particular attack requires getting users to sideload apps that would be rejected by the play store, and most users don't have developer mode enabled. Therefore, the cost of persuading someone to enable developer mode matters. If the procedure to enable developer mode changes from "open settings, scroll down, tap, scroll down, tap seven times" to include e.g. a 96-hour wait for developer mode to be enabled, then the cost of the attack rises by whatever it costs to stay in close contact with the victim for 96 hours, close enough to react if the victim comes close to realising the truth.
This isn't a guarantee. You can still get phished even if the phisher has to spend 96 hours in intensive contact with you. Some victims are worth that effort, maybe you are, and maybe the phisher made a mistake and puts in the effort to phish you based on the mistaken assumption that you're a millionaire.
There are also other things like that. If Google can ban the keylogger you use quicker than you can deploy new builds, for example. Still no guarantee.
also, 'rooted' means you have root access, not that you run everything as root.