Introduction to GrapheneOS (opens in new tab)

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.

That's a thing in the US? Here, clerks in various stores ask me for postal code but nothing else and I could refuse giving that info.

You mean different user accounts? Those are available on stock Android, too.

I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?

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

This just isn't true. Switching profiles is nothing like rebooting the phone. It takes about 8 seconds to go thru the entire procedure. That's including about 3 seconds to load the 2nd profile (even an unloaded profile). The procedure on my Pixel 7 goes:

- Swipe down to open the Notification Panel

- Swipe down again to expand the Quick Settings

- Tap the User icon at the bottom

- Select the user profile you want to open

- Wait 3 seconds

- Enter the 2nd user's PIN to log in

That's 4 taps + 3 seconds of load time.

Apart from having to tweak some location permissions for when I wanted to copy the BankID credentials from my old phone I haven't had to any tweaking or anything to get it to just work.

Google Play and associated services are not bundled with GrapheneOS, they are completely optional.

> I found the profile feature to be only slightly more convenient than having two physical devices.

User Profiles is a feature inherited from AOSP. This is what AOSP says about the feature: "Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty."

In the community it is popular to use multiple profiles to compartmentalise personas or group apps with hard google service dependencies together, but this is all completely optional. GrapheneOS as a project gently suggest keeping everything in the same initial owner profile and then moving things around to suit your comfort level.

> It's my device, not google's, and certainly not Graphene's.

You've clearly endured a lot of frustration when using the OS. Are there any specific things you remember trying to do that were blocked or prevented by GrapheneOS? It's not a project with unlimited resources, but actionable information about limitations and bugs can potentially be addressed if known.

   #!/data/data/com.termux/files/usr/bin/bash 
   
   PACKAGE="com.google.android.gms com.google.android.gms.policy_sidecar_aps com.google.android.gsf com.android.vending"
   PATH="/data/data/com.termux/files/usr/bin:$PATH"
   
   command=$(echo "$0"|cut -d: -f2)
   
   pman () {
        action=$1
        shift
        for package in $@; do
             sudo pm $action $package
        done
   }
   
   case $command in
   disable|enable)
        pman $command $PACKAGE
        ;;
   *)
        echo "command '$command' not supported"
        ;;
   esac
   exit 0

Notice that the script can enable/disable multiple packages by adding package names to the $PACKAGES variable.

I enable and disable things like Google Services manually but the scheme can be extended as much as you wish, eg. by creating spin lock files to indicate whether a specific package is needed as a dependency for another package. This is left as an exercise for the reader.

I personally don't use the separate user profiles at all. I agree they are clunky, due to how segregated they are. though with a work profile, and if needed (I don't use it atm) the newly added android feature, a private space, I feel there are plenty of compartmentalisation/sandboxing options available within a single user profile.

There are no restrictions on what people can do added by GrapheneOS compared to the Android Open Source Project / stock Pixel OS.

> Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.

GrapheneOS doesn't come with Google Play. You would have had to install it yourself and those run as regular sandboxed apps with no special access. It doesn't make sense to turn it off and on which will break apps set up to depend on it. If you only want to use it with specific apps when needed, the right approach is using a dedicated profile for it. By turning it off, you were breaking apps installed in the same profile with it which use it.

Using a single profile with sandboxed Google Play is perfectly fine and doesn't ruin the privacy and security provided by GrapheneOS. Putting it into a separate profile is optional. Sandboxed Google Play are regular apps in the regular app sandbox with zero special access or privileges. Using multiple profiles to split things up is a more advanced approach.

> I found the profile feature to be only slightly more convenient than having two physical devices.

That's the purpose of secondary users. There are also the more convenient work profiles and Private Spaces. All 3 of these features are standard Android features. GrapheneOS enhances user profiles and Private Spaces in various ways but they're not at all mandatory and there's nothing pushing people to use them more than the stock OS. There's a widespread misconception that the sandboxing of sandboxed Google Play is tied to profiles but it's not.

> The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.

