I know Graphene has innovative security measures, do you happen to know whether that includes anything wrt. phishing or social engineering?
(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.)
That's one of its primary arguments: besides the hardening against exploits, they're considered such a safe OS because you cannot access your data either and give the wrong app root access. Everything lives in a sandbox. Whether not being able to grant full access to e.g. adb shell, Termux, or Restic is what you want is a personal choice, but it adds a layer of security against any malware that tries to get you to grant them root access
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)
So it doesn't actually do anything to give control of the device back to the user?
One of the core tenets of truly free software is that I as user must be able to run, access, edit, and view everything.
You are free to make your own build of GrapheneOS with root access and have extremely reduced security. Just don’t expect support on the forums and waste everyone’s time when something happens.
"extremely reduced security"
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.
The sad part is that this has a solution. It's called adb root. Your adb stays locked unless you unlock it, and you're not able to get root on the phone. But you can through the adb shell, meaning that when app X wants to screw your data away from you you can still copy it. There is something deeply wrong about locking filesystems even from read access. GrapheneOS should at the very least give a full read-only access to the fs through (possibly) limited adb access.
Absolutely! Even if they require (like with bootloader unlock) adb and screen unlock for access.
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.
Root access takes agency away from you and gives it to 3rd party software. It doesnt expand freedom at all, it just allows other software to abuse the user.
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.
I just don't get why we need to argue about something — the right to general purpose computing — which has been answered decades ago?
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.
We're still arguing for several reasons, one of them is that people still confuse the user with the owner, as you do. "The user must be able to override" is implies that if you have physical access to someone's phone, you can install a keylogger before handing the phone back its owner. Nice for you but I imagine the owner might still quibble, even if you quote TRON.
If I hand my windows laptop to someone, they can also install a keylogger.
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.
Being the administrator and being able to sidestep OS protections are not the same thing. Without root, the user is in control of what application does what and how. With root, the user is not. Root is not freedom or ownership, like many try to claim. Root is a hacky shortcut to proper functionality. 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.
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.
Being an administrator is being root. That's the entire point. That whatever restrictions an app has set, I can override it if I need to.
> 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.
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.
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.
> 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.
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.
>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.
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.
> 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.
>The vast majority of scams literally work by them asking their victims to buy cryptocurrency or gift cards directly. Malware is exceedingly rare.
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!"
It is not an OS with bubblewrap, you can still mess up your privacy / security if you want to, that includes phishing and social engineering.
Is anything bulletproof against the user signing away their data? I think the question was whether it has any measures in this regard, not whether it's impossible to get phished
It's complicated… in a sense the bulletproof solutions are the ones that raise the cost of executing the attack above the average take. In another sense even they aren't bulletproof.
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.
> do you happen to know whether that includes anything wrt. phishing or social engineering?
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.
my brother in Christ, people who root their phones don't fall for "Hello sir, I'm sir John from Microsoft, you have virus sir, please do the needful install antivirus and send gift card sir."
Right, instead they download shady magisk modules that promise them free fortnite skins.
1) Anyone can fall for a scam. Especially those who believe they wouldn't fall for a scam. This is why ridiculing those who fall for [a] scam is harmful, and serves scammers. 2) You can root a smartphone for someone else's usage. For example, I can install pmOS on a smartphone and hand it over to my kid.
You’re right, they just fall for installing updates or CLI tools which install compromised dependencies and run wild on a rooted system before getting caught 24 hours later.
on their phones?
also, 'rooted' means you have root access, not that you run everything as root.