I just bought a pixel from best buy to install gos, which was an ordeal.
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.
Obviously avoiding surveillance can be a bigger red flag than being surveilled.
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.
I recently bought a Pixel from a Google store and wasn't asked any personal information. I installed Graphene right away and the phone just works. I use FOSS apps obtained on F-Droid and don't bother with sandboxed Google Play and all that. For me that kind of defeats the point of a FOSS OS.
Sandboxed Google Play doesn't really defeat the point of GrapheneOS. Not wanting to use Google Play or any proprietary Google services is perfectly valid, for all clarity. But, it's just important to note that for people that heavily use Google services, the advantage of using those on GrapheneOS instead of on a GMS-licensing OS is very high. The GMS-licensing OS will bundle the Google Mobile Services (Google suite off apps, Google Play, ...) in a privileged way. They won't be treated as regular apps, as is the case on GrapheneOS, but will have invasive access on your phone. In general, GrapheneOS' many hardening and privacy features allow you to have a better grasp on privacy-invasive apps.
The planned sideloading instructions only apply to certified OSes. GrapheneOS is not certified because it doesn't bundle privileged Google Mobile Services.
> Do you think Best Buy assigns cash serial numbers to individual products they sold, by default, always?
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!
I'd never thought of ATMs scanning the serial numbers of cash, but that makes sense. However, and maybe this isn't leading practice, but stores just seem to put cash in a collective cash drawer, so they can't exactly tell what cash was used for what (though cash purchase would be rare these days). Are there regulations around logging serial numbers now?
Commercial banks don't usually share consumer info with each other. Unless it's the same bank, they're probably safe. Plus, there's no way to obtain a network-connected SIM with cash, so all of this is moot.
You're over thinking it. You can determine this with much more available data, though you'd need to do this through aggregate. In one sense it is simpler, but in another sense it is more complex.
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.
On GrapheneOS they're profiles. Pretty much the same as with the stock aosp, but they add very extensive support - like notifications forwarding and a perfect balance between security and convenience, 2FA with shorter pin.
It's incredibly useful! I have one profile for the "social" apps I don't trust (TikTok, Reddit, etc.). They can commingle. And there's another profile that contains the apps that rely on Google Play Services (e.g. something relies on google maps). As far as I understand it, it's like a strong firewall between them such that they are pretty close to having multiple different phones.
It's not really like having multiple phones. User profiles are a useful features, also for privacy, but they are not a privacy or security silver bullet. Within any given user profile, apps are sandboxes. An app can't peak into the contents or internal data of another app and can't access things it isn't given access to per the permissions. Despite not being able to peek into other apps, apps can use IPC to communicate with other apps bases on MUTUAL consent.
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).
I understand that you have a concern, but may I ask what you mena specifically by "trust", and how would profiles help? Is it about accessing phone data or something else? As far as fingerprinting goes, I don't think profiles matter -- they already know who you are and can associate you with data from other sources.
I've successfully used Material Files [1] to set a nework shared folder (I think it was FTP) on one Android profile, and accessing it ("connecting" to it) from the other. So this might also work between GrapheneOS profiles.
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.
You can use Seedvault to make and restore a backup. Set up a secondary user profile with settings only (no apps yet), make a backup and use that in future for initializing other profiles.
There are apps like Inter Profile sharing (appID: digital.ventral.ips).
Yes, but a small subset of the GrapheneOS features are enhancements to user profiles and Private Space. We enable more of the standard user profile functionality that's usually not available (such as ending secondary user sessions or toggling them running the background) and add extra features such as notification forwarding. For Private Space, we enable making them in secondary users instead of only Owner and provide control over clipboard sharing instead of it always being shared with the parent profile (the user it's nested in).
Our more prominent 2-factor fingerprint authentication feature is also relevant when switching between users a lot.
The only thing I don't like from private space is that all notifications from apps inside private space are hidden. Wish that was configurable. I use private space for containerization, not to hide things.
True, although on GrapheneOS, apps on different profiles can remain active when you switch and notifications can be sent to the primary profile if you choose.
Secure folder is an older approach to what Android provides via the standard Private Space feature since Android 15. Private Space and work profiles are based on the same infrastructure as secondary users including per-profile encryption keys, although typically work profile management apps don't take advantage of it.
last time I tried, my samsung phone couldn't use multiple profiles. it is a setting that has been disabled in oneUI since a few years. Don't ask me why.
Well, nobody's forced it, but my company publishes content on TikTok that drives customers, and I want to be able to see it myself. You'd be surprised how many CISOs and security workers are on TikTok.
What kind of 2FA? I run OTP on my work laptop. Yes, it's maybe not really a 2nd factor if someone had access to my laptop with LUKS open. But at least I don't expect any automated attack because it's my own piece of code using an otp library.
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).
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.
Because obviously people want to enjoy technological usefulness (i.e. navigation, payments, communication) and automation while preserving dignity and not being spied like a bunch of ships.
I did try phoneless for a few years, except for a dumbphone that I kept at home for the rare call or SMS 2FA.
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.
If you are going to use a desktop instead, you are hurting your security significantly. Traditional desktop OSes like Window, MacOS and Linux desktop lack a sane security model with a mandatory app sandbox with fine-grained permissions. They also heavily use memory-unsafe code compared to modern OSes like Android OSes and iOS and lack modern exploit mitigations. Only daily drivable productions grade desktop OS with security in its foundations is ChromeOS.
I ran Graphene for several months and hated every minute of it. It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
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.
> Sure, but to get to them is just about as convenient as rebooting the phone from cold.
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:
It's important to note that user profiles are a standard Android feature, as are Private Space and work profiles nested within the Owner user. None of the core privacy and security features of GrapheneOS require using user profiles. We make certain enhancements to user profiles and Private Space. For user profiles, that's mainly allowing making more users, using more standard functionality (end session, more toggles to control access) and notification forwarding. For Private Space, we enable using them in secondary users and provide the important improvement of controlling clipboard sharing with the parent profile. Those profile improvements are a very tiny portion of what GrapheneOS provides. There's a common misconception that sandboxed Google Play requires profiles but that's not the case and they're regular sandboxed apps when installed in the Owner user too.
Huh? To me, Graphene just feels like unbloated Android with a few convenient ways of customizing google stuff and that's it. I like that it actually gets out of my way and I don't really understand how it "coddles" you.
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.
As an alternative to running something like GrapheneOS to limit intrusive proprietary apps you can disable such apps and only enable them when required for some reason, then disable them again. To do so you'll want a rooted device, Termux and Termux:Widget for easy access to the enabling/disabling scripts. Here's an example of such a script, this one can be used to enable or disable Google services:
#!/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
The script is stored in ~/.shortcuts/Name_of_package:enable and hardlinked to ~/.shortcuts/Name_of_package:disable. Its action depends on by which name it is called. The scripts can be started through a Termux widget from the launcher.
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.
They're describing a bad experience with heavily using Android's user profiles for compartmentalization, not GrapheneOS. An incredibly tiny portion of what GrapheneOS provides has to do with user profiles. GrapheneOS does not restrict/limit users in the way they're describing. They're attributing a very niche way they chose to set up and use the device to GrapheneOS when it's not tied to it. See https://news.ycombinator.com/item?id=45244497.
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.
An alternative (and possibly easier) way that doesn't require root is to use Hail + Shizuku.
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/
This all has little to do with the privacy and security features provided by GrapheneOS. See https://news.ycombinator.com/item?id=45244497 in response to the original post with complaints about Android user profiles, which are not a GrapheneOS feature. Nearly the entirety of the GrapheneOS added features can be used without ever making/using a secondary user. It's not required by sandboxed Google Play at all. Secondary users are useful but not a feature added by GrapheneOS.
You might prefer /e/OS: It's another de-googled Android variant but in contrast to Graphene the focus is on privacy and everyday usability. They aren't trying to produce an OS hardened against nation-state attackers, just one that doesn't routinely leak all your data to advertisers.
GrapheneOS provides much better privacy, stability and app compatibility than /e/ rather than only security. GrapheneOS entirely exists as a privacy project and focuses on security too in order to protect privacy. GrapheneOS is a privacy project aimed at being highly usability. There's a good third party comparison between them here:
/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:
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:
OP has found Graphene to be unusable and my experience has been similar. In contrast, I find /e/OS to be friendly and approachable as a daily driver. 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.
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.
This post ignored the vast majority of what was said and gave very inaccurate and misleading responses to the rest. There are even many responses in their own forum to that post and others debunking the claims. Beyond the privacy and security issues, it helps demonstrates that Murena and /e/ are not trustworthy due to covering up severe privacy and security vulnerabilities on a consistent basis.
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.
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 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:
perhaps its something you missed, but you can use a work profile. put all your google apps in there and its a tap of a button (quick setting pull down) to jump into. then another to turn it off. you get the benefits of sandboxing a bunch of apps, while using the same user profile. its very convenient.
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.
Private Space is from Android 15 so GrapheneOS has provided support for it since October 2024 when Android 15 was released. Profiles are a standard Android feature, not something added by GrapheneOS, and are not required to benefit from the privacy and security it provides. Sandboxed Google Play does not depend on putting it in a secondary profile.
> It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
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.
I use Graphene for years now and it's the most out of my way OS I have used on my phones so far. It Just Works™, no bundleware, all the freedom I need.
To be fair, "it just works" is a relatively recent feature of Graphene. It used to not be able to support things like Uber, Google Maps, etc.
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
The sandboxed Google Play compatibility layer was added in July 2021 and quickly advanced from there, being able to support nearly all Play Store apps depending on Play services by around the end of the year.
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.
That is something to do with Google Fi, not GrapheneOS. You can work around it by having the Google Fi app installed in the secondary profile and signed into the Google account associated with your service. Although I don't see much point in that. Anyway, it's not an issue caused by GrapheneOS, just Google Fi expecting to be present to grant service access.
Yeah, I suspect this really is a YMMV situation. I approach phones from my PC / Linux background, with a specific subset of software I wanna use, and it was a perfect match for that. If someone expects it to be "Android, but somehow better", then it likely won't deliver.
> GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
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:\
As described in the README, the combination of root access and locking the bootloader has the caveat that it's easy to brick your boot partition by accidentally making changes to it. That causes the signature check to fail, and then you have to unlock the bootloader and wipe all your data to re-flash it.
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?
It also has the caveat that protecting against privileged attacker persistence doesn't work by definition, so it only provides protection against physical attacks. The protection against physical attacks is also reduced through having the keys available on a lower security device as would typically be the case.
After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
You can use most banking apps on GrapheneOS but a subset block using any alternate OS. GrapheneOS supports hardware attestation and some banking apps explicitly permit GrapheneOS via hardware attestation such as Swissquote which recently added it. Banking app compatibility on GrapheneOS is better than any other alternate OS due to some apps choosing to special case allowing it.
Google will not using their service for tap-to-pay.
My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.
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.
> My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.
There's no such thing for Pixels, and it also doesn't void the manufacturer warranty.
Where are you getting this information? For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/EFuse
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.
The Pixel 6 is mentioned specifically about eFuses which is the technical detail that caught my attention in this thread.
> 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.
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".
You mentioned devices being irreversibly "tainted" after unlocking the bootloader.
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.
I was purely focusing on whether or not it uses eFuses, literally, which it 100% absolutely does. I was not making any other such claims.
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.
Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no.
(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.
Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-gu....
Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
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.
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
> 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.
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.
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.
> You either build a debug image, so you just have 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.
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.
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.
> Here is a recent report of widespread advanced malware looking to see if a device is rooted
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.
Root does not leave the Android permission model in a usable state at all, it completely undermines it.
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*.
From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.
And there's reason why normal windows / Linux laptops are less secure.
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 :)
> 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?
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.
Running GUI programs as root has been discouraged more or less always. Nowadays GUI programs that need root request it, via e.g. PolicyKit, for the specific operations it is needed.
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.
They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user?
By the way, personal attacks are against the HN Guidelines.
Ah yes thats a real good faith argument you got there.
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.
Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
> If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
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/
Giving the user control does not mean giving the user root. Giving root breaks Android security model. Whatever capability you want should be implemented as a proper feature to avoid breaking the security of the device.
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.
That would be nice, but trying to get those kinds of functionality upstreamed into GOS so they can be exposed tovapps in a structured way with the usual permissions model is a high effort.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
This just doesn't work the way you think, this mentality is not just outdated, but dangerous. People who think like that are more subject to "low IQ" attacks than people who accept the fact they are subject to the same "low IQ" attacks that work on everybody. You are overly confident. You can't be 100% alert and suspicious 24/7, around the clock. At some point you are tired, your attention is elsewhere or you are just not up-to-date on the latest techniques that attackers combine with some form of social engineering.
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.
> 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.
This kind of mentality is why malware became such a big issue on Windows. It turned out ignoring security and just relying on the user to not be stupid doesn't work. That mistake shouldn't be made again and there is no reason to artificially restrict the audience of an OS to people who don't have "low IQ."
No, the goal is to move to a system that doesn't rely on badness enumeration (antivirus) as a primary defense. You can rely on the app sandbox and the security model of the system to keep it in check.
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.
Yeah, I have few bricked devices which reached the your goal.
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?
GrapheneOS is very easy to install via https://grapheneos.org/install/web and many non-technical people do it. It's also sold preinstalled on devices. It's very easy to use and not much harder than using regular Android. People often find it to be easier than using a very complex Android UI such as what Samsung typically makes.
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.
I have Pixel 6 with Graphene and Pixel 5 with stock OS. Also, I have an old ZTE Nubia, which still works. None of them was rooted.
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.
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.
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.
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.
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.
Arguably Android has a capability-based security model, though it suffers from being ... well, it's not what you'd build if you were doing it from scratch today. Hindsight is 20/20. But I'd tentatively say not really, because the point of root is to get outside the existing capabilities. As an example: For a while, the most common root app I ran was one to limit charging to 80% or whatever to make the battery age more gracefully.[0] The whole reason that needed root is because there wasn't a capability/permission for that; the app couldn't ask the OS to let it control charging, because nobody even thought to expose that API surface.
[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.
>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.
Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.
Quoting inline since parent has been rewritten multiple times now...
> 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.
> Android has an established way to handle permission dialogs that require the user to confirm their approval
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.
> With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
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.
Possibly. Yes, hiding from auditing would be a possible advantage, but I think an app with accessibility permissions could already draw over the settings app to hide the real list of permissions from your view without root. Off the top of my head I think there's a whole mess of permissions needed to allow that, but we're discussing a threat model where permission dialogs can be effectively bypassed so that's no obstacle.
Sincere question: what is the point of using this OS for privacy and then using Google services? The intro runs though how it’s very easy to do this. Maybe I’m missing something.
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)
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!).
Why is this in any way superior to microg, apart from compatibility? Microg simply spoofs/shims the API while not actually contacting Google servers at all.
microG still uses Google services for accounts, push messaging and many other features.
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.
Just the fact that you have more control over the permissions you give to apps makes it worth it for me.
* 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.
GrapheneOS primarily exists to give you tools to exert more control over what apps have access to and to better protect your data. What you do with those tools is entirely your own concern. Where those apps come from is not GrapheneOS's concern.
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.
Security, including privacy, is about layers of hardening. In this case, minimization of leakage and other privacy concerns for some can still be worth the tradeoffs. For example, some apps literally refuse to work on a completely de-googled phone. (I ran one for many years with no google services). Also, the general control the user gets offers a lot more ability to harden than most android. I bricked my phone and am currently borrowing one and using stock android and there are things like facebook that are literally uninstallable... At least on lineage/graphene the user can actually control the system.
I have done less isolation with GrapheneOS than others. I have one profile and that profile has Google Play Services because I have friends on several chat apps, and Signal is the only one that reliably notified me when I got a new message.
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.
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.
as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.
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.
It's worth noting they're still regular sandboxed apps regardless of whether you use dedicated profiles for this. The main reason to use a separate profile for this is for fine-grained control over which apps can/will use Google Play. Apps in the same profile can see it's there and choose to use it.
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.
There did not seem to be an RCS story. Whether the device is RCS capable or not seems to be up to some unfathomable Google logic the tickling of which didn't work for me. Having old RCS chat histories and new RCS chats not work made me go back to stock quick.
Official support for Google Messages on GrapheneOS is being developed instead of needing to set it up in a very particular way where it can be fragile. In the long term, we plan to make our own RCS app.
Which itself is not guaranteed to work even on ”stock” Android, let alone GOS — which multiple people (myself included) have been experiencing firsthand.
GrapheneOS hasn't added official support for it yet, but we're working on it. People using it on GrapheneOS have been relying on it working for many people with various tweaks but not everyone. Official support will make it reliable.
I've seen several complaints here about how GOS does "user profiles", specifically complaining they make the UX too poor. There is a weaker form of user profiles called "work profiles" that one can use to have separation between apps but in a more user-friendly way.
Private Spaces are available since Android 15 and provides a similar nested profile without the need for a management app. They're better integrated into the OS user interface.
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.
This post would be better if it focused on the differences with android.
They can be found on GOS feature page, https://grapheneos.org/features , some security features are difficult to understand for non-developers, like ability to block Web JIT and native code debugging.
I like the idea of loading all apps from the "root" user profile, and pushing them to sub-user accounts, that seems natural as an administrative feature, but when you do it that way, any kind of privacy you'd have separating apps from seeing each other seems like it would be lost. I don't want apps to know what other apps on my phone, that would be part of the promise of user profiles in the first place... I'm not sure how to remedy that, but I've seen this advice in TFA and also on a youtube channel @sideofburritos, that covers GOS and security stuff, and it seems counter-productive in that sense.
Anyone have a sense for how battery life compares on grapheneOS vs stock Pixel?
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)
Out-of-the-box battery life is much better on GrapheneOS. With a similar setup with 1 profile with sandboxed Google Play and the same apps, it will be slightly better on GrapheneOS due to having fewer apps than the massive amount of stuff present in the stock OS.
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.
By default Play Store isn't installed. You can install it in order to set up the phone, but then remove it afterwards.
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.
I recently made the shift to graphene from iOS and am mostly enjoying it.
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.
> 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.
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.
PayPal's tap-to-pay availability is currently very limited and is likely still only in Europe. Curve Pay is in all of the UK and European Economic Region. I don't know how many countries have options for tap-to-pay via banking apps without Google Pay, but it's definitely available in most of Europe.
Installing it on a tablet is a good idea. I hesitate to install it on my phone because I'm concerned about a few things I rely on not working (RCS, tap to pay, nearby devices to unlock rental cars)
Contactless payments via phone would only be possible if you had a banking app that provided the feature independently. Google Wallet/Google Pay does not work on OSes not certified by Google.
Curve Pay also works, as do European banks using the standard approach not dependent on Google Play. Tap-to-pay is not an issue for GrapheneOS users in the UK and EU.
Apps that need SafetyNet to be in a particular state won't work. I never experienced the downside, even with my smaller bank's app, it works seamlessly.
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.
Software tamperproofing. Or, at least an attempt to it. Apps can request the info from Android: "hey, is this a legit Android system? Everything in factory condition?" and this mechanism would respond. Some apps request this in the name of security. In an attempt to ensure that the user and their data via the app are safe.
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:
It seems every single day there is a new article here favoring that distro.
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.
If you have evidence of a hardware backdoor, please provide it. Otherwise you are just speculating and that doesn't bring value to a HackerNews discussion. Burden of proof lays upon you.
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."
LineageOS is just fine if you have a well-supported device. If you need to run proprietary apps, you'll need MicroG (which runs just fine as a user application) and the Aurora store.
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.
LineageOS, iodé and /e/ are in a much different space than GrapheneOS. They greatly reduce the privacy and security of the Android Open Source Project rather than greatly improving it. They do not provide current privacy/security patches or keep all of the standard protections intact, let alone providing similar privacy and security enhancements to GrapheneOS.
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 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:
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:
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:
> 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.
If you are fine running an OS with horrible security and privacy, then LineageOS and it's forks are fine. If you want the best privacy and security, then GrapheneOS is the best option.
Is it just me or does it seems very odd that GrapheneOS only runs on a phone produced by the company that makes Android. Meaning that ironically, it isn't a Google alternative.
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.
For me the big blockers for GrapheneOS are still pretty much the same:
* 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.
> The community is unnecessarily toxic from what I've seen
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.
GrapheneOS developers keep insisting [0] that their security model is the only reasonably secure approach in the world, despite that Qubes OS proved that wrong.
>their security model is the only reasonably secure approach in the world
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.
> 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.
Librem 5 not only doesn't provide firmware updates for serious security vulnerabilities but goes out of the way to block the OS from doing it and block updating firmware in general. It uses a bunch of low security components. It's a closed source device with closed source firmware. Not updating the firmware from the OS has nothing to do with a threat model but rather a loophole in a definition of freedom where a device with a fully closed source OS would be considered free as long as it couldn't be updated by anyone...
> Librem 5 not only doesn't provide firmware updates for serious security vulnerabilities but goes out of the way to block the OS from doing it and block updating firmware in general
Sorry, but it is very difficult to understand what you mean and what you want from GrapheneOS. GrapheneOS is a FOSS project and they have committed to that being the case for the forseeable future.
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 just wanted to get a statement from them concerning what's a reasonable goal and what isn't
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.
QubesOS provides strong compartmentalization between virtual machines defined by the user, but it doesn't provide better protection against exploitation within those guests. Network drivers are a special case due to running in a dedicated VM. Applications and guest operating systems are just as vulnerable to exploitation. They're not hardened operating systems but rather traditional desktop OSes with a weak privacy and security model. QubesOS similarly doesn't provide any significant protection against data extraction in the After First Unlock state. It's nearly entirely focused on compartmentalization at the granularity of a whole OS.
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.
> but it doesn't provide better protection against exploitation within those guests
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
> 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.
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.
How did Qubes OS prove them wrong? You still have root on qubes, humans still make errors, IMO it's therefore technically still less secure. Of course this assumes your goal is to prevent bad things from happening in general, regardless of how it happens, and not just say "yea the OS is secure but humans can still mess things up by using it wrong".
I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
Even if that's true, it's not a knock against GrapheneOS itself. It's a subjective stance, not an objective one. This may be useful for some people to consider what projects they want to support, but it's not pertinent to discussions of function.
I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.
What utter nonesense. Just because the GrapheneOS Team doesn't do free work to support devices you like doesn't mean they prevent you from doing it. It's still 100% opensource and you are free to port it yourself to whatever device you please. The entitlement of people that want the grapheneos project to work for them for free is insane. Fucking hire a dev to work on this for a few month yourself if you don't like the device support.
The only reason I ditched GrapheneOS is because it doesn’t support automatic call recording. Sure, you can hit the record button every time you pick up, but who remembers to do that? Plenty of people have asked for this feature on GitHub [0], and the way the lead developer responds makes it look like there are some serious unresolved mental issues at play. Then I watched Louis Rossmann’s video [1] about him, and that sealed it. I refuse to touch Graphene OS with a 20 foot pole.
> Then I watched Louis Rossmann’s video [1] about him, and that sealed it.
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"?
> 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.
Why is it that whenever someone makes an accusation of bad behaviour from GrapeheneOS devs, they always end the posts with citations that lead to absolutely nowhere? Where, specifically in that first link as I don't consider a Louis Rossmann video a credible source, are these indications of "unresolved mental issues"?
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.
Strcat gets harassed based on frivolties, manufactured outrage. There have been repeated accusations of mental health issues without any substantive evidence, including from the person I was just replying to. The evidence they do give is usually of the developer expressing frustration at dealing with those accusations, which is ironic given that those accusations are self evidently true given that the people making those posts are usually accusing them!
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.
Idk anything about this drama, but "frustrated" is generous interpretation. Dude left an comment on a YouTube video and the guy freaked out on him. Seems like exactly the type of behavior he's claiming isn't real. I just want to know the OS I'm installing on my phone isn't at the whims of anyone who could pull a "colours/faker" stunt. But hopefully the project has governance and control that no single person could that that anyways (otherwise it'd be hard to calm it's a "secure" alternative)
I don’t think that you need to know anything about the drama to know that there is no context in which responses showed in the video are fine. Did strcat apologise for it?
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.
Rossman was complicit in harassment, harassment (particularly at this scale, driven by their significant viewer base) that would be harmful to literally anyone who would be the target of it. strcat was upset, understandably, and privately communicated that to Rossman who then proceeds to cynically turn it into something to generate more views for his channel.
Once again, there is no context in which strcat’s comments to Rossman would be fine which are in the video in full. Repeating a context won’t change this. Even if the main points of strcat is fine, their style was really, really bad, without the possibility of excuse. They got plenty of options for excuse during the conversation, they clearly didn’t use them. The whole conversation just seemingly proved the point of “harassments”.
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.
The video you're referencing very clearly exists for the purpose of directing harassment towards me based on fabrications and spin as part of Rossmann's bullying towards me. Nearly all of the claims he makes in the video are lies of misrepresentations, including even the title.
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.
I reflected only on the comments which you sent to Rossmann; you don’t deny that you sent those AFAIK. I purposefully ignored everything what Rossmann said. As I said, even if you’re right, those comments were mistakes.
It's a fabricated story which you're taking at face value. What Rossmann claims to have been said to him was not said to him. He deliberately misrepresents what was said and the context of him engaging in many months of public and private bullying leading up to it. See https://news.ycombinator.com/item?id=45255341.
The basic thing is that the developer had been swatted multiple times right before that video. Swatted by a fan of the YouTubers who made the video that Louis commented on.
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.
> Dude left an comment on a YouTube video and the guy freaked out on him.
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.
It's kind of funny that you're doing the exact same thing the person I initially responded to was doing, making a broad accusation and posting a link as evidence without specifying what it is within that link that you have a problem with. Grow a backbone and actually pull a quote that you feel is relevant.
joemazerino very frequently makes inaccurate claims about GrapheneOS and has been participating in bullying towards me for years. He has repeatedly lied about me and pushed fabricated stories. You're not going to find anything in my post history to back up his claims that I'm insane or delusional. If you look through his comment history, you'll find a lot of evidence that he has an unhealthy obsession with me and is blatantly engaging in bullying. It's something Hacker News should be addressing as a moderation issue. It should not be permitted to engage in blatant bullying and harassment on this platform including repeatedly claiming an open source developer is insane.
Convincing or not, given strcat (Daniel) is very vocal that you stop (what they sincerely feels is) harrasment, should be an indication enough that you do.
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).
I am sick of people raising this developer's mental issues. This is 2025, we should be sympathetic and encouranging to any human being struggling with mental issues, helping them get through or at least not trip them or sideline them. GrapheneOS is undeniably a project of great value, if you don't like something about it's development raise it and stop there as you would do with any project. Stop the "Graphene doesn't have X feature but the lead dev is nuts so I don't touch it" meme.
Completely agree. Writing off the project's numerous benefits on the basis of one missing feature is irrational. Immediately moving on to attack him personally by claiming he's mentally ill makes it impossible to assume good faith.
This is besides the point. The lead dev started going on a rant when facing a comment as simple as "this is informative, and unfortunate" on a video that he didn't like, and is unable to parse that statement as anything else but a personal attack at him. He threatened banning Louis over that unless he completely gave in. You can see the whole discussion in the video linked in the post above.
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.
I know the whole story in depth and you keep iterating over the same thing.
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?
Posting "this is informative, and unfortunate" as a comment to a video with a bunch of inflammatory accusations is giving credence to and expressing approval at the substance of it's content.
So no, it isn't as "simple" as the issue being only the literal content of that comment. The context matters.
As someone else pointed out, it's not just the comment. There's context you're either ignoring because it's inconvenient for you, or you don't know because you couldn't be bothered to learn more about it.
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.
GrapheneOS being in use by people and orgs with a high security requirement dictates an organizational review. OPSEC extends beyond just cyber capabilities.
The people calling me insane, delusional, schizophrenic, etc. almost entirely don't believe what they're saying as there's no actual basis for it. All they can do is link to incredibly dishonest harassment content from Louis Rossmann and Henry Fisher where they engage in a monologue pushing fabricated stories. What they show as supposed evidence doesn't at all match their claims and instead they heavily misrepresent it.
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.
Automatic recording may be illegal in jurisdictions that mandate permission from both parties. I can see why gos might not want to include it in a base operating system.
Samsung phones have it. I have verified from at least one source who lives in one of such jurisdictions (India), a Samsung phone they bought has this feature. So, it doesn't have anything to do with the law.
We never said we wouldn't implement it. We said the current pull request is inadequate because it doesn't show users that it's enabled so people can end up accidentally recording a bunch of calls if they toggle it on and forget about it or toggle it by accident.
I'm one of GrapheneOS's moderators and just saw this.
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.
He didn't step away. He made a post where he "stepped down" as the project lead and instead got replaced by a "GrapheneOS Foundation director", of which there are 3 including him.
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.
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:
> Is strcat the person who supposedly stepped down?
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.
Getting to the meat of why they didn't implement automatic call recording is that storage could fill up and they didn't want to implement managing user storage? I mean sounds like a fair call.
We never said we wouldn't implement it. We said the current pull request is inadequate because it doesn't show users that it's enabled so people can end up accidentally recording a bunch of calls if they toggle it on and forget about it or toggle it by accident.
I just bought a pixel from best buy to install gos, which was an ordeal.
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.
Obviously avoiding surveillance can be a bigger red flag than being surveilled.
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.
I recently bought a Pixel from a Google store and wasn't asked any personal information. I installed Graphene right away and the phone just works. I use FOSS apps obtained on F-Droid and don't bother with sandboxed Google Play and all that. For me that kind of defeats the point of a FOSS OS.
Sandboxed Google Play doesn't really defeat the point of GrapheneOS. Not wanting to use Google Play or any proprietary Google services is perfectly valid, for all clarity. But, it's just important to note that for people that heavily use Google services, the advantage of using those on GrapheneOS instead of on a GMS-licensing OS is very high. The GMS-licensing OS will bundle the Google Mobile Services (Google suite off apps, Google Play, ...) in a privileged way. They won't be treated as regular apps, as is the case on GrapheneOS, but will have invasive access on your phone. In general, GrapheneOS' many hardening and privacy features allow you to have a better grasp on privacy-invasive apps.
> I recently bought a Pixel from a Google store and wasn't asked any personal information.
A physical pop-up? The online google store requires a google account that has your personal info already..
Yeah, I'm just worried about the future of this with the AOSP and "sideloading" changes that Google is making to Android.
The planned sideloading instructions only apply to certified OSes. GrapheneOS is not certified because it doesn't bundle privileged Google Mobile Services.
That was my experience too. Up and running in 30 minutes, I was quite surprised
> (...) my name, address, and phone number just to purchase the device
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.
Did you pay cash? If not, you already gave them your real name and info.
... and did you get the cash from an ATM? or other source that tracks serial numbers?
Do you think Best Buy assigns cash serial numbers to individual products they sold, by default, always?
How would they even do that? As part of the machine that checks for counterfeit notes? They don't always use that, right?
> Do you think Best Buy assigns cash serial numbers to individual products they sold, by default, always?
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!
I'd never thought of ATMs scanning the serial numbers of cash, but that makes sense. However, and maybe this isn't leading practice, but stores just seem to put cash in a collective cash drawer, so they can't exactly tell what cash was used for what (though cash purchase would be rare these days). Are there regulations around logging serial numbers now?
Commercial banks don't usually share consumer info with each other. Unless it's the same bank, they're probably safe. Plus, there's no way to obtain a network-connected SIM with cash, so all of this is moot.
Ah, but that is far less critical than having your name and device IMEI show up in some database by default!
But yes, your bank could know you were at Best Buy, maybe.
The NSA's IMEI location logs will show you were at Best Buy at the time too.
You're over thinking it. You can determine this with much more available data, though you'd need to do this through aggregate. In one sense it is simpler, but in another sense it is more complex.
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.
[0] https://sa.my/androidmap/
[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...
> The user containers are very helpful
You mean different user accounts? Those are available on stock Android, too.
On GrapheneOS they're profiles. Pretty much the same as with the stock aosp, but they add very extensive support - like notifications forwarding and a perfect balance between security and convenience, 2FA with shorter pin.
> but they add very extensive support
Huh, I didn't realize they had added additional functionality not present on stock Android. Thanks!
It's incredibly useful! I have one profile for the "social" apps I don't trust (TikTok, Reddit, etc.). They can commingle. And there's another profile that contains the apps that rely on Google Play Services (e.g. something relies on google maps). As far as I understand it, it's like a strong firewall between them such that they are pretty close to having multiple different phones.
It's not really like having multiple phones. User profiles are a useful features, also for privacy, but they are not a privacy or security silver bullet. Within any given user profile, apps are sandboxes. An app can't peak into the contents or internal data of another app and can't access things it isn't given access to per the permissions. Despite not being able to peek into other apps, apps can use IPC to communicate with other apps bases on MUTUAL consent.
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).
I understand that you have a concern, but may I ask what you mena specifically by "trust", and how would profiles help? Is it about accessing phone data or something else? As far as fingerprinting goes, I don't think profiles matter -- they already know who you are and can associate you with data from other sources.
What about settings, though? Don't you have to set up each user profile separately?
Also, what if you ever want to share a file across user profiles?
I've successfully used Material Files [1] to set a nework shared folder (I think it was FTP) on one Android profile, and accessing it ("connecting" to it) from the other. So this might also work between GrapheneOS profiles.
[1]: https://f-droid.org/packages/me.zhanghai.android.files/
Sharing files requires a bit of creativity.
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
[0]https://github.com/equalitie/ouisync
[1]https://github.com/VentralDigital/InterProfileSharing
You can use Seedvault to make and restore a backup. Set up a secondary user profile with settings only (no apps yet), make a backup and use that in future for initializing other profiles.
There are apps like Inter Profile sharing (appID: digital.ventral.ips).
See: https://github.com/VentralDigital/InterProfileSharing
It also shows that profiles can't really prevent an app from correlating profiles on the same device, by listening on a local socket.
If you disallow Network permission to an app (a GrapheneOS feature), local network access is also disabled.
Yes, but a small subset of the GrapheneOS features are enhancements to user profiles and Private Space. We enable more of the standard user profile functionality that's usually not available (such as ending secondary user sessions or toggling them running the background) and add extra features such as notification forwarding. For Private Space, we enable making them in secondary users instead of only Owner and provide control over clipboard sharing instead of it always being shared with the parent profile (the user it's nested in).
Our more prominent 2-factor fingerprint authentication feature is also relevant when switching between users a lot.
The only thing I don't like from private space is that all notifications from apps inside private space are hidden. Wish that was configurable. I use private space for containerization, not to hide things.
True, although on GrapheneOS, apps on different profiles can remain active when you switch and notifications can be sent to the primary profile if you choose.
I think it depends on the Android distribution. I am not sure it is available on Samsung's One UI.
Multiple user is available on Samsung. Both multiple profiles as well as work profile.
Samsung also has "secure folder" which isolates apps and files and presumably uses multiple users to do the isolation.
Secure folder is an older approach to what Android provides via the standard Private Space feature since Android 15. Private Space and work profiles are based on the same infrastructure as secondary users including per-profile encryption keys, although typically work profile management apps don't take advantage of it.
Apparently multiple user profiles is available on their tablets but not on their smartphones.
last time I tried, my samsung phone couldn't use multiple profiles. it is a setting that has been disabled in oneUI since a few years. Don't ask me why.
> I have to have TikTok for work
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
Well, nobody's forced it, but my company publishes content on TikTok that drives customers, and I want to be able to see it myself. You'd be surprised how many CISOs and security workers are on TikTok.
Edit: "experts" > "workers"
Tiktok.com
?
I would assume for advertising/business account. There are things you can only do on the TikTok app that you can't do on the web.
All jobs I've had since the mid 2010s essentially did the same for me by requiring 2fa in certain contexts
What kind of 2FA? I run OTP on my work laptop. Yes, it's maybe not really a 2nd factor if someone had access to my laptop with LUKS open. But at least I don't expect any automated attack because it's my own piece of code using an otp library.
One of the contexts is login to the laptop , would be pretty challenging to facilitate on device ;)
Sadly, biometric authentication as 2fa is not sufficient for that.
Same here. If someone is accessing my OTP codes from my laptop, I've got bigger problems to worry about.
Only my most recent job is doing this. Before the job provided a phone for 2FA that I didn't use much outside of that.
Suggestion for people trying GrapheneOS...
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).
Re: not using Google Play
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.
[0] https://github.com/tmo1/sms-ie
Why stop there when you can just not have a phone at all?
Because obviously people want to enjoy technological usefulness (i.e. navigation, payments, communication) and automation while preserving dignity and not being spied like a bunch of ships.
I did try phoneless for a few years, except for a dumbphone that I kept at home for the rare call or SMS 2FA.
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.
If you are going to use a desktop instead, you are hurting your security significantly. Traditional desktop OSes like Window, MacOS and Linux desktop lack a sane security model with a mandatory app sandbox with fine-grained permissions. They also heavily use memory-unsafe code compared to modern OSes like Android OSes and iOS and lack modern exploit mitigations. Only daily drivable productions grade desktop OS with security in its foundations is ChromeOS.
I never said anything about desktops? You don’t have to use those either, though.
I ran Graphene for several months and hated every minute of it. It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
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.
> Sure, but to get to them is just about as convenient as rebooting the phone from cold.
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.
It's important to note that user profiles are a standard Android feature, as are Private Space and work profiles nested within the Owner user. None of the core privacy and security features of GrapheneOS require using user profiles. We make certain enhancements to user profiles and Private Space. For user profiles, that's mainly allowing making more users, using more standard functionality (end session, more toggles to control access) and notification forwarding. For Private Space, we enable using them in secondary users and provide the important improvement of controlling clipboard sharing with the parent profile. Those profile improvements are a very tiny portion of what GrapheneOS provides. There's a common misconception that sandboxed Google Play requires profiles but that's not the case and they're regular sandboxed apps when installed in the Owner user too.
Huh? To me, Graphene just feels like unbloated Android with a few convenient ways of customizing google stuff and that's it. I like that it actually gets out of my way and I don't really understand how it "coddles" you.
I have the exact opposite experience.
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.
> Sure it's cool you can turn off google play
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.
As an alternative to running something like GrapheneOS to limit intrusive proprietary apps you can disable such apps and only enable them when required for some reason, then disable them again. To do so you'll want a rooted device, Termux and Termux:Widget for easy access to the enabling/disabling scripts. Here's an example of such a script, this one can be used to enable or disable Google services:
The script is stored in ~/.shortcuts/Name_of_package:enable and hardlinked to ~/.shortcuts/Name_of_package:disable. Its action depends on by which name it is called. The scripts can be started through a Termux widget from the launcher.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.
They're describing a bad experience with heavily using Android's user profiles for compartmentalization, not GrapheneOS. An incredibly tiny portion of what GrapheneOS provides has to do with user profiles. GrapheneOS does not restrict/limit users in the way they're describing. They're attributing a very niche way they chose to set up and use the device to GrapheneOS when it's not tied to it. See https://news.ycombinator.com/item?id=45244497.
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.
An alternative (and possibly easier) way that doesn't require root is to use Hail + Shizuku.
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/
This all has little to do with the privacy and security features provided by GrapheneOS. See https://news.ycombinator.com/item?id=45244497 in response to the original post with complaints about Android user profiles, which are not a GrapheneOS feature. Nearly the entirety of the GrapheneOS added features can be used without ever making/using a secondary user. It's not required by sandboxed Google Play at all. Secondary users are useful but not a feature added by GrapheneOS.
That's true and I agree. I was responding to the comment about using termux to disable apps.
You might prefer /e/OS: It's another de-googled Android variant but in contrast to Graphene the focus is on privacy and everyday usability. They aren't trying to produce an OS hardened against nation-state attackers, just one that doesn't routinely leak all your data to advertisers.
GrapheneOS provides much better privacy, stability and app compatibility than /e/ rather than only security. GrapheneOS entirely exists as a privacy project and focuses on security too in order to protect privacy. GrapheneOS is a privacy project aimed at being highly usability. There's a good third party comparison between them here:
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
OP has found Graphene to be unusable and my experience has been similar. In contrast, I find /e/OS to be friendly and approachable as a daily driver. 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.
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.
> OP has found Graphene to be unusable
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.
FYI https://community.e.foundation/t/e-os-and-security-updates/7...
(I googled this, cannot attest to the accuracy of these rebuttals)
This post ignored the vast majority of what was said and gave very inaccurate and misleading responses to the rest. There are even many responses in their own forum to that post and others debunking the claims. Beyond the privacy and security issues, it helps demonstrates that Murena and /e/ are not trustworthy due to covering up severe privacy and security vulnerabilities on a consistent basis.
> Our
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.
> You are a partisan.
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...
perhaps its something you missed, but you can use a work profile. put all your google apps in there and its a tap of a button (quick setting pull down) to jump into. then another to turn it off. you get the benefits of sandboxing a bunch of apps, while using the same user profile. its very convenient.
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.
Private Space is from Android 15 so GrapheneOS has provided support for it since October 2024 when Android 15 was released. Profiles are a standard Android feature, not something added by GrapheneOS, and are not required to benefit from the privacy and security it provides. Sandboxed Google Play does not depend on putting it in a secondary profile.
> It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
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.
[dead]
I use Graphene for years now and it's the most out of my way OS I have used on my phones so far. It Just Works™, no bundleware, all the freedom I need.
To be fair, "it just works" is a relatively recent feature of Graphene. It used to not be able to support things like Uber, Google Maps, etc.
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
The sandboxed Google Play compatibility layer was added in July 2021 and quickly advanced from there, being able to support nearly all Play Store apps depending on Play services by around the end of the year.
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.
That is something to do with Google Fi, not GrapheneOS. You can work around it by having the Google Fi app installed in the secondary profile and signed into the Google account associated with your service. Although I don't see much point in that. Anyway, it's not an issue caused by GrapheneOS, just Google Fi expecting to be present to grant service access.
Yeah, I suspect this really is a YMMV situation. I approach phones from my PC / Linux background, with a specific subset of software I wanna use, and it was a perfect match for that. If someone expects it to be "Android, but somehow better", then it likely won't deliver.
> GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
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:\
You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting.
See: github.com/chenxiaolong/avbroot
As described in the README, the combination of root access and locking the bootloader has the caveat that it's easy to brick your boot partition by accidentally making changes to it. That causes the signature check to fail, and then you have to unlock the bootloader and wipe all your data to re-flash it.
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?
It also has the caveat that protecting against privileged attacker persistence doesn't work by definition, so it only provides protection against physical attacks. The protection against physical attacks is also reduced through having the keys available on a lower security device as would typically be the case.
After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
You can use most banking apps on GrapheneOS but a subset block using any alternate OS. GrapheneOS supports hardware attestation and some banking apps explicitly permit GrapheneOS via hardware attestation such as Swissquote which recently added it. Banking app compatibility on GrapheneOS is better than any other alternate OS due to some apps choosing to special case allowing it.
Google will not using their service for tap-to-pay.
My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.
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.
> My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.
There's no such thing for Pixels, and it also doesn't void the manufacturer warranty.
Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader.
Where are you getting this information? For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/EFuse
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.
> For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/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 Pixel 6 is mentioned specifically about eFuses which is the technical detail that caught my attention in this thread.
> 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.
I had the same misunderstanding of your comment, as this other commenter https://news.ycombinator.com/item?id=45256978
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.
You mentioned devices being irreversibly "tainted" after unlocking the bootloader.
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.
I was purely focusing on whether or not it uses eFuses, literally, which it 100% absolutely does. I was not making any other such claims.
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.
Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no.
(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.
it'd be really nice to exert pressure on GPay or at least banking apps to add GOS's keys. accepting only Google's keys is anticompetitive.
Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-gu....
Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
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.
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
> 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.
No, it is very easy.
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.
> You either build a debug image, so you just have 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.
Theres been a consistent pattern of both low quality and advanced malware looking for and targeting the weakness introduced by rooting a device.
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.
> Here is a recent report of widespread advanced malware looking to see if a device is rooted
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.
Root does not leave the Android permission model in a usable state at all, it completely undermines it.
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*.
If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
Pssst, quiet, don't give them any ideas... :-/
From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
Android of course requires root for installing and configuring applications. It just grants the root automatically.
No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
Developers cannot trust a random phone «owner».
Have a look at https://qubes-os.org to understand why you're mistaken.
I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.
> so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root
So if I don't use sudo then the problem with root is solved?
And there's reason why normal windows / Linux laptops are less secure.
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 :)
> 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?
The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
Someone can correct me if I'm wrong.
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.
Running GUI programs as root has been discouraged more or less always. Nowadays GUI programs that need root request it, via e.g. PolicyKit, for the specific operations it is needed.
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.
I'm willing to take the very slight chance of getting compromised in exchange for getting things done.
That's a Chromebook, no?
Chromebooks have Developer Mode that gives full root.
https://www.chromium.org/chromium-os/developer-library/guide...
[dead]
They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.
> That will give you adb root access.
I don't want adb root access? I want to be able to run apps with root access.
> massive risk
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user?
By the way, personal attacks are against the HN Guidelines.
Ah yes thats a real good faith argument you got there.
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.
Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
> Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on
This sounds like a great news to me, thank you.
Non sequitur?
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.
Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
> If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
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/
Giving the user control does not mean giving the user root. Giving root breaks Android security model. Whatever capability you want should be implemented as a proper feature to avoid breaking the security of the device.
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.
That would be nice, but trying to get those kinds of functionality upstreamed into GOS so they can be exposed tovapps in a structured way with the usual permissions model is a high effort.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
There doesn't need to be an easy escape hatch. The escape hatch is to wipe and flash a fork.
Then you lose all your data. You could also install a more traditional Linux phone OS too.
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.
> Giving root breaks Android security model.
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.
This just doesn't work the way you think, this mentality is not just outdated, but dangerous. People who think like that are more subject to "low IQ" attacks than people who accept the fact they are subject to the same "low IQ" attacks that work on everybody. You are overly confident. You can't be 100% alert and suspicious 24/7, around the clock. At some point you are tired, your attention is elsewhere or you are just not up-to-date on the latest techniques that attackers combine with some form of social engineering.
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.
> 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.
There are technical solutions for this problem, which are banned or delayed by GooGle.
This kind of mentality is why malware became such a big issue on Windows. It turned out ignoring security and just relying on the user to not be stupid doesn't work. That mistake shouldn't be made again and there is no reason to artificially restrict the audience of an OS to people who don't have "low IQ."
So, your proposition is to remove their ability to install antivirus software, like Google does in Android?
Users know about this problem and know how to mitigate it. Get out of my way, please.
No, the goal is to move to a system that doesn't rely on badness enumeration (antivirus) as a primary defense. You can rely on the app sandbox and the security model of the system to keep it in check.
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.
Yeah, I have few bricked devices which reached the your goal.
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?
GrapheneOS is very easy to install via https://grapheneos.org/install/web and many non-technical people do it. It's also sold preinstalled on devices. It's very easy to use and not much harder than using regular Android. People often find it to be easier than using a very complex Android UI such as what Samsung typically makes.
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.
I have Pixel 6 with Graphene and Pixel 5 with stock OS. Also, I have an old ZTE Nubia, which still works. None of them was rooted.
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.
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.
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.
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.
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.
It's useful for general use just fine.
But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.
EDIT: This is a reply to the 2nd(?) version of your comment before it was silently changed into something different.
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.
>This is not what people are referring to when they talk about rooting on Android
Would this have been easier or more possible if Android had a full capability-based security model?
Arguably Android has a capability-based security model, though it suffers from being ... well, it's not what you'd build if you were doing it from scratch today. Hindsight is 20/20. But I'd tentatively say not really, because the point of root is to get outside the existing capabilities. As an example: For a while, the most common root app I ran was one to limit charging to 80% or whatever to make the battery age more gracefully.[0] The whole reason that needed root is because there wasn't a capability/permission for that; the app couldn't ask the OS to let it control charging, because nobody even thought to expose that API surface.
[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.
>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.
Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.
Quoting inline since parent has been rewritten multiple times now...
> 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.
> Android has an established way to handle permission dialogs that require the user to confirm their approval
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.
> With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
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.
> Frankly, I'm not sure what they'd get out of root at this point.
A permission that allows them to hide that they have access to everything, including other apps' data?
Possibly. Yes, hiding from auditing would be a possible advantage, but I think an app with accessibility permissions could already draw over the settings app to hide the real list of permissions from your view without root. Off the top of my head I think there's a whole mess of permissions needed to allow that, but we're discussing a threat model where permission dialogs can be effectively bypassed so that's no obstacle.
Sincere question: what is the point of using this OS for privacy and then using Google services? The intro runs though how it’s very easy to do this. Maybe I’m missing something.
It's actually really great!
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.
https://grapheneos.org/donate
Why is this in any way superior to microg, apart from compatibility? Microg simply spoofs/shims the API while not actually contacting Google servers at all.
microG still uses Google services for accounts, push messaging and many other features.
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.
> Microg simply spoofs/shims the API while not actually contacting Google servers at all.
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.
Just the fact that you have more control over the permissions you give to apps makes it worth it for me.
* 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.
GrapheneOS primarily exists to give you tools to exert more control over what apps have access to and to better protect your data. What you do with those tools is entirely your own concern. Where those apps come from is not GrapheneOS's concern.
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.
Security, including privacy, is about layers of hardening. In this case, minimization of leakage and other privacy concerns for some can still be worth the tradeoffs. For example, some apps literally refuse to work on a completely de-googled phone. (I ran one for many years with no google services). Also, the general control the user gets offers a lot more ability to harden than most android. I bricked my phone and am currently borrowing one and using stock android and there are things like facebook that are literally uninstallable... At least on lineage/graphene the user can actually control the system.
I have done less isolation with GrapheneOS than others. I have one profile and that profile has Google Play Services because I have friends on several chat apps, and Signal is the only one that reliably notified me when I got a new message.
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.
Afaik, Google services are run in a sandbox on Graphene OS.
Hm ok but location data etc still goes to them? What about the device fingerprint?
I’m just wondering what the selling point for using Graphene with Google is. Very Graphene curious.
> but location data etc still goes to them
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.
as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.
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.
It's worth noting they're still regular sandboxed apps regardless of whether you use dedicated profiles for this. The main reason to use a separate profile for this is for fine-grained control over which apps can/will use Google Play. Apps in the same profile can see it's there and choose to use it.
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.
There did not seem to be an RCS story. Whether the device is RCS capable or not seems to be up to some unfathomable Google logic the tickling of which didn't work for me. Having old RCS chat histories and new RCS chats not work made me go back to stock quick.
Official support for Google Messages on GrapheneOS is being developed instead of needing to set it up in a very particular way where it can be fragile. In the long term, we plan to make our own RCS app.
you need the google messaging app for RCS
Is it because no one else has tried implementing the RCS standard or because Google has some proprietary hold over it?
No one else has tried implementing the RCS standard.
There just aren't any open-source Android libraries for RCS out there, much less anything in AOSP.
https://github.com/search?q=rcs+android&type=repositories
Apple has RCS, compatible with Android, at least in the EU. You don't get the blue bubble though.
I think they’re asking about on Android. The point is whether there’s an alternative RCS client to run on GOS.
Which itself is not guaranteed to work even on ”stock” Android, let alone GOS — which multiple people (myself included) have been experiencing firsthand.
GrapheneOS hasn't added official support for it yet, but we're working on it. People using it on GrapheneOS have been relying on it working for many people with various tweaks but not everyone. Official support will make it reliable.
RCS is an abomination.
I've seen several complaints here about how GOS does "user profiles", specifically complaining they make the UX too poor. There is a weaker form of user profiles called "work profiles" that one can use to have separation between apps but in a more user-friendly way.
The recommended app is "Shelter". https://f-droid.org/en/packages/net.typeblog.shelter/
Private Spaces are available since Android 15 and provides a similar nested profile without the need for a management app. They're better integrated into the OS user interface.
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.
This post would be better if it focused on the differences with android. They can be found on GOS feature page, https://grapheneos.org/features , some security features are difficult to understand for non-developers, like ability to block Web JIT and native code debugging.
I like the idea of loading all apps from the "root" user profile, and pushing them to sub-user accounts, that seems natural as an administrative feature, but when you do it that way, any kind of privacy you'd have separating apps from seeing each other seems like it would be lost. I don't want apps to know what other apps on my phone, that would be part of the promise of user profiles in the first place... I'm not sure how to remedy that, but I've seen this advice in TFA and also on a youtube channel @sideofburritos, that covers GOS and security stuff, and it seems counter-productive in that sense.
Anyone have a sense for how battery life compares on grapheneOS vs stock Pixel?
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)
Out-of-the-box battery life is much better on GrapheneOS. With a similar setup with 1 profile with sandboxed Google Play and the same apps, it will be slightly better on GrapheneOS due to having fewer apps than the massive amount of stuff present in the stock OS.
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.
By default Play Store isn't installed. You can install it in order to set up the phone, but then remove it afterwards.
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.
I recently made the shift to graphene from iOS and am mostly enjoying it.
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.
> 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.
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.
Interesting... Maybe I need to investigate PayPal as an option here. Best case would be my bank eventually adds tap to pay natively
PayPal's tap-to-pay availability is currently very limited and is likely still only in Europe. Curve Pay is in all of the UK and European Economic Region. I don't know how many countries have options for tap-to-pay via banking apps without Google Pay, but it's definitely available in most of Europe.
Bought an Google Pixel Tablet only for GOS. Installation worked like a charm and all my applications are still working without problems.
Loving it.
Installing it on a tablet is a good idea. I hesitate to install it on my phone because I'm concerned about a few things I rely on not working (RCS, tap to pay, nearby devices to unlock rental cars)
Contactless payments via phone would only be possible if you had a banking app that provided the feature independently. Google Wallet/Google Pay does not work on OSes not certified by Google.
Paypal tap-to-pay works according to reports.
Curve Pay also works, as do European banks using the standard approach not dependent on Google Play. Tap-to-pay is not an issue for GrapheneOS users in the UK and EU.
Great idea! I have wanted to experiment with GrapheneOS but didn’t want it to use it for banking or calls.
Do bank apps work with GrapheneOS?
In my country most of them do. It depends on the bank and their application. https://privsec.dev/posts/android/banking-applications-compa... offers a possibility to check which apps may work fine.
All my Swedish bank related apps work without issue.
But there are some exceptions out there so you need to be more specific.
Apps that need SafetyNet to be in a particular state won't work. I never experienced the downside, even with my smaller bank's app, it works seamlessly.
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.
What is SafetyNet?
Software tamperproofing. Or, at least an attempt to it. Apps can request the info from Android: "hey, is this a legit Android system? Everything in factory condition?" and this mechanism would respond. Some apps request this in the name of security. In an attempt to ensure that the user and their data via the app are safe.
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.
It seems every single day there is a new article here favoring that distro.
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.
If you have evidence of a hardware backdoor, please provide it. Otherwise you are just speculating and that doesn't bring value to a HackerNews discussion. Burden of proof lays upon you.
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."
Then list the other options, please.
LineageOS is just fine if you have a well-supported device. If you need to run proprietary apps, you'll need MicroG (which runs just fine as a user application) and the Aurora store.
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.
LineageOS, iodé and /e/ are in a much different space than GrapheneOS. They greatly reduce the privacy and security of the Android Open Source Project rather than greatly improving it. They do not provide current privacy/security patches or keep all of the standard protections intact, let alone providing similar privacy and security enhancements to GrapheneOS.
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.
> LineageOS, iodé and /e/ are in a much different space than GrapheneOS.
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 have different priorities, granted.
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.
[dead]
If you are fine running an OS with horrible security and privacy, then LineageOS and it's forks are fine. If you want the best privacy and security, then GrapheneOS is the best option.
stop spreading misinformation
There has to be a better open source mobile OS out there.
Better in terms of what? Do PureOS, Mobian, postmarketOS work for you?
Thanks I'll check them out. Which one do you recommend?
Is it just me or does it seems very odd that GrapheneOS only runs on a phone produced by the company that makes Android. Meaning that ironically, it isn't a Google alternative.
I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.
The reasoning is explained here: https://grapheneos.org/faq#device-support
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.
For me the big blockers for GrapheneOS are still pretty much the same:
* 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.
What safetyNet does GrapheneOS implements of its own?
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.
> The community is unnecessarily toxic from what I've seen
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.
GrapheneOS developers keep insisting [0] that their security model is the only reasonably secure approach in the world, despite that Qubes OS proved that wrong.
https://news.ycombinator.com/item?id=45101400
>their security model is the only reasonably secure approach in the world
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.
See the response at https://news.ycombinator.com/item?id=45244398.
>> their security model is the only reasonably secure approach in the world
>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.
Librem 5 not only doesn't provide firmware updates for serious security vulnerabilities but goes out of the way to block the OS from doing it and block updating firmware in general. It uses a bunch of low security components. It's a closed source device with closed source firmware. Not updating the firmware from the OS has nothing to do with a threat model but rather a loophole in a definition of freedom where a device with a fully closed source OS would be considered free as long as it couldn't be updated by anyone...
> Librem 5 not only doesn't provide firmware updates for serious security vulnerabilities but goes out of the way to block the OS from doing it and block updating firmware in general
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.)
Sorry, but it is very difficult to understand what you mean and what you want from GrapheneOS. GrapheneOS is a FOSS project and they have committed to that being the case for the forseeable future.
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?
> Why should anyone expect them to throw away everything
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.
>I just wanted to get a statement from them concerning what's a reasonable goal and what isn't
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.
QubesOS provides strong compartmentalization between virtual machines defined by the user, but it doesn't provide better protection against exploitation within those guests. Network drivers are a special case due to running in a dedicated VM. Applications and guest operating systems are just as vulnerable to exploitation. They're not hardened operating systems but rather traditional desktop OSes with a weak privacy and security model. QubesOS similarly doesn't provide any significant protection against data extraction in the After First Unlock state. It's nearly entirely focused on compartmentalization at the granularity of a whole OS.
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.
> but it doesn't provide better protection against exploitation within those guests
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?
> 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.
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.
How did Qubes OS prove them wrong? You still have root on qubes, humans still make errors, IMO it's therefore technically still less secure. Of course this assumes your goal is to prevent bad things from happening in general, regardless of how it happens, and not just say "yea the OS is secure but humans can still mess things up by using it wrong".
I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
> 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."
See also: https://news.ycombinator.com/item?id=45081344
See the response at https://news.ycombinator.com/item?id=45244398.
Even if that's true, it's not a knock against GrapheneOS itself. It's a subjective stance, not an objective one. This may be useful for some people to consider what projects they want to support, but it's not pertinent to discussions of function.
I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.
Your link does not support the text in your comment.
See the response at https://news.ycombinator.com/item?id=45244398.
https://news.ycombinator.com/item?id=45250815
What utter nonesense. Just because the GrapheneOS Team doesn't do free work to support devices you like doesn't mean they prevent you from doing it. It's still 100% opensource and you are free to port it yourself to whatever device you please. The entitlement of people that want the grapheneos project to work for them for free is insane. Fucking hire a dev to work on this for a few month yourself if you don't like the device support.
See the response at https://news.ycombinator.com/item?id=45244398.
I explicitly said in the link that the lack of resources is a good reason for not supporting other devices, but it's not their stated main reason.
[dead]
The only reason I ditched GrapheneOS is because it doesn’t support automatic call recording. Sure, you can hit the record button every time you pick up, but who remembers to do that? Plenty of people have asked for this feature on GitHub [0], and the way the lead developer responds makes it look like there are some serious unresolved mental issues at play. Then I watched Louis Rossmann’s video [1] about him, and that sealed it. I refuse to touch Graphene OS with a 20 foot pole.
0. https://web.archive.org/web/20250123135603/https://github.co... 1. https://www.youtube.com/watch?v=Dl1x1Dy-ej4
> Then I watched Louis Rossmann’s video [1] about him, and that sealed it.
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...
they actually don't want futo grants anymore
> 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.
https://x.com/GrapheneOS/status/1854611673711353902
Why is it that whenever someone makes an accusation of bad behaviour from GrapeheneOS devs, they always end the posts with citations that lead to absolutely nowhere? Where, specifically in that first link as I don't consider a Louis Rossmann video a credible source, are these indications of "unresolved mental issues"?
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.
Do you think Louiss fabricated that chat he was showing in realtime? Seemed pretty unhinged to me...
Strcat gets harassed based on frivolties, manufactured outrage. There have been repeated accusations of mental health issues without any substantive evidence, including from the person I was just replying to. The evidence they do give is usually of the developer expressing frustration at dealing with those accusations, which is ironic given that those accusations are self evidently true given that the people making those posts are usually accusing them!
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.
Idk anything about this drama, but "frustrated" is generous interpretation. Dude left an comment on a YouTube video and the guy freaked out on him. Seems like exactly the type of behavior he's claiming isn't real. I just want to know the OS I'm installing on my phone isn't at the whims of anyone who could pull a "colours/faker" stunt. But hopefully the project has governance and control that no single person could that that anyways (otherwise it'd be hard to calm it's a "secure" alternative)
If you don't know anything about the "drama" then maybe you should avoid jumping to conclusions.
I don’t think that you need to know anything about the drama to know that there is no context in which responses showed in the video are fine. Did strcat apologise for it?
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.
Rossman was complicit in harassment, harassment (particularly at this scale, driven by their significant viewer base) that would be harmful to literally anyone who would be the target of it. strcat was upset, understandably, and privately communicated that to Rossman who then proceeds to cynically turn it into something to generate more views for his channel.
Apologise for what?
Once again, there is no context in which strcat’s comments to Rossman would be fine which are in the video in full. Repeating a context won’t change this. Even if the main points of strcat is fine, their style was really, really bad, without the possibility of excuse. They got plenty of options for excuse during the conversation, they clearly didn’t use them. The whole conversation just seemingly proved the point of “harassments”.
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.
The video you're referencing very clearly exists for the purpose of directing harassment towards me based on fabrications and spin as part of Rossmann's bullying towards me. Nearly all of the claims he makes in the video are lies of misrepresentations, including even the title.
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.
See https://news.ycombinator.com/item?id=45255341.
I reflected only on the comments which you sent to Rossmann; you don’t deny that you sent those AFAIK. I purposefully ignored everything what Rossmann said. As I said, even if you’re right, those comments were mistakes.
It's a fabricated story which you're taking at face value. What Rossmann claims to have been said to him was not said to him. He deliberately misrepresents what was said and the context of him engaging in many months of public and private bullying leading up to it. See https://news.ycombinator.com/item?id=45255341.
The basic thing is that the developer had been swatted multiple times right before that video. Swatted by a fan of the YouTubers who made the video that Louis commented on.
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.
> Dude left an comment on a YouTube video and the guy freaked out on him.
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.
Unsubstantiated? Have you looked at his post history?
https://news.ycombinator.com/threads?id=strcat
It's kind of funny that you're doing the exact same thing the person I initially responded to was doing, making a broad accusation and posting a link as evidence without specifying what it is within that link that you have a problem with. Grow a backbone and actually pull a quote that you feel is relevant.
joemazerino very frequently makes inaccurate claims about GrapheneOS and has been participating in bullying towards me for years. He has repeatedly lied about me and pushed fabricated stories. You're not going to find anything in my post history to back up his claims that I'm insane or delusional. If you look through his comment history, you'll find a lot of evidence that he has an unhealthy obsession with me and is blatantly engaging in bullying. It's something Hacker News should be addressing as a moderation issue. It should not be permitted to engage in blatant bullying and harassment on this platform including repeatedly claiming an open source developer is insane.
Convinced yet?
Convincing or not, given strcat (Daniel) is very vocal that you stop (what they sincerely feels is) harrasment, should be an indication enough that you do.
I don't listen to people who accuse me of being complicit in swatting attacks, and I don't cowtow to bullies. The truth will always come out.
This is informative, and unfortunate
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).
I am sick of people raising this developer's mental issues. This is 2025, we should be sympathetic and encouranging to any human being struggling with mental issues, helping them get through or at least not trip them or sideline them. GrapheneOS is undeniably a project of great value, if you don't like something about it's development raise it and stop there as you would do with any project. Stop the "Graphene doesn't have X feature but the lead dev is nuts so I don't touch it" meme.
Completely agree. Writing off the project's numerous benefits on the basis of one missing feature is irrational. Immediately moving on to attack him personally by claiming he's mentally ill makes it impossible to assume good faith.
This is besides the point. The lead dev started going on a rant when facing a comment as simple as "this is informative, and unfortunate" on a video that he didn't like, and is unable to parse that statement as anything else but a personal attack at him. He threatened banning Louis over that unless he completely gave in. You can see the whole discussion in the video linked in the post above.
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.
I know the whole story in depth and you keep iterating over the same thing.
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?
Posting "this is informative, and unfortunate" as a comment to a video with a bunch of inflammatory accusations is giving credence to and expressing approval at the substance of it's content.
So no, it isn't as "simple" as the issue being only the literal content of that comment. The context matters.
As someone else pointed out, it's not just the comment. There's context you're either ignoring because it's inconvenient for you, or you don't know because you couldn't be bothered to learn more about it.
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.
GrapheneOS being in use by people and orgs with a high security requirement dictates an organizational review. OPSEC extends beyond just cyber capabilities.
The people calling me insane, delusional, schizophrenic, etc. almost entirely don't believe what they're saying as there's no actual basis for it. All they can do is link to incredibly dishonest harassment content from Louis Rossmann and Henry Fisher where they engage in a monologue pushing fabricated stories. What they show as supposed evidence doesn't at all match their claims and instead they heavily misrepresent it.
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.
Couldn't that be achieved by a separate app? Why would the OS need to do it?
Automatic recording may be illegal in jurisdictions that mandate permission from both parties. I can see why gos might not want to include it in a base operating system.
https://en.wikipedia.org/wiki/Telephone_call_recording_laws
Samsung phones have it. I have verified from at least one source who lives in one of such jurisdictions (India), a Samsung phone they bought has this feature. So, it doesn't have anything to do with the law.
We never said we wouldn't implement it. We said the current pull request is inadequate because it doesn't show users that it's enabled so people can end up accidentally recording a bunch of calls if they toggle it on and forget about it or toggle it by accident.
I'm one of GrapheneOS's moderators and just saw this.
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.
From what I can tell sounds like this guy's stepped away from the project? Curious what the latest status is.
He didn't step away. He made a post where he "stepped down" as the project lead and instead got replaced by a "GrapheneOS Foundation director", of which there are 3 including him.
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.
Is strcat the person who supposedly stepped down?
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:
https://news.ycombinator.com/item?id=45214818
> Is strcat the person who supposedly stepped down?
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.
Getting to the meat of why they didn't implement automatic call recording is that storage could fill up and they didn't want to implement managing user storage? I mean sounds like a fair call.
We never said we wouldn't implement it. We said the current pull request is inadequate because it doesn't show users that it's enabled so people can end up accidentally recording a bunch of calls if they toggle it on and forget about it or toggle it by accident.
[dead]