GrapheneOS deeply cares about user experience including app compatibility. We have limited resources so we haven't been able to replace or overhaul all of the AOSP apps yet, which is the main weakness of the out-of-the-box experience. Those can all be replaced by the user's choice of apps.

> Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.

No, not at all.

> Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.

Profiles are an Android feature, not a GrapheneOS feature, and only a tiny portion of our features have to do with them. The features page at https://grapheneos.org/features covers most of the features added by GrapheneOS, and very little of that has to do with profiles. It sounds like you chose to heavily use secondary users and didn't like that, which has little to do with GrapheneOS specifically.

> Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices. > > I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.

GrapheneOS did not create Android's user profile feature. It makes enhancements to it but it's not a major focus of what we work on. You aren't missing many of the GrapheneOS features if you don't use user profiles. Enabling more standard user profile functionality, notification forwarding, allowing more user profiles and a few other minor things are all we do with those. We have a substantial set of privacy and security features and nearly none of it has to do with profiles. Adding clipboard control to Private Space and enabling making Private Spaces in secondary users are how we improve those. Many GrapheneOS users only use an Owner user or Owner with a Private Space and/or work profile. Secondary users are a much more specialized thing. It's not expected that people split things across a bunch of secondary users, that's an advanced power user approach.

See: github.com/chenxiaolong/avbroot

I 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.

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.

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.

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

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

* If an app wants to access your contacts, you can choose which contacts, and you can choose to feed them a "fake" list (which is an empty list). Same for storage.

* You can choose not to give network access to an app, and the system will tell the app that there is no signal all the time.

The other very nice feature is that the Google Play Services and Play Store aren't running as system apps (i.e. they don't have root access): they just run like any other app. So you can choose not to share your contact list with them, for instance.

I don't think most people use Google services out of choice anyway, but more because sometimes that's the only way to get functionality you may need.

Google apps are still in a sandbox.

Location services and other features can be provided by non-Google services.

I know the OS itself isn't siphoning data; With my Oneplus 12 I had to check both Google and Oneplus configs to make sure I wasn't leaking anything.

I can disable network access for apps.

I can limit app access to Contacts and files with "scopes". For example, I have Whatsapp for only a few known people. Whatsapp demands access to your contacts. I can set up a scope called "Whatsapp Users", add only my friends to it, and then give Whatsapp Contact access to that scope.

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.

It's easy to set things up far less efficiently on GrapheneOS. As an example, Signal's WebSocket push fallback when Firebase Cloud Messaging is unavailable via Play services is quite inefficient. There's the Molly fork of Signal with support for UnifiedPush which has efficient alternatives to FCM, but since Signal's server doesn't support it this requires a MollySocket server to convert to UnifiedPush. There's at least one public provider. If you simply use FCM as you do on the stock OS then you wouldn't have any extra battery drain from running multiple often less efficient push implementations. It's common to want to avoid FCM to the extent possible, so people often do set things up less efficiently, but it's not because of GrapheneOS.

> Also, does this let you setup very restricted accounts like something for my parents so they can't go installing malware from the play store? (Parental controls are week in play store and malware rated for everyone in "weather" apps and the like)

You can use user profiles for this as you can on standard Android. If you want parental control software for those profiles, that's something you need to install. It's supported, but GrapheneOS is not going to specifically provide parental control and monitoring features rather than only the standard device/profile management APIs usable for it.

This doesn't however, prevent your parents from installing it again (it is installable from the GrapheneOS app store and therefore relatively easy to install), and then going nuts with installing whatever malware their storage can hold.

It's worth noting this is a standard Android feature along with work profiles and Private Space which are nested in another user. Private Space has built-in sharing functionality and work profiles can have it via the management app.

GrapheneOS enhances user profiles and Private Space but doesn't add the baseline features.

> I suspect one of the biggest barriers to mass adoption will be the fact that tap to pay doesn't work. IIUC apple/google pay are generally considered a privacy and security improvement over physical cards, since you don't give every merchant your actual card number.

Curve Pay, PayPal tap-to-pay and a bunch of European banks provide tap-to-pay support. Google Pay doesn't allow GrapheneOS but works on it on a technical level so if it was tricked into believing it was an old stock OS device, it would work, but that's not something feasible to keep working as they don't want to allow it.

