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.
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.
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:
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.
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.
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.
> 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.
> 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:\
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.
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.
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.
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
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!).
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.
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.
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.
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)
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.
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.
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.
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."
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.
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.
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.
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"?
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.
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.
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.
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.
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.
electric_muse|5 months ago
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.
vid|5 months ago
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.
drnick1|5 months ago
pndy|5 months ago
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.
glitchc|5 months ago
codethief|5 months ago
You mean different user accounts? Those are available on stock Android, too.
dosshell|5 months ago
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
neilv|5 months ago
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).
EvanAnderson|5 months ago
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
hsbauauvhabzb|5 months ago
estimator7292|5 months ago
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.
discardedrefuse|5 months ago
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.
zevon|5 months ago
lawn|5 months ago
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.
ysnp|5 months ago
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.
hagbard_c|5 months ago
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.
ForHackernews|5 months ago
ReluctantLaser|5 months ago
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.
strcat|5 months ago
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.
hydraraptor81|5 months ago
[deleted]
yjftsjthsd-h|5 months ago
It really is sad that there isn't any ROM with Graphene's permission and sandboxing features while still leaving the user in control. IIRC it's theoretically possible since they publish the code, but one assumes it would be a non-trivial effort:\
crapple8430|5 months ago
See: github.com/chenxiaolong/avbroot
subscribed|5 months ago
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
charcircuit|5 months ago
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
ranger_danger|5 months ago
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
npteljes|5 months ago
Taek|5 months ago
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
tietjens|5 months ago
cool_cherry|5 months ago
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
palata|5 months ago
* 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.
ysnp|5 months ago
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.
arminiusreturns|5 months ago
unethical_ban|5 months ago
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.
krior|5 months ago
junkblocker|5 months ago
strcat|5 months ago
throawayonthe|5 months ago
ThePowerOfFuet|5 months ago
romanpoet|5 months ago
The recommended app is "Shelter". https://f-droid.org/en/packages/net.typeblog.shelter/
strcat|5 months ago
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.
o999|5 months ago
NoiseBert69|5 months ago
Loving it.
TranquilMarmot|5 months ago
mark_l_watson|5 months ago
raybb|5 months ago
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)
strcat|5 months ago
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.
BLKNSLVR|5 months ago
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.
angusturner|5 months ago
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.
strcat|5 months ago
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.
pull_my_finger|5 months ago
ewuhic|5 months ago
ysnp|5 months ago
unknown|5 months ago
[deleted]
lawn|5 months ago
But there are some exceptions out there so you need to be more specific.
npteljes|5 months ago
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.
bpiroman|5 months ago
fsflover|5 months ago
nunobrito|5 months ago
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.
tranq_cassowary|5 months ago
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."
pandemic_region|5 months ago
aswerty|5 months ago
I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.
tranq_cassowary|5 months ago
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.
noirscape|5 months ago
* 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.
slashtab|5 months ago
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.
other8026|5 months ago
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.
fsflover|5 months ago
https://news.ycombinator.com/item?id=45101400
ysnp|5 months ago
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.
strcat|5 months ago
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.
ranger_danger|5 months ago
I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
unknown|5 months ago
[deleted]
BLKNSLVR|5 months ago
I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.
hollerith|5 months ago
ajjahs|5 months ago
[deleted]
IlikeKitties|5 months ago
whatsupdog|5 months ago
0. https://web.archive.org/web/20250123135603/https://github.co... 1. https://www.youtube.com/watch?v=Dl1x1Dy-ej4
ignoramous|5 months ago
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...
scheeseman486|5 months ago
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.
fluidcruft|5 months ago
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).
gtsop|5 months ago
Iolaum|5 months ago
sandworm101|5 months ago
https://en.wikipedia.org/wiki/Telephone_call_recording_laws
other8026|5 months ago
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.
cjonas|5 months ago
commandersaki|5 months ago
ohdeargodno|5 months ago
[deleted]