They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems.
QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.
I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
At checkout they looked at me like I was up to no good when I said I didn’t want to give them my name, address, and phone number just to purchase the device. I didn’t set up a plan. They said it was for “restocking” or something.
Fortunately they accepted obviously fake info. These front line sales people just don’t care as long as they can say they followed the policy.
The user containers are very helpful. I have to have TikTok for work and I put it in a container all by itself with a vpn on kill switch. And for one app that needs google play services, I have it a container with that.
The duress passcode is super clever, too. You enter a different device passcode and it just wipes the device.
You mean different user accounts? Those are available on stock Android, too.
Samsung also has "secure folder" which isolates apps and files and presumably uses multiple users to do the isolation.
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
Loving it.
I’m just wondering what the selling point for using Graphene with Google is. Very Graphene curious.
I don't think most people use Google services out of choice anyway, but more because sometimes that's the only way to get functionality you may need.
Google Play Services is a dependency for some apps, and GrapheneOS allows for people to take steps to protect their privacy while still being able to use those apps.
First, with GrapheneOS google play services run in a sandbox like any other app. (play services have more privileged access in vanilla android)
It also works well with a multi-user setup. The default account in Android is the "owner account" and in GrapheneOS (and AOSP) you can use the owner account to create multiple distinct user accounts on the device. Then, you can only install google play services in one user account. Google play services won't start if you're not logged into that user account.
Google play services won't have visibility into your other user accounts and what you're doing there. And even in your account with play services installed, there's a bit more privacy because of the sandboxing (although I believe google play will know all of the apps installed in that user account)
There's a full explanation here: https://grapheneos.org/usage#sandboxed-google-play
yjftsjthsd-h•2h ago
It really is sad that there isn't any ROM with Graphene's permission and sandboxing features while still leaving the user in control. IIRC it's theoretically possible since they publish the code, but one assumes it would be a non-trivial effort:\
ranger_danger•2h ago
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
yjftsjthsd-h•2h ago
Yes, I'm sure it is. But I don't consider that a tolerable tradeoff, and I believe we could have a system that has most of the best of both worlds.
cakealert•2h ago
The same is true even of an operating system such as QubesOS. And it's a minimal risk.
Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.
bbarnett•1h ago
But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.
yjftsjthsd-h•2h ago
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think
> An accessibility service trivially has root access.
is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.
> In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.
> A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
Agreed, that's not what I want.
ranger_danger•1h ago
With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
> including use of fingerprint/PIN/password to authenticate
IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
yjftsjthsd-h•1h ago
So you're using a version of Android patched to remove all permissions? After all, in your threat model all apps can get permission to use the microphone and camera, make phone calls, access fine-grained location information, read and write files at will, etc. Frankly, I'm not sure what they'd get out of root at this point.
> IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
Likewise, surely this applies to any permission system, and every other permission. The system UI controls every other permission in the system; if we assume it compromised, then everything else is already lost.
codethief•1h ago
A permission that allows them to hide that they have access to everything, including other apps' data?
yjftsjthsd-h•1h ago
ysnp•1h ago
Would this have been easier or more possible if Android had a full capability-based security model?
yjftsjthsd-h•1h ago
[0] This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.
ysnp•1h ago
For what it's worth, my understanding is that this has always been the position of GrapheneOS too. Given the resources and enough benefit/cost to allocate, the project would rather integrate or implement usability features at the OS level instead of encouraging people to expose attack surface. Specifically because GrapheneOS is a project meant to be primed to defend some of the most intimate and personal aspects of a person's life.
yjftsjthsd-h•54m ago
subscribed•1h ago
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
jampekka•1h ago
bornfreddy•1h ago
paulhart•1h ago
jampekka•1h ago
https://www.chromium.org/chromium-os/developer-library/guide...
codethief•1h ago
jampekka•1h ago
oneshtein•20m ago
sfdlkj3jk342a•1h ago
yjftsjthsd-h•1h ago
I don't want adb root access? I want to be able to run apps with root access.
fsflover•1h ago
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
IlikeKitties•34m ago
yjftsjthsd-h•1h ago
> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.
> I dint understand why you insist on this massive risk to be laid on on everyone.
Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
crapple8430•1h ago
See: github.com/chenxiaolong/avbroot
charcircuit•48m ago
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
oneshtein•26m ago
It's true only if user is the threat for the user, e.g. a user with low IQ but high curiosity, but such user usually cannot install GrapheneOS.
treyd•22m ago
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.