But there are some exceptions out there so you need to be more specific.

Although, keep in mind, this is subject to change. All they need to do is just introduce the requirement in an app update, and then you're screwed.

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."

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.

Pixel is better hardware based on project's security requirement. you're simply wrong here.

Most of what you're complaining about are upstream Android limitation and problem.

I'm a GrapheneOS community moderator and I would disagree with this take. If people have issues with the community and feel that they can't ask "why" then a moderator should help with that. I can assure you we've had talks with "supportive" community members who cause problems. Being supportive of the project doesn't mean they can get away with acting rude towards others.

As for the F-Droid post, I never even heard of that post. I don't recognize the username of the user who posted it either. I guess I won't be able to see the original aggressive post, but either way just because someone is a fan doesn't mean the rest of our community is toxic.

> Instead of blockading SafetyNet as being a user hostile solution, GOS instead... implements their own version of it.

SafetyNet was depreciated, so you must be talking about Play Integrity. We don't reimplement Play Integrity, but rather have Sandboxed Google Play, and have even taken steps to reduce its effect on GrapheneOS users, notably optionally blocking API attempts or returning a server error (I forget) and blocking Google-injected code from running in apps that have automatic protection enabled in the Play Developer Console.

Outside of some workarounds, apps that expect Play Integrity verdicts can refuse to run if they choose to. Blocking things won't change that. Spoofing is also not practical because Google can and will break spoofing every time, especially since GrapheneOS has so many users. They already do that for people who root and use various spoofing methods.

> Pixel exclusivity is dumb and remains dumb.

Only Pixels meet the project's requirements as of now. GrapheneOS is in talks with a major OEM for them to get a few of their devices to meet the project's requirements and have official support for GrapheneOS. If all continues to go well, we expect it'll be 1-2 years before this happens.

> GOS doesn't let you do hosts based adblocking

There are apps and VPNs that can do this kind of thing.

> GOS as a project doesn't quite grasp the relationship between app developer and app user and how it's become toxified over the years > The problem these days is usually the developer going bad, not a third party.

The way you're talking here and your mention of F-Droid earlier leads me to believe you're a supporter of F-Droid. The project's advice is just that: advice. People are free to ignore that advice.

GrapheneOS is far from the only group that talks about issues with F-Droid. I don't personally know of all the issues with F-Droid, but as I understand it they use out of date servers, out of date build environments, and other similar issues. Also, they don't actually audit code at all, so developers can still sneak changes past them as long as the developers' changes aren't caught by their basic scanning. There's even the case where the WireGuard developer made changes that break F-Droid's terms of use or something like that. They were making those changes very much in the open and the F-Droid team didn't even notice. If a developer was trying to hide malicious changes, they could easily do that. No, we still have to trust developers. F-Droid is just another trusted party, and they don't deserve that trust considering all the issues they have.

They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems.

QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.

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.

I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.

I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.

fwiw, Louis Rossmann's employer/key supporter has disbursed grants to GrapheneOS and associated projects.

> Plenty of people have asked for this feature on GitHub

The issue has been deleted, but from the archive, (assuming the "lead developer" jab is aimed at Daniel) Micay says, "This is an issue that's going to be fixed and not a reason to change this." Then goes, "Please use reactions on the top level issue instead of adding comments expressing support for a change. You're sending unnecessary emails to the project developers."

As someone who maintains rather unremarkable FOSS projects, saying NO to feature requests is not at all easy in that it irks the community to no end, let alone one as large as Graphene's. Everyone is quick to reach all sorts of conclusions and pass judgements.

> ... the way the lead developer responds makes it look like there are some serious unresolved mental issues at play

afaik, there's 3 directors (also developers, from what I can tell) who steward GrapheneOS. Don't suppose they are all "mental"?

https://www.canadacompanyregistry.com/companies/grapheneos-f...

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).

https://en.wikipedia.org/wiki/Telephone_call_recording_laws

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.