Introduction to GrapheneOS(dataswamp.org) |
Introduction to GrapheneOS(dataswamp.org) |
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.
I use a google account for convenience for some purposes, and host my own email (out of principle, not exactly super interesting material). It would be nice if when I enter the 'duress' password it erased everything except the gmail related activity.
A physical pop-up? The online google store requires a google account that has your personal info already..
That's a thing in the US? Here, clerks in various stores ask me for postal code but nothing else and I could refuse giving that info.
You mean different user accounts? Those are available on stock Android, too.
Our more prominent 2-factor fingerprint authentication feature is also relevant when switching between users a lot.
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
Edit: "experts" > "workers"
Although GrapheneOS puts a lot of work into sandboxing and protecting against Google Play, don't assume that you have to go that direction.
An alternative direction, if you wish, is to simply minimize the set of apps you use. And maybe it turns out that you don't really need anything from Google Play.
For example, I limit myself to a few open source apps (e.g., email, TOTP authenticator, maps, calendaring).
Anything else, either I don't need to do it from my phone, or I can get by with the Web site version of it in the phone's Web browser.
I also recently went through and deleted some open source apps that were a good idea to try, and which initially seemed like a good idea to keep on hand, but that I really wasn't using, and didn't expect to use without opportunity to reinstall them, so were just clutter and risk (e.g., Matrix, XMPP, Signal).
Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
I found the profile feature to be only slightly more convenient than having two physical devices. I could not find any real use for it. I thought I'd set up a work profile to attach to my work gsuite account. Nope, unsupported. I can't attach my work google account at all. Maybe I can just put all my google play dependent apps in a profile? Sure, but to get to them is just about as convenient as rebooting the phone from cold. And notifications are not forwarded to other profiles. If an event happens in another profile, you get a notification that there is a notification. You still have to drop everything to reboot into the other profile to check that you got an emote reaction to your Discord message. Great use of my time.
The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices.
I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
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:\
And, I still haven't been able to get it to properly support Google Fi, wherever I switch profiles it confuses the carrier and my access gets reset.
My solution has been to have two phones, one with Google Fi that I use to hotspot my Graphene device. Everything else seems to work fine on Graphene, including Uber and maps and calendar and VPNs and isolated profiles for gaming vs work vs socializing, etc
Note Google Maps used to work without sandboxed Google Play without account-based functionality and it having a hard dependency on Google Play happened around a year ago or so.
The recommended app is "Shelter". https://f-droid.org/en/packages/net.typeblog.shelter/
Secondary users, work profiles and Private Spaces are standard Android features but GrapheneOS does provide improvements to secondary users and Private Spaces such as control over clipboard sharing with a Private Space, enabling having a Private Space for each secondary user, cross-user notification forwarding, etc. https://grapheneos.org/features has a good overview of most (not all) GrapheneOS features.
Loving it.
Also, does this let you setup very restricted accounts like something for my parents so they can't go installing malware from the play store? (Parental controls are week in play store and malware rated for everyone in "weather" apps and the like)
It's easy to set things up far less efficiently on GrapheneOS. As an example, Signal's WebSocket push fallback when Firebase Cloud Messaging is unavailable via Play services is quite inefficient. There's the Molly fork of Signal with support for UnifiedPush which has efficient alternatives to FCM, but since Signal's server doesn't support it this requires a MollySocket server to convert to UnifiedPush. There's at least one public provider. If you simply use FCM as you do on the stock OS then you wouldn't have any extra battery drain from running multiple often less efficient push implementations. It's common to want to avoid FCM to the extent possible, so people often do set things up less efficiently, but it's not because of GrapheneOS.
> Also, does this let you setup very restricted accounts like something for my parents so they can't go installing malware from the play store? (Parental controls are week in play store and malware rated for everyone in "weather" apps and the like)
You can use user profiles for this as you can on standard Android. If you want parental control software for those profiles, that's something you need to install. It's supported, but GrapheneOS is not going to specifically provide parental control and monitoring features rather than only the standard device/profile management APIs usable for it.
This doesn't however, prevent your parents from installing it again (it is installable from the GrapheneOS app store and therefore relatively easy to install), and then going nuts with installing whatever malware their storage can hold.
The user profiles was slow to set up and not having shared filesystem between the user profiles creates friction. But I love that I can effectively sandbox my work apps, sandbox the Zuck apps etc, with different VPN profiles for each user.
Getting a burner google account (for gplay services) is a PITA if you are determined to get a clean slate from Googles tracking. Gplay is the only safe way to get certain apps at the moment, and make certain apps pass the device integrity checks.
I suspect one of the biggest barriers to mass adoption will be the fact that tap to pay doesn't work. IIUC apple/google pay are generally considered a privacy and security improvement over physical cards, since you don't give every merchant your actual card number.
Overall love the project and really nice to see such high quality open source software.
It's worth noting this is a standard Android feature along with work profiles and Private Space which are nested in another user. Private Space has built-in sharing functionality and work profiles can have it via the management app.
GrapheneOS enhances user profiles and Private Space but doesn't add the baseline features.
> I suspect one of the biggest barriers to mass adoption will be the fact that tap to pay doesn't work. IIUC apple/google pay are generally considered a privacy and security improvement over physical cards, since you don't give every merchant your actual card number.
Curve Pay, PayPal tap-to-pay and a bunch of European banks provide tap-to-pay support. Google Pay doesn't allow GrapheneOS but works on it on a technical level so if it was tricked into believing it was an old stock OS device, it would work, but that's not something feasible to keep working as they don't want to allow it.
But there are some exceptions out there so you need to be more specific.
Although, keep in mind, this is subject to change. All they need to do is just introduce the requirement in an app update, and then you're screwed.
Reminder: It forces you to use hardware suspected as compromissed from Google. Even this same month they were advocating you to use Tor, a VPN created and sponsored by the same agencies trying to get your private data.
Read other comments here, many others will point out the obvious red flags. It isn't spontaneous either that every day or so there is an article about this distro.
Don't fall into this trap, there are other options out there that deserve your attention.
GrapheneOS doesn't advocate use of Tor. See https://nitter.net/GrapheneOS/status/1945623621457600929#m You have gone on a quest to criticize GrapheneOS across social media just because a GrapheneOS moderator shared a screenshot for the TorVPN app : https://primal.net/e/nevent1qqstmnf2qj09j7t2gthgdhr72ghmvn08...
My conclusion is "It seems every single day there is a new disingenuous comment on GrapheneOS-related posts from you based on a heavy misportrayal of a social media post made on the personal account of a GrapheneOS moderator. It isn't spontaneous. Don't fall into this trap."
Unfortunately, now that CalyxOS has died, the other choices are all forks of LineageOS (Iodé, /e/). The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet.
I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.
Note that Google is in active talks with an major Android OEM for a few months already to help them meet the requirements for a subset of their future devices. They are very optimistic about that.
* The community is unnecessarily toxic from what I've seen: there's a lot of following dogma without asking "why". It leads to this very insular userbase that often turns outwardly toxic towards other projects, which is an issue that goes forever unfixed (ie. This post on the F-Droid forums originally was far more aggressive towards the F-Droid project before moderators edited it to be less aggressive: https://forum.f-droid.org/t/google-will-require-developer-ve... ). Other, older places I've seen this come "from the top" include hostile relicensing of Vanadium's patches to prevent other Chromium forks from making use of them.
* Instead of blockading SafetyNet as being a user hostile solution, GOS instead... implements their own version of it. Which is hard to see as anything other than basically recreating the same walled garden you get on stock Android.
* Pixel exclusivity is dumb and remains dumb. Pixels are very mediocre devices from a usability angle; they're large, have pretty inefficient battery life and in my experience are prone to becoming hot very easily. (I also managed to randomly brick one during a routine stock system upgrade, so there's that; not on GOS obviously, just noting that the Google side of the flagship Android is pretty lackluster too.) There's also a forever hypocrisy in defeating Google spying... by giving more money to Google. The motives for this seem to mostly be tied to a promise about the Pixel's security chip being open sourced eventually, but this is a forever promise Google isn't willing to cash out on. GOS has a token line on their site saying that most patches can be used on other OSes with little effort, but there's zero effort from any community to actually make these. (The reason for this can be blamed squarely on point 1; there's an insanely hostile reaction to anyone trying to do a fork for this sort of thing, which is basically enabled by the lead devs because of what they did w/ the Vanadium license.)
* Finally, GOS doesn't let you do hosts based adblocking, instead encouraging you to use the Android VPN service instead. A simple solution... that isn't really realistic because the Android VPN service only covers running one VPN at a time, meaning you have to pick between adblocking and privacy/accessing your own internal network.
Finally, a broader problem is that from what I can tell, GOS as a project doesn't quite grasp the relationship between app developer and app user and how it's become toxified over the years. Things like their ongoing signing beef with the F-Droid project (an incredibly niche issue that doesn't matter for most users) suggest to me that GOS is at best extremely naive/unrealistic on the issues that affect app usage for the common user. The problem these days is usually the developer going bad, not a third party.
0. https://web.archive.org/web/20250123135603/https://github.co... 1. https://www.youtube.com/watch?v=Dl1x1Dy-ej4
I'm not using GrapheneOS (I am unwilling to give Google money directly), but I did recently move to my second Android phone after having been a decade-plus iPhone user.
When I got my first Android phone I decided to "sideload" all non-stock software on the phone. I never have setup a Google Play account. I kept all the APKs for the software I loaded over the three years I used the old phone.
When I got the new phone I loaded all the software I use day-to-day and imported my SMS, contacts, and call logs using a nice FOSS app[0]. It felt remarkably like moving to a new PC does. It was nice.
You definitely don't need Google Play to get a lot of functionality. I have run into a number of apps that I can't get to "sideload" (basically any xapk-packaged apps) but I don't need any of the badly enough to care.
I am really sad Google is ending this moving forward. Jackasses.
The biggest factor that forced upgrading was poor call quality on the dumbphones I tried. (And this was really forced by bombing a particular important phone call because I couldn't be understood well.)
Then, once I found a smartphone that I kinda liked (GrapheneOS, after Apple sold out on surveillance), there were reasons to start carrying it. Rather than simply keeping it in a drawer at home.
But fortunately not sufficient reason so far to go full Google Play.
Email, Web, maps, authenticator, camera, and calls are all things I sometimes could use when out.
Though I normally don't have to have any of those, but I've been experimenting with it for a year or so, and seeing whether it's worthwhile.
This just isn't true. Switching profiles is nothing like rebooting the phone. It takes about 8 seconds to go thru the entire procedure. That's including about 3 seconds to load the 2nd profile (even an unloaded profile). The procedure on my Pixel 7 goes:
- Swipe down to open the Notification Panel
- Swipe down again to expand the Quick Settings
- Tap the User icon at the bottom
- Select the user profile you want to open
- Wait 3 seconds
- Enter the 2nd user's PIN to log in
That's 4 taps + 3 seconds of load time.
Apart from having to tweak some location permissions for when I wanted to copy the BankID credentials from my old phone I haven't had to any tweaking or anything to get it to just work.
Google Play and associated services are not bundled with GrapheneOS, they are completely optional.
> I found the profile feature to be only slightly more convenient than having two physical devices.
User Profiles is a feature inherited from AOSP. This is what AOSP says about the feature: "Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty."
In the community it is popular to use multiple profiles to compartmentalise personas or group apps with hard google service dependencies together, but this is all completely optional. GrapheneOS as a project gently suggest keeping everything in the same initial owner profile and then moving things around to suit your comfort level.
> It's my device, not google's, and certainly not Graphene's.
You've clearly endured a lot of frustration when using the OS. Are there any specific things you remember trying to do that were blocked or prevented by GrapheneOS? It's not a project with unlimited resources, but actionable information about limitations and bugs can potentially be addressed if known.
#!/data/data/com.termux/files/usr/bin/bash
PACKAGE="com.google.android.gms com.google.android.gms.policy_sidecar_aps com.google.android.gsf com.android.vending"
PATH="/data/data/com.termux/files/usr/bin:$PATH"
command=$(echo "$0"|cut -d: -f2)
pman () {
action=$1
shift
for package in $@; do
sudo pm $action $package
done
}
case $command in
disable|enable)
pman $command $PACKAGE
;;
*)
echo "command '$command' not supported"
;;
esac
exit 0
Notice that the script can enable/disable multiple packages by adding package names to the $PACKAGES variable.
I enable and disable things like Google Services manually but the scheme can be extended as much as you wish, eg. by creating spin lock files to indicate whether a specific package is needed as a dependency for another package. This is left as an exercise for the reader.
Disabling Google Play apps as you're describing will heavily break other apps and will cause lots of issues. It will not reduce what they can do or access. It's not an alternative to the privacy or security features provided by GrapheneOS. What the person above is describing has little to do with GrapheneOS specifically and doesn't make sense as an approach to using it.
Recommend reading https://grapheneos.org/features and looking at https://eylenburg.github.io/android_comparison.htm for an understanding of what GrapheneOS provides.
Shizuku helps normal apps to use system APIs without root. You can enable it with from a computer with adb or from the phone itself using wireless debugging. Hail uses Shizuku's API access and lets you select apps to freeze. You can then unfreeze / refreeze apps with a quick tap in Hail.
If you already have root, all this becomes easier. If you do the wireless debugging method, Shizuku's API access won't survive a reboot. You'll have to go thru the wireless debugging procedure again before you can use Hail. https://shizuku.rikka.app/guide/setup/
https://eylenburg.github.io/android_comparison.htm
/e/ regularly lags many weeks and months behind on essentially privacy and security patches for Android, the browser engine used by many apps, the Linux kernel, drivers and firmware. It doesn't preserve the standard Android privacy and security model either. It isn't safe from a privacy or security perspective for those reasons. It doesn't take a nation state attacker to exploit not having patches for many known browser/OS privacy and security vulnerabilities.
Despite the misleading marketing, /e/ always uses multiple Google services and integrates them into the OS with privileged access unavailable to other services. They automatically download and run Google code with privileged access along with giving privileged access to certain Google apps when they're installed including Android Auto.
Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches:
https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nich...
Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service:
https://community.e.foundation/t/voice-to-text-feature-using...
Information from the founder of the Divested projects:
Issues with /e/: https://codeberg.org/divested-mobile/divestos-website/raw/co... ASB update history: https://web.archive.org/web/20241231003546/https://divestos.... Chromium update history: https://web.archive.org/web/20250119212018/https://divestos.... Chromium update summary: https://infosec.exchange/@divested/112815308307602739
I personally don't use the separate user profiles at all. I agree they are clunky, due to how segregated they are. though with a work profile, and if needed (I don't use it atm) the newly added android feature, a private space, I feel there are plenty of compartmentalisation/sandboxing options available within a single user profile.
There are no restrictions on what people can do added by GrapheneOS compared to the Android Open Source Project / stock Pixel OS.
> Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
GrapheneOS doesn't come with Google Play. You would have had to install it yourself and those run as regular sandboxed apps with no special access. It doesn't make sense to turn it off and on which will break apps set up to depend on it. If you only want to use it with specific apps when needed, the right approach is using a dedicated profile for it. By turning it off, you were breaking apps installed in the same profile with it which use it.
Using a single profile with sandboxed Google Play is perfectly fine and doesn't ruin the privacy and security provided by GrapheneOS. Putting it into a separate profile is optional. Sandboxed Google Play are regular apps in the regular app sandbox with zero special access or privileges. Using multiple profiles to split things up is a more advanced approach.
> I found the profile feature to be only slightly more convenient than having two physical devices.
That's the purpose of secondary users. There are also the more convenient work profiles and Private Spaces. All 3 of these features are standard Android features. GrapheneOS enhances user profiles and Private Spaces in various ways but they're not at all mandatory and there's nothing pushing people to use them more than the stock OS. There's a widespread misconception that the sandboxing of sandboxed Google Play is tied to profiles but it's not.
> The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
GrapheneOS deeply cares about user experience including app compatibility. We have limited resources so we haven't been able to replace or overhaul all of the AOSP apps yet, which is the main weakness of the out-of-the-box experience. Those can all be replaced by the user's choice of apps.
> Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
No, not at all.
> Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Profiles are an Android feature, not a GrapheneOS feature, and only a tiny portion of our features have to do with them. The features page at https://grapheneos.org/features covers most of the features added by GrapheneOS, and very little of that has to do with profiles. It sounds like you chose to heavily use secondary users and didn't like that, which has little to do with GrapheneOS specifically.
> Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices. > > I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
GrapheneOS did not create Android's user profile feature. It makes enhancements to it but it's not a major focus of what we work on. You aren't missing many of the GrapheneOS features if you don't use user profiles. Enabling more standard user profile functionality, notification forwarding, allowing more user profiles and a few other minor things are all we do with those. We have a substantial set of privacy and security features and nearly none of it has to do with profiles. Adding clipboard control to Private Space and enabling making Private Spaces in secondary users are how we improve those. Many GrapheneOS users only use an Owner user or Owner with a Private Space and/or work profile. Secondary users are a much more specialized thing. It's not expected that people split things across a bunch of secondary users, that's an advanced power user approach.
See: github.com/chenxiaolong/avbroot
I don't know if there's any good solution to this, since all this seems to be necessary for the security model.
EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other) Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?
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.
> 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.
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
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.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
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.
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.
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.
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.
Would this have been easier or more possible if Android had a full capability-based security model?
> 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.
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
Edit: I am a web security researcher and longtime user of GrapheneOS and have always been impressed by the features, frequent security updates, and focus on usability, security, and privacy. They've upstreamed numerous security improvements to Android and other open source projects (so if you're running Android, they've probably made your phone more secure!).
https://grapheneos.org/faq#upstream
I encourage folks to join me in making a regular small donation to the project if you have some cash to spare. They're doing good work.
* If an app wants to access your contacts, you can choose which contacts, and you can choose to feed them a "fake" list (which is an empty list). Same for storage.
* You can choose not to give network access to an app, and the system will tell the app that there is no signal all the time.
The other very nice feature is that the Google Play Services and Play Store aren't running as system apps (i.e. they don't have root access): they just run like any other app. So you can choose not to share your contact list with them, for instance.
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 apps are still in a sandbox.
Location services and other features can be provided by non-Google services.
I know the OS itself isn't siphoning data; With my Oneplus 12 I had to check both Google and Oneplus configs to make sure I wasn't leaking anything.
I can disable network access for apps.
I can limit app access to Contacts and files with "scopes". For example, I have Whatsapp for only a few known people. Whatsapp demands access to your contacts. I can set up a scope called "Whatsapp Users", add only my friends to it, and then give Whatsapp Contact access to that scope.
Pixel is better hardware based on project's security requirement. you're simply wrong here.
Most of what you're complaining about are upstream Android limitation and problem.
I'm a GrapheneOS community moderator and I would disagree with this take. If people have issues with the community and feel that they can't ask "why" then a moderator should help with that. I can assure you we've had talks with "supportive" community members who cause problems. Being supportive of the project doesn't mean they can get away with acting rude towards others.
As for the F-Droid post, I never even heard of that post. I don't recognize the username of the user who posted it either. I guess I won't be able to see the original aggressive post, but either way just because someone is a fan doesn't mean the rest of our community is toxic.
> Instead of blockading SafetyNet as being a user hostile solution, GOS instead... implements their own version of it.
SafetyNet was depreciated, so you must be talking about Play Integrity. We don't reimplement Play Integrity, but rather have Sandboxed Google Play, and have even taken steps to reduce its effect on GrapheneOS users, notably optionally blocking API attempts or returning a server error (I forget) and blocking Google-injected code from running in apps that have automatic protection enabled in the Play Developer Console.
Outside of some workarounds, apps that expect Play Integrity verdicts can refuse to run if they choose to. Blocking things won't change that. Spoofing is also not practical because Google can and will break spoofing every time, especially since GrapheneOS has so many users. They already do that for people who root and use various spoofing methods.
> Pixel exclusivity is dumb and remains dumb.
Only Pixels meet the project's requirements as of now. GrapheneOS is in talks with a major OEM for them to get a few of their devices to meet the project's requirements and have official support for GrapheneOS. If all continues to go well, we expect it'll be 1-2 years before this happens.
> GOS doesn't let you do hosts based adblocking
There are apps and VPNs that can do this kind of thing.
> GOS as a project doesn't quite grasp the relationship between app developer and app user and how it's become toxified over the years > The problem these days is usually the developer going bad, not a third party.
The way you're talking here and your mention of F-Droid earlier leads me to believe you're a supporter of F-Droid. The project's advice is just that: advice. People are free to ignore that advice.
GrapheneOS is far from the only group that talks about issues with F-Droid. I don't personally know of all the issues with F-Droid, but as I understand it they use out of date servers, out of date build environments, and other similar issues. Also, they don't actually audit code at all, so developers can still sneak changes past them as long as the developers' changes aren't caught by their basic scanning. There's even the case where the WireGuard developer made changes that break F-Droid's terms of use or something like that. They were making those changes very much in the open and the F-Droid team didn't even notice. If a developer was trying to hide malicious changes, they could easily do that. No, we still have to trust developers. F-Droid is just another trusted party, and they don't deserve that trust considering all the issues they have.
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.
>They have not said anything like that.
Quote (https://news.ycombinator.com/item?id=30769666):
> Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required.
The reality is that Librem 5 is secure according to a different threat model than the one GrapheneOS follows. This doesn't make it "incredibly" insecure, unless you believe that only you can define good threat models.
GrapheneOS is focused on privacy and security overall including protecting applications and the OS from exploitation in general. GrapheneOS does use sandboxing and compartmentalization to improve security. Hardware-based virtualization is one of the GrapheneOS hardware requirements (https://grapheneos.org/faq#future-devices) and is used through Android's virtualization framework. It's provided by pKVM on Pixels and Gunyah on Snapdragon. Making more use of virtualization beyond isolating system services via microdroid and running a desktop OS via Android's virtual machine management app (Terminal) is planned and being gradually worked on. It's part of what we work on overall, not the whole picture or primary focus. It will be a bigger focus over time as hardware improves to make it more viable.
Smartphones didn't have a lot of memory for virtualization until recently and GrapheneOS needs memory for other protections too. The Pixel 6 was the first Pixel with CPU hardware virtualization support and the Pixel 10 is the first with native GPU hardware virtualization support not requiring proxying to the host for GPU acceleration. Secure GPU acceleration is quite important for making it into a highly usable feature, especially on a phone, so the hardware was not ready yet and still isn't on most other devices. QubesOS largely doesn't have that available either, but laptop or desktop hardware is more powerful.
Why would you need that if you don't run any untrusted apps in a trusted VM? Also, you don't have any private information in the untrusted VMs. It might only be helpful in the context of security in depth, but this barrier for attackers is much lower than the virtualization itself.
> data extraction in the After First Unlock state
By whom? A physical attacker?
> Hardware-based virtualization is one of the GrapheneOS hardware requirements
Qubes doesn't force the user to have it. Could GrapheneOS also allow using devices which don't support it? It would make millions of people more secure, not less. And it would make GrapheneOS more popular, too. You could name it "GrapheneOS lite" if you're afraid of a false security message.
> Applications and guest operating systems are just as vulnerable to exploitation
Which exploitation? Where would it come from?
I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
Indeed, this is where we disagree. "If you are protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned."
I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.
fwiw, Louis Rossmann's employer/key supporter has disbursed grants to GrapheneOS and associated projects.
> Plenty of people have asked for this feature on GitHub
The issue has been deleted, but from the archive, (assuming the "lead developer" jab is aimed at Daniel) Micay says, "This is an issue that's going to be fixed and not a reason to change this." Then goes, "Please use reactions on the top level issue instead of adding comments expressing support for a change. You're sending unnecessary emails to the project developers."
As someone who maintains rather unremarkable FOSS projects, saying NO to feature requests is not at all easy in that it irks the community to no end, let alone one as large as Graphene's. Everyone is quick to reach all sorts of conclusions and pass judgements.
> ... the way the lead developer responds makes it look like there are some serious unresolved mental issues at play
afaik, there's 3 directors (also developers, from what I can tell) who steward GrapheneOS. Don't suppose they are all "mental"?
https://www.canadacompanyregistry.com/companies/grapheneos-f...
> FUTO made a $40k donation to GrapheneOS supposedly with no strings attached. They ended up being unhappy with us not making content with them and promoting them.
Don't post another link or quote from anywhere else. You provided that link as evidence and I want to see specifically what it is you expect people to take from it.
I don't use call recording and also don't care about some guy I've never heard of ranting for 18min about some pointless comment he made on youtube causing drama (but I do care about NFC payments so that's why I haven't tried GrapheneOS yet).
It's a communication issue at the core, and always doubling down is not making it any better.
It portrays the whole project as being unreliable.
Many people enjoy participating in harassment towards an open source developer when they have a disagreement with the project such as our requirements for accepting a pull request for automatic call recording. We've said we won't accept it without showing that it's active so that people are aware calls are being recorded when it's enabled. That's more than enough for some people to participate in harassment.
Hacker News shouldn't be permitting it over and over again.
What I see here is someone who wants a feature, a feature that many people want, but it hasn't been added for reasons listed in the GrapheneOS issue tracker. No one was rude or anything there in that link you shared that I can see.
> the lead developer responds makes it look like there are some serious unresolved mental issues
To say something like this is extremely out of line.
> Louis Rossmann’s video
What you fail to mention here is incredibly important context, but leaving that out conveniently supports the narrative that Daniel is crazy. Biggest fact there is that he had just been swatted multiple times. Louis commented on another harassment video and Daniel was understandably upset. By the way, the swatter had been in contact and even told GrapheneOS project members that they were a fan of the YouTuber who made the first video. So, attempted murder by some other person, a "friend" was supporting harassment content making him out to be "crazy" and comments on that video showing support for it, then, knowing that, Louis records a video of a private conversation in real time. The video itself was filled with lies and misrepresentations. Even the title was a lie because Rossmann continued to use GrapheneOS for long after that video was released.
Not to mention the fact that targeted updates aren't even possible on GrapheneOS considering how updates work and the infrastructure. Louis may not understand these things, but even though we and others have pointed this fact out multiple times, the video remains up. The video is clearly meant to do one thing: damage or destroy GrapheneOS.
That post has been deleted.
As far as I can tell, nothing has changed other than obscuring the leadership of the project a tiny bit. strcat is still active here in the comments.
?
Normal, unmodified Android systems report back that they are untouched. The system detects LineageOS, /e/OS, Graphene etc as modifications though, so then it reports that the system is compromised. As an option, it can be hacked, so it reports A-OK even on a modified phone - but this hack is prone to breaking, and not the easiest to do to begin with.
It's not straightforward which apps need this thing. I found a compilation here:
https://xdaforums.com/t/apps-games-need-pi-list.4677050/
But the list has YouTube, and I can report that I'm happily using that for years on a phone without this mechanism, so, I cannot vouch for this list.
But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.
microG itself has functionality requiring downloading and running Google executables as part of itself. It doesn't change the fact that apps depending on Google Play are using Google Play libraries often making connections on their own without Play services.
GrapheneOS sandboxed Google Play compatibility layer provides far broader app compatibility while giving strictly less access to Google Play code. Sandboxed Google Play runs as a set of regular apps with no special access or privileges. It's the same app sandbox the apps using it run in with the Google Play SDK and libraries built into them. GrapheneOS improves the app sandbox and permission model substantially, which applies to sandboxed Google Play in the same way.
GrapheneOS implements functionality such as location services via the OS and reroutes apps using Google Play APIs to the OS APIs. We have our own network location and geocoding implementations in the OS. We're building our own fully local text-to-speech and speech-to-text services right now.
It's not quite that simple; it still contacts Google servers as soon as you enable push notifications, for example, which then won't run in a sandbox.
Never enabling any such services is possible, but you have to be somewhat careful about what you're doing.
I don't want adb root access? I want to be able to run apps with root access.
A user's web browser, messaging app, etc. getting exploited is going to result in an attacker getting their data from it and the OS. Containing it within a VM limits damage to that VM which depends entirely on how the user has split things up. It's not a substitute for protecting against exploitation of containing successful exploitation within applications or operating systems.
> By whom? A physical attacker?
It's in reference to situations where disk encryption matters to prevent data extraction. One of the two purposes of verified boot is as part of an overall approach to protecting against data being extracted from the device.
> Qubes doesn't force the user to have it.
No, it does require it. It works without extra features for properly containing devices, etc. but does require hardware virtualization support in the CPU. They do have mandatory hardware features.
> Could GrapheneOS also allow using devices which don't support it?
Without hardware-based virtualization? It could allow it, but then the functionality we build resembling how QubesOS does compartmentalization won't be available to users on those devices. There are much more important security features in our requirements than this. Hardware-based virtualization support was added there because any devices we'll support in the future are going to have it anyway since it's a standard feature on Snapdragon. We avoid adding features to the list which would rule out supporting a 2026 or later Snapdragon device. Memory tagging was an essential feature which is game changing for security when deployed throughout the OS and for apps, which is why it was added as a requirement despite Snapdragon temporarily losing it. Snapdragon had a very early implementation of memory tagging and then lost it due to their custom cores prioritizing performance and cost over security.
> Which exploitation? Where would it come from?
Remote attacks on the applications and OS running in the VMs. Alternatively, supply chain compromises or other forms of attacks against the applications, etc. These are the reasons why QubesOS is providing compartmentalization in the first place. However, it does not protect what's inside each VM from attacks against what's in that VM. It protects other VMs after that VM gets compromised. It depends entirely on the user dividing things up well and limits the damage of a compromise rather than avoiding it.
For example, if the user's main everyday usage web browser instance they use for most things get remotely compromised, then they're going to have all their logins, passwords and other data in that VM obtained by the attacker but other VMs will be safe. It's containing the damage, but it's still very bad. If someone divided up their web browsing heavily between VMs, they'll limit the damage more, but it could be one of their most important instances which got exploited.
For example, a journalist may run an email client and web browser related to their work in a VM which may be targeted, get exploited, and now a lot of their most important work related data is available to their attacker. The compartmentalization will likely protect their personal life, etc. but the same exploit could be used against their email client / web browser used for personal usage too. The exploit not being prevented leaves it open for use against their other compartments too.
If this person has indeed mental issues, to publicly expose it in a degrading light does not help him, or anyone else really.
If he doesn't have mental issues then all this discussion is unjustly defaming a person and damaging perception around mental issues.
Either way this discussion is bad.
You are the one portraying the project as unreliable. I only judge GrapheneOS by the actual output being delivered, the code and and the binary that is. And if you go down the route of validating the output based on his behaviour then i would flip it on you. I would much rather use an OS developed by a paranoid guy who thinks everyone hunts them. I'd bet it's more secure.
But this is silly-talk. What matters is the deliverable. Has the project given any evidence of being unreliable or not teustworthy?
So no, it isn't as "simple" as the issue being only the literal content of that comment. The context matters.
The video is harassment content, plain and simple. It's filled with disinformation and he lied about not using GrapheneOS moving forward. The developer was swatted multiple times, then when upset with Rossmann he tried to talk to him about his support for harassment content (the swatter was a fan), and instead of being a decent human being, Rossmann made a video of it while it was happening.
Samsung also has "secure folder" which isolates apps and files and presumably uses multiple users to do the isolation.
There just aren't any open-source Android libraries for RCS out there, much less anything in AOSP.
Sadly, biometric authentication as 2fa is not sufficient for that.
The point is that you should always be some supported workflow instead of the user having to go out of their way and modifying the base system.
No, they can be installed as regular sandboxed apps and you don't need to grant them any of the standard permissions such as Location. They have the same app sandbox and permission model as other apps including all of the GrapheneOS improvements. For example, if you want to use a Google Play feature requiring Contacts access, you can use Contact Scopes instead. However, barely any Google Play functionality needs more than the added Network permission.
Location services work perfectly fine without Google Play installed. For apps depending on Google Play and using the Google Play location API, GrapheneOS redirects the requests to the OS by default. If you want network-based location for location detection without satellite reception, you can enable the network-based location service built into GrapheneOS. The only reason to give the Location permission to Google Play would be if you want to use a feature they provide depending on it such as location sharing.
cool_cherry explained exactly how I've been using it, with my main 'owner' account not having play services installed at all, only instead installed on another user, which only takes a few seconds to switch to.
you can easily install owner apps onto other user profiles. or grant/forbid the other user profiles to install apps themselves.
users are not tied to google accounts, only your google play installations.
I was able to install google play apps on 'owner' user and then uninstalled google play services and play store. if they don't require play services to function, they work fine, otherwise they just might not function or may function/look surprisingly differently when they don't have their network connections.
location, network, other permission have defaults and can set them on per-app basis like on normal android.
a unique device MAC address is generated for each wifi connection.
For example, Signal will use Google Play services for push notifications via Firebase Cloud Messaging (FCM) when it's in the same profile. If it's not there, Signal uses their own inefficient WebSocket-based push which uses significantly more power due to lack of optimization. Molly is a fork of Signal with support for UnifiedPush as an efficient alternative to FCM.
Many apps from the Play Store don't use Play services, while many others be used with or without Play services where they may have extra functionality or different behavior when Play services is available. Others have a hard dependency on it.
There are many other ways to apps to get apps than the Play Store. For getting apps from the Play Store, there's both the sandboxed Play Store and Aurora Store as options. Play Store requires an account for installing/updating apps but it can be a throwaway one like the ones Aurora Store uses by default. Note Aurora Store does not currently check the store's signature metadata to secure the initial install better than HTTPS alone.
Huh, I didn't realize they had added additional functionality not present on stock Android. Thanks!
User profiles (secondary profiles, private space) don't enhance this sandboxing. The apps already were sandboxed. What they do, though, is aid in isolation in a number of ways. The allow the use of a seperate VPN slot which can help split up identities, they restrict the IPC to communication with apps within that profile (not other profiles), they have separate clipboard, user data and non-global settings, they have distinct encryption keys and can be put at rest on demand without rebooting the phone (not possible for Owner profile).
Also, what if you ever want to share a file across user profiles?
How would they even do that? As part of the machine that checks for counterfeit notes? They don't always use that, right?
https://eylenburg.github.io/android_comparison.htm is a high quality third party overview comparing them with a focus on privacy and security.
CalyxOS was not a hardened OS either, it just didn't roll back privacy and security quite as much as LineageOS.
> The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet.
GrapheneOS is a non-Google Linux distribution. Google heavily contributes to the Linux kernel and is responsible for a massive portion of the security work upstream. The same goes for LLVM, GCC and many other projects. If you have an issue with using lots Google code including as the biggest driver of security in these projects, you're going to need to avoid Linux too.
Waydroid uses an ancient Android releases and largely disables the privacy and security model. Android apps running in Waydroid are much less sandboxed than in the standard Android app sandbox. It's not a sandbox for running Android but rather a partially working way to run an insecure fork of Android on top of a less private and secure non-Android distribution at a huge cost to privacy and security. It's not a good approach and moving to a much less private and secure OS is not progress in those areas.
They have different priorities, granted.
> They greatly reduce the privacy and security of the Android Open Source Project
That's going to depend on your threat model. Many people don't feel that having an unlocked bootloader is a significant threat.
> GrapheneOS is a non-Google Linux distribution. [...] If you have an issue with using lots Google code [...]
https://x.com/GrapheneOS/status/1964561043906048183
Even you seem to agree that we're relying too much on Google's goodwill.
They do not provide current privacy and security patches. They don't do the bare minimum to protect user privacy and security.
> That's going to depend on your threat model. Many people don't feel that having an unlocked bootloader is a significant threat.
Not supporting verified boot is a small part of how they reduce privacy and security. Lagging many months and even years behind on basic patches for vulnerabilities is a far bigger problem.
Information from the founder of the Divested projects:
Issues with /e/: https://codeberg.org/divested-mobile/divestos-website/raw/co...
ASB update history: https://web.archive.org/web/20241231003546/https://divestos....
Chromium update history: https://web.archive.org/web/20250119212018/https://divestos....
Chromium update summary: https://infosec.exchange/@divested/112815308307602739
Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches:
https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nich...
Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service:
https://community.e.foundation/t/voice-to-text-feature-using...
> Even you seem to agree that we're relying too much on Google's goodwill.
That's not what the post says at all, and it's not clear how it relates to talking about other AOSP-based operating systems.
GrapheneOS is on the 2025-10-01 patch level and has access to the Android Security Bulletins for October, November and December with the option to ship the patches early via special release channels where sources are published once the embargo ends. We'll also have early access to the quarterly and yearly releases soon, with the option to release previews of those too once that process starts. We didn't have early access to quarterly and yearly releases in time for the Android 16 QPR1 port but should have it for Android 16 QPR2. We're going to be significantly less impacted by AOSP delays than others. We can still complain about a delay in something which was supposed to be pushed on September 3rd not being done yet. It wasn't the topic here.
[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.
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.
If so, I'm glad he's still project lead. I would have immediately written off GrapheneOS as a lost cause if he wasn't.
I have spent many hours browsing his comment history and reading his extremely detailed posts on Android and smartphone security. He obviously knows what he's doing. Not only is he competent, it's also clear that he cares way too much about GrapheneOS and is personally invested in it.
Competence and actually giving a shit are the two attributes I respect most in a person. I wouldn't want anyone else making decisions.
And that's coming from a guy who publicly disagreed with him on some ideological issue literally three days ago:
They're misrepresenting our announcement. It's unsurprising since it's in the context of supporting harassment towards me based on fabrications. Unfortunately, Hacker News consistently permits baselessly calling people insane, schizophrenic, etc. and pushing fabricated stories about them.
No but when you took that cash out of an ATM, it logged the serial numbers on the bills it gave you. Then when Best Buy deposited that cash at the bank they again scanned that serial number and can make an assumption that you spent that money at Best Buy.
What that information is used for, who knows? But the flow of cash is definitely logged somewhere, for some reason!
But yes, your bank could know you were at Best Buy, maybe.
If you have knowledge of a withdrawal and even a rough ball park of that amount, then you can probably determine it was a phone purchase. If you're a big company like Google or Facebook, you're going to be pretty good at that regardless of the prior knowledge (which then can be back inferred). The tracking is not just limited to what information your phone sends out but what information other devices get. It's good to mix up your fingerprints and all that, but this only goes so far.
The social graph is a pretty critical tool for those doing the tracking, and that graph isn't just composed of other humans. Every device is constantly talking to every other device. Snoop on your radios and look at what they're doing. Things like WiFi and Bluetooth are constantly pinging things around you and this can be used for tracking if you know where certain MAC addresses are physically located. This won't work anymore, but like 15 years ago Samy Kamkar made a tool to do exactly that[0], because while they were mapping the streets they also recorded all the SSIDs, MACs, and whatever else they could get. So if you have a device like a router that is constantly connecting to something that's saying it is a phone, and you can see that that device is at a location at specific hours and you can reidentify someone by that. Especially when a device that normally fit a pattern stops fitting that pattern.
I mean some of this sounds crazy but I feel like 10 years ago we had more posts and conversations about things like [0]. Where people were doing things like tracking their friends' sleeping schedules[1], exploiting Facebook ads to microtarget and prank your friends[2], or spending $1k to geolocate your friends[3]. While it's become more difficult to exploit this information from the user side, the capabilities haven't gone away. They've only grown over the last decade and been placed behind more expensive walls. Funny enough, it is a time of the internet I missed. These things were fun, scary, motivating, and made us talk more openly about the implications of surveillance capitalism. We've only just become used to it, while the severity has significantly magnified. I mean when I deleted my Facebook account in like 2016/2017 I did a takeout and found that they accurately were able to geolocate my photos to where I was standing inside a specific room of my house, by aggregating the GPS information with the WiFi information (you have neighbors?).
I feel like we need to bring these conversations back. But I'm not sure how best we do them while being productive and not turning towards apathy. No one's going to kill the beast overnight, but I want to stress that it's at least better to reduce exposure. Apathy tends to come from the interpretation that it is binary. You're either fucked or not, and we're only fucked. But there's a big difference between a floor covered in shit and being neck deep in shit. I don't want to be in either situation, but if I had to choose then that's a very easy situation. It's also easier to clean up. So I guess... can we get more people to start normalizing things like Signal and Firefox? Or pick some other tools, I don't care. But encrypted communications and non-chromium based browsers (sorry Brave and Opera) do a lot to help. At worst they send a signal to these big companies that we care. Maybe all they see is money, but they'll care about your privacy if it is more profitable than not caring. They go with the tides, even if they don't really believe it. So they can be reigned, but people mostly don't know how to send a signal.
[1] https://medium.com/@sorenlouv/how-you-can-use-facebook-to-tr...
[2] https://ghostinfluence.com/the-ultimate-retaliation-pranking...
[3] https://www.wired.com/story/track-location-with-mobile-ads-1...
You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
Use your own keys to sign and you're golden.
The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't.
I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both.
It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
And lastly, it's okay if you don't consider it a massive risk. I do.
Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...
For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
It is my understanding that that only gives root to adb, not apps, so no.
> or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
If we're at the point of patching source trees, then no, we've left the realm of "very easy" behind. Installing Magisk is easy. Building Android from source, let alone patching it, is not.
> It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
I really disagree. Knowing when to click the allow button or not is a separate skill from building/patching a ROM from source.
> Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...
I'd love to, but you'll have to mention what they might be. Both of those links treat root as nearly synonymous with compromise but never bother to explain how that compromise would occur, just 1. root 2. ??? 3. malware. That's fear-mongering, not a threat model.
> I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
Or, we could avoid Appeal to Authority and talk threat models. The only one I've seen yet in this thread is people claiming that malware can fake out permission dialogs and that this is a problem for root permissions but somehow leaves the rest of Android's permission model in a usable state, which is... an interesting claim.
> Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
Many people making vague claims might technically be a "consensus" but it's not actually meaningful. If you've got an actual threat model, let's hear it, otherwise there's not much point to this.
Here is a recent report of widespread advanced malware looking to see if a device is rooted - https://www.lookout.com/threat-intelligence/article/badbazaa...
Here is a report of malware using root - https://zimperium.com/blog/new-advanced-android-malware-posi...
Root does not only provide privilege escalation, it also provides attractive options for exploit persistence on a device, something which is difficult to achieve on modern Android and iOS.
You are moving from a small handful of processes that get root access and are heavily constrained by selinux policies and are nowhere near userspace to putting root access behind a weak UI prompt. That is the ability to modify the system at runtime. If the system can be modified and the bar to that modification is trivially bypass-able, privilege escalation becomes monumentally easier for an attacker. Because the system can be modified *it cannot be trusted*.
A lot of the rest of this post reads as hostile FUD: /e/OS ships with microg (https://en.wikipedia.org/wiki/MicroG) that provides FLOSS reimplementations for some Google services - users can optionally choose to log in with their Google account. Providing this choice out of the box is controversial for people who want a complete and total break from Google.
No, they're describing heavily using user profiles as not being usable. User profiles are a standard Android feature. GrapheneOS provides small improvements for user profiles as a tiny part of what we do. Using user profiles is in no way required to benefit from what GrapheneOS offers. They're describing a specific way they chose to use the device that's not GrapheneOS related as not being usable. What does any of what they said about user profiles being inconvenient and painful to heavily use for isolating groups of apps have to do with GrapheneOS specifically?
> my experience has been similar
Your reply shows you lack experience with GrapheneOS.
> In contrast, I find /e/OS to be friendly and approachable as a daily driver.
This is the direct opposite of nearly everyone's experience who has tried both, which you do not appear to have done.
> To be honest, I don't care if it's a few weeks behind on ASOP patches, it's still far better than the average OEM Android distribution.
/e/ lags many months and even years behind on privacy and security patches, not a few weeks. The amount it's behind depends on the device. On the Pixel 7, they're multiple years behind on kernel, driver and firmware security patches.
> A lot of the rest of this post reads as hostile FUD
No, it's your inaccurate claims about GrapheneOS privacy and usability which are accurately described that way. Everything in my posts about /e/ here is accurate and verifiable information. People should check the third party sources I linked and do research on it.
> /e/OS ships with microg
Our sandboxed Google Play compatibility layer is also open source. Both microG and sandboxed Google Play exist to provide compatibility with closed source code running on the device. microG receives substantial privileged access and the closed source code which it downloads/runs as part of itself and which runs in the apps using it has much more access to your data than it does on GrapheneOS. The Google services themselves don't become any more open source and neither do the Google Play libraries within apps, which often don't require Play services to function.
> users can optionally choose to log in with their Google account
GrapheneOS has no Google services built in and installing/using sandboxed Google Play does not require an account.
> Providing this choice out of the box is controversial for people who want a complete and total break from Google.
GrapheneOS provides the option to use Google apps and apps depending on them but doesn't bake in privileged Google services to the OS which are always enabled like /e/. On /e/, there's no way to avoid connecting to multiple Google services or to avoid how they're baked in with privileged access. A subset of these are covered in https://eylenburg.github.io/android_comparison.htm but not the ones added by /e/, only the ones present in AOSP which are not replaced by it.
You are a partisan. I'm sure all your points are correct in some narrow technical sense, but I agree with OP: Graphene is an OS for geeks who want to geek out about security, not for normal people who want to use a smartphone without surrendering all their digital privacy.
Independent researchers have confirmed that /e/OS leaks very little data, and that's good enough for me https://www.tcd.ie/news_events/articles/study-reveals-scale-...
If you're a security nerd, live in an authoritarian state, or you're a targeted activist, Graphene is a better choice – although, really, you should be using a burner phone or staying offline.
(I googled this, cannot attest to the accuracy of these rebuttals)
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.
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.
A permission that allows them to hide that they have access to everything, including other apps' data?
All I see in Rossman's video is someone frustrated by a influential person giving a platform to an organisation that, to be frank, has shown themselves to be considerably less trustworthy than GrapheneOS. I believe strcat has been the target of harassment, I believe them because I've seen it happen and given the sensitive nature of GrapheneOS I also think it's not terribly unlikely there was an organized disinfo effort.
That I've seen "This is informative and unfortunate." come up over and over again as if it were some mantra, I guess is sorta telling. People aren't thinking for themselves, they're just uncritically absorbing the opinions of the charming people they're watching on youtube.
But the targeted update thing isn't even possible on GrapheneOS. The update server is basically a basic web server. The updates are stored on the servers and the update client downloads them. All update files follow the same naming system and the update client downloads updates using that system.
The update client never sends any IDs either.
So if GrapheneOS can't get unique IDs, then how can targeting be done? It's just not possible.
No, that's part of Rossmann's heavily fabricated story about what happened. The reality is that Rossmann's live stream and video very clearly aimed at directing harassment towards me with spin and fabrications were only a further escalation of his ongoing bullying towards me. His video is self-evidently dishonest bullying and harassment. Even the video title was a lie disproven by his own followers catching him continuing to use GrapheneOS as a daily driver with his important apps and data for many months afterwards. He did eventually move away from it, potentially multiple years later, but his claim to have deleted it was a lie, as were his claims of being scared of us replying to his attacks or targeting him with an update. It was utter nonsense to justify engaging in a massively escalated form of bullying using his community as a weapon to cause harm to someone and try to destroy their life.
Rossmann actively uses Kiwi Farms with a verified account and was very clearly catering to them. He actively seeks their friendship and respect in a thread he was actively using before and after posting the video. He's friendly with the person who posted the harassment and doxxing thread clearly aimed at causing physical harm to me and further propagating fabricated stories/claims about me. Rossmann continued to post jabs towards me and complaints about us on Kiwi Farms following that thread being posted which has acted as a regular reminder to them to keep targeting us. He continues to actively post there and engage with serial harassers.
I mean, this is only true if you pull out money once just for this one purchase. If you pull out money regularly and make most of your purchases with that cash, it would be incredibly difficult. If I pull out $500-$1000 per week in cash, with occasional $1,500-$2,000 weeks, there would be very little ability to know if I was buying a phone on a $2,000 week or a car repair. If a $1,500 week was a regular week with a fancy dinner, or a low expense week with a phone purchase.
It would be like trying to tell what you bought with the credit card you use for all your expenses by only looking at the size of the payment each month from your bank account.
Okay? I do actually think that should be blocked (good root is invisible), but I'm not seeing a problem.
> Here is a report of malware using root
To quote the article:
> In addition to collecting the messages using the Accessibility Services, if root access is available, the spyware steals the WhatsApp database files by copying them from WhatsApp’s private storage.
Note that it already uses a11y features to do the same thing regardless, but also this is another case of conveniently skipping all the important details. Seriously - "if root access is available, the spyware steals" - how did it get root access? If the "vulnerability" is that the malware asks the user for root access and the user gives it, that is not a vulnerability. A system where malware needs permission to do bad things is perfectly fine.
By the way, personal attacks are against the HN Guidelines.
GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
GOS is not running a flavour of mainline Linux, but Android. They're nevertheless planning on moving to virtualisation as well https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-r...
For now it's as good as it gets.
Do you have any statistics to show about how secure a micro-kernel is? I can't believe it can be better than this: https://www.qubes-os.org/security/qsb/
You can share with file synchronisation apps like Syncthing/Ouisync [0], exploit a temporary weakness in the isolation model with Inter Profile Sharing [1], or simply copy the files over to an external storage device and transfer them that way.
[0]https://github.com/Catfriend1/syncthing-android
[1]: https://f-droid.org/packages/me.zhanghai.android.files/
It also shows that profiles can't really prevent an app from correlating profiles on the same device, by listening on a local socket.
There are apps like Inter Profile sharing (appID: digital.ventral.ips).
Google will not using their service for tap-to-pay.
I'm okay with losing access to Google wallet while using Graphene os (I can just use plain old credit cards), but I would like to have the option to revert it in the future.
There's no such thing for Pixels, and it also doesn't void the manufacturer warranty.
(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
This is plain wrong: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
(And I think I already told you that once. Upd: @amosbatto did: https://news.ycombinator.com/item?id=30769589, and you ignored that.)
They have expressed interest in open hardware, well-designed open source secure elements, open source blob-free firmware with proper signature verification, open source greenfield kernel and OS projects, hardware kill switches with a proper threat model etc.
Why should anyone expect them to throw away everything they have accomplished to start several steps backward on platforms that don't achieve any of these things?
I don't expect them to throw away anything. I just wanted to get a statement from them concerning what's a reasonable goal and what isn't. But still:
- to break from their life-threatening dependence on Google? https://news.ycombinator.com/item?id=45208925;
- to allow more people benefit from a better security, not just those who can afford a Pixel?
> open source blob-free firmware
Where did you find that?
> open source greenfield kernel and OS projects
I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware.
> hardware kill switches with a proper threat model
Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches.
Please contact the OEMs/manufacturers and ask them why they cannot support reasonable requirements like: minimum five years of full (OS, firmwared, security patches etc.) device support code, hardware accelerated virtualisation, isolated radios (Wi-Fi/Cellular/Bluetooth etc.), a decent secure element implementation and support for throttling, proper Wi-Fi privacy support etc. (https://grapheneos.org/faq#future-devices)
You are clearly passionate about this, and you are not alone. But I have never understood why people expect GrapheneOS to compromise their goals and values, rather than wanting others to improve to meet them. GrapheneOS is completely free.
>to break from their life-threatening dependence on Google?
They have had talks with at least one OEM in the years past before the recent round of communications, trying to secure support for GrapheneOS on non-Pixel hardware. They have had builds in the past for Samsung hardware and development boards to explore alternative platforms and interest in minimal blob platforms which they had to abandon because those were not suitable for the project long term.
They have always been completely willing to support non-Pixel devices that meet their requirements, but none have been available or validated so far.
It's not appropriate at all to say they have no interest in breaking their dependence on Google Pixels. Personally, I think it's bizarre that numerous companies like Fairphone, Punkt and OSOM can come and go without ever seriously attempting to meet the reasonable requirements set by GrapheneOS and offer alternative options.
>to allow more people benefit from a better security, not just those who can afford a Pixel?
GrapheneOS is not a hardware manufacturer with the benefits of economies of scale. If they could magically create an affordable device that met their standards they would do it...
As you already understand, GrapheneOS is a project with limited resources. They put those resources to use in significantly improving the privacy/security for an operating system (OS) that guards regular people's most personal data and device. Any device they support that lowers that standard means much much more time spent on device support and much less time on important work that improves on what you can have now (GrapheneOS + Pixel 8 and above).
GrapheneOS is also open source, so nothing stops you or I from adapting parts of it for a less suitable platform and releasing that for others to use. DivestOS for example used code and ideas from GrapheneOS in their own project, and GrapheneOS were always supportive of the project and even offered the founding developer a role in the development team after they stopped working on DivestOS.
>Where did you find that?
As I've said above, it is something they experimented with in the past. But the reality is that they are intimately familiar with some past and present projects around that area including Raptor Engineering stuff, SiFive, Betrusted, coreboot, OpenTitan, Tropic Square etc. GrapheneOS has always been deeply interested in quality open source software and open hardware, unfortunately they just never had opportunities to support those things while improving on the progress they have already made.
>I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware.
I did not say Pixels are a blob-free platform. I said GrapheneOS have expressed interest in open source kernel and OS projects even outside of GrapheneOS itself.
>Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches.
No, I don't mean usability, I mean physical privacy switches with a proper threat model. GrapheneOS have stated they would be 100% interested in usable privacy switches for specific goals like stopping audio recording or location detection but it is a lower priority than other ideas they have to improve privacy/security on the device as a whole.
An attacker can do cross-guest exploits via the network too, which would not be considered within the scope of that list. As an example, if an attacker could exploit the network VM via a Linux kernel TCP/IP vulnerability, then exploit connected virtual machines from there with the same vulnerability. Network driver vulnerabilities are another way to get that initial foothold. It wouldn't be a hole in the architecture implemented by QubesOS but it would still give them control over everything that matters to the user.
I provided accurate and verifiable information. You are yourself clearly here to promote /e/ and attack GrapheneOS, which you're doing with objectively false claims about both.
/e/ has far lower app compatibility and stability. It lags many months and years behind on critical privacy and security patches. Their services were down for many months recently. It has major issues with stability and functionality across devices. Those are facts.
People can verify that what I've said is accurate along with looking at the third party sources from actual experts, contrary to the phony inaccurate study from 2021 done in coordination with /e/ that you've provided.
> I'm sure all your points are correct in some narrow technical sense
They're all accurate and not only in a narrow sense.
> Graphene is an OS for geeks who want to geek out about security, not for normal people who want to use a smartphone without surrendering all their digital privacy.
GrapheneOS objectively provides far better app compatibility and stability than /e/. It's far better tested and provides the current generation Android functionality and usability rather than being based on old versions.
> Independent researchers have confirmed that /e/OS leaks very little data
The paper doesn't claim any such thing and /e/ has added multiple kinds of invasive telemetry and services since 2021. You should check the much more up-to-date and better researched information from Mike Kuketz and Divested. Your claim that they're independent researchers is unsubstantiated and contradicted by information which has come out about the motivations and methodology behind what they published. /e/ was involved in it.
> If you're a security nerd, live in an authoritarian state, or you're a targeted activist, Graphene is a better choice – although, really, you should be using a burner phone or staying offline.
/e/ isn't safe to use due to lack of current privacy and security patches. It should be avoided by anyone who cares the slightest about privacy or security. Going years without receiving important patches for serious privacy and security issues is a severe problem.
Contrary to what you're claiming, GrapheneOS provides much better app compatibility and stability.
Murena's services were recently down from early October 2024 through March 2025, for an idea of what people can expect from the OS and services:
https://community.e.foundation/t/service-outage-announcement...
Your argument boils down to "Graphene is so secure that it's like having two phones in one: one that has a cool greyscale theme but doesn't do anything, and a sandboxed Google phone with all your apps, Google Play services, and personal data on it."
It is completely the user's choice to put sandboxed google play in a private space or secondary user profile. It is completely the user's choice to put sandboxed google play services in the owner profile and not use multiple profiles at all. It is completely the user's choice to source apps from outside Google Play.
This sounds like a great news to me, thank you.
I don’t understand these GitHub links either. None of them which I’ve seen bad at all. I don’t understand the one with strcat’s post history either. The comments which are one the first two pages are completely fine.
Apologise for what?
So I assume they didn’t apologise. Stupidly, further proving the points of “harassments”, which I can imagine exist and probably disproportional, they were just stupid enough to give data points to support them more. For no good reason.
Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?
And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?)
I hope you're at least running your laptop with selinux in enforcing mode :)
The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
If the GUI stack is vulnerable, then those sandboxes could be broken out of. The idea behind not allowing an app to access root is to remove the attack surface introduced by the GUI stack. An alternative interface to a GUI would be some physical connection (like usb-c). So accessing root exclusively via a console port or USB would be safer in theory.
This is true regardless if it's a phone or a PC.
Desktops are unfortunately waaaay behind something like GrapheneOS or iOS in terms of sandboxing. The closest in the desktop world is Qubes OS, but that's not a realistic alternative to normal OSes for the common user.
https://www.chromium.org/chromium-os/developer-library/guide...
Also no matter how technical you are, it's almost impossible for you to detect zero-click 0days for which you are more vulnerable to than people without root privileges. You running rooted OS actually become easier and less costly target than people without rooted OS.
I doubt that user-controlled root access is a significant variable in the face of zero-days; LineageOS+Magisk is more likely to resist attack than vendor ROMs that are lagging security updates by months.
Users know about this problem and know how to mitigate it. Get out of my way, please.
Antivirus scanners are essentially useless on modern mobile OSes because they are limited to accessing the same things a malicious app or file would be.
Providing app-accessible root compromises the security of the OS even for people not using it since it provides root access to a substantial portion of the OS and provides a way to maintain persistent root access for an attacker. A quick tapjacking vulnerability exploit is all that's required to gain full control over the device with no way to detect or eliminate it. The attacker has root so they control all the user interfaces, etc. and can hide it. They can hide what happened and block an attempt at revoking it. The idea that it only impacts people negatively if they use it poorly is wrong. Using it at all is using it poorly anyway, since the right way to implement anything is not giving root access to an application. App-accessible root access is used as an insecure shortcut to implement features without proper security models where components are given the privileges they need to function and are split up to reduce attack surface.
For example, in Android, there's an isolated netd process with CAP_NET_ADMIN for configuring the network but it can't load eBPF programs itself, only bpfloader which it only does via predefined programs. This avoids a compromise of netd being able to compromise the kernel via eBPF. Similarly, a VPN service app providing features like local filtering and/or an actual VPN does not have CAP_NET_ADMIN or other highly privileged access. User interfaces in the OS configuring firewall functionality and other network configuration do it via netd. A common use of app-accessible root is giving root access to a GUI application to manage firewall rules directly rather than having a tiny privileged component doing it and then the GUI only being given the privilege of configuring rules through that in a structured way. Principle of least privilege, isolation, etc. are basic security concepts violated by this whole approach.
Giving the user root access is not the same as giving apps root access. The user having a root access shell is not nearly as harmful as having apps able to request it.
Apps can and will coerce users into doing things they shouldn't. Root access is inherently not required by someone like a firewall configuration GUI and not the right way for the implementation to be made. That's an example of an insecure implementation leading people to believe it requires giving broad root access to the OS and the app when it's not needed by a well written implementation. It's similar to apps demanding a permission like Contacts and refusing to work without it despite it not being required, which is why GrapheneOS provides Contact Scopes and similar features for overruling the demands from the apps. App accessible root access goes against the Android and GrapheneOS privacy and security approach to an extreme.
Nubia was hacked remotely. It received no updates for years, so it was an easy target. I unlocked Nubia and plan to install LineAge OS to it when my Pixel 5 will die.
Pixel 5 was hacked from close distance via WiFi or BT.
Pixel 6 with Graphene is not hacked yet.
Lack of root doesn't protect me.
However, I use SafeDot to monitor phone access to microphone, camera, GPS, so I'm alerted when it starts to beep, which creates problems for spies, so SafeDot is banned by Google at request of СІА. I cannot fix this, because Google controls my phone instead of me. SafeDot still works on Pixel6 GrapheneOS with warning notification about it «unsafety» though.
Yes, because the FSF endorsement matters, https://news.ycombinator.com/item?id=25504641. Why does this matter at all how the updates are implemented? The fact is, the updates are possible and being performed via other means.
> Crucially, there aren't cellular radio firmware updates.
This is false:
https://forums.puri.sm/t/librem-5-firmware-updates/20604
https://forums.puri.sm/t/updating-firmware-on-the-librem-5/2...
The goal of /e/OS is to provide a more-private degoogled OS that is usable out of the box by normal people: an app store, maps, etc.
This whole conversation reminds me of talking to Slackware users in the early 2000s: "I don't understand what you mean, it's compatible with everything you just have to recompile it. It's 100% secure, it comes with zero services running."
So if I don't use sudo then the problem with root is solved?
I very much don't want to have some external device to have root access to my computer.
If iOS type sandboxing where I can't access most of the data at all is ahead, I'm glad to be behind.
No, I cannot rely on the app sandbox. If someone else controls a device, then this device can be used against me.
Your antivirus, scanner or not, is useless on your device for you.
My antivirus on my device is useful for me. It works fine on GrapheneOS (Pixel 6), but banned by Google on Pixel 5, which is not supported by Google with security updates. WTF?
You're supporting someone who very openly engages in libel and bullying towards me while he was actively publicly using and catering to Kiwi Farms. The content is very clearly aimed at that kind of audience and to make the harassment much worse, which it did, and Rossmann continued to double down on that.
Myself I have not reverse engineered the Titan M2 security chip, but surely it uses eFuse or OTP memory for anti rollback protection mechanisms and such.
These are really basic hardware security primitives. I'm curious why you're under the impression Pixels wouldn't use eFuse.
The Pixel 6 is only mentioned in regards to anti-rollback protection. This has nothing to do with unlocking and later relocking the bootloader. Pixels have always supported relocking the bootloader with a custom root of trust, i.e. custom AVB signing keys used by a custom, user-installed operating system.
https://source.android.com/docs/security/features/verifiedbo...
> The Xbox 360, Nintendo Switch, Pixel 6 and Samsung Galaxy S22 are known for using eFuses this way.[8]
Anti-rollback protection is a security feature, eFuses are hardware primitives that can be used to implement it. Bootloader locking is another security feature that can be implemented with eFuses.
If you have any data denying the use of eFuses in the Pixel 6, please share it, that is what I was interested in this sub-thread. I really did not understand the relevance and the correctness of your comment.
On Samsung devices, blowing the Knox eFuse permanently disables features tied to Knox (e.g. Samsung Pay, Secure Folder). ("can never go back to a state where it passes all checks")
Pixels do not have an equivalent eFuse that permanently disables features (discounting the ability to flash previous versions of Android). Restoring stock firmware and relocking the bootloader will give you a normal Pixel.
Indeed it may be true today that "restoring stock firmware and relocking the bootloader will give you a normal Pixel", I completely understand what you mean.
But that is NOT the same thing as "Pixels do not have eFuses to flag devices that have been modified before". Please share data supporting this claim if you have it.
It is possible that existing Pixels have such eFuses that internally flag your device (perhaps bubbling up to the Google Play Integrity APIs) but they don't kill device features per Google's good will.
My question is 100% about the hardware inside the Titan M2 and how it is used by Google. I don't think the answer is public, and anyone who has reverse engineered it to such detail won't share the answer either.
I thought you claimed that Pixels also used eFuses to disable certain features after unlocking the bootloder once, like Samsung devices do. That's why I pointed out that Pixel devices have always had support for relocking the bootloader with a custom root of trust.
Your response to this comment https://news.ycombinator.com/item?id=45244933 made it seem that way, because you appeared to disagree that "Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader".
I guess that was a misunderstanding.