I just bought a pixel from best buy to install gos, which was an ordeal.
At checkout they looked at me like I was up to no good when I said I didn’t want to give them my name, address, and phone number just to purchase the device. I didn’t set up a plan. They said it was for “restocking” or something.
Fortunately they accepted obviously fake info. These front line sales people just don’t care as long as they can say they followed the policy.
The user containers are very helpful. I have to have TikTok for work and I put it in a container all by itself with a vpn on kill switch. And for one app that needs google play services, I have it a container with that.
The duress passcode is super clever, too. You enter a different device passcode and it just wipes the device.
Obviously avoiding surveillance can be a bigger red flag than being surveilled.
I use a google account for convenience for some purposes, and host my own email (out of principle, not exactly super interesting material). It would be nice if when I enter the 'duress' password it erased everything except the gmail related activity.
I recently bought a Pixel from a Google store and wasn't asked any personal information. I installed Graphene right away and the phone just works. I use FOSS apps obtained on F-Droid and don't bother with sandboxed Google Play and all that. For me that kind of defeats the point of a FOSS OS.
Sandboxed Google Play doesn't really defeat the point of GrapheneOS. Not wanting to use Google Play or any proprietary Google services is perfectly valid, for all clarity. But, it's just important to note that for people that heavily use Google services, the advantage of using those on GrapheneOS instead of on a GMS-licensing OS is very high. The GMS-licensing OS will bundle the Google Mobile Services (Google suite off apps, Google Play, ...) in a privileged way. They won't be treated as regular apps, as is the case on GrapheneOS, but will have invasive access on your phone. In general, GrapheneOS' many hardening and privacy features allow you to have a better grasp on privacy-invasive apps.
On GrapheneOS they're profiles. Pretty much the same as with the stock aosp, but they add very extensive support - like notifications forwarding and a perfect balance between security and convenience, 2FA with shorter pin.
Yes, but a small subset of the GrapheneOS features are enhancements to user profiles and Private Space. We enable more of the standard user profile functionality that's usually not available (such as ending secondary user sessions or toggling them running the background) and add extra features such as notification forwarding. For Private Space, we enable making them in secondary users instead of only Owner and provide control over clipboard sharing instead of it always being shared with the parent profile (the user it's nested in).
Our more prominent 2-factor fingerprint authentication feature is also relevant when switching between users a lot.
True, although on GrapheneOS, apps on different profiles can remain active when you switch and notifications can be sent to the primary profile if you choose.
Well, nobody's forced it, but my company publishes content on TikTok that drives customers, and I want to be able to see it myself. You'd be surprised how many CISOs and security workers are on TikTok.
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 did try phoneless for a few years, except for a dumbphone that I kept at home for the rare call or SMS 2FA.
The biggest factor that forced upgrading was poor call quality on the dumbphones I tried. (And this was really forced by bombing a particular important phone call because I couldn't be understood well.)
Then, once I found a smartphone that I kinda liked (GrapheneOS, after Apple sold out on surveillance), there were reasons to start carrying it. Rather than simply keeping it in a drawer at home.
But fortunately not sufficient reason so far to go full Google Play.
Email, Web, maps, authenticator, camera, and calls are all things I sometimes could use when out.
Though I normally don't have to have any of those, but I've been experimenting with it for a year or so, and seeing whether it's worthwhile.
Because obviously people want to enjoy technological usefulness (i.e. navigation, payments, communication) and automation while preserving dignity and not being spied like a bunch of ships.
If you are going to use a desktop instead, you are hurting your security significantly. Traditional desktop OSes like Window, MacOS and Linux desktop lack a sane security model with a mandatory app sandbox with fine-grained permissions. They also heavily use memory-unsafe code compared to modern OSes like Android OSes and iOS and lack modern exploit mitigations. Only daily drivable productions grade desktop OS with security in its foundations is ChromeOS.
I ran Graphene for several months and hated every minute of it. It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
I found the profile feature to be only slightly more convenient than having two physical devices. I could not find any real use for it. I thought I'd set up a work profile to attach to my work gsuite account. Nope, unsupported. I can't attach my work google account at all. Maybe I can just put all my google play dependent apps in a profile? Sure, but to get to them is just about as convenient as rebooting the phone from cold. And notifications are not forwarded to other profiles. If an event happens in another profile, you get a notification that there is a notification. You still have to drop everything to reboot into the other profile to check that you got an emote reaction to your Discord message. Great use of my time.
The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices.
I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
> Sure, but to get to them is just about as convenient as rebooting the phone from cold.
This just isn't true. Switching profiles is nothing like rebooting the phone. It takes about 8 seconds to go thru the entire procedure. That's including about 3 seconds to load the 2nd profile (even an unloaded profile). The procedure on my Pixel 7 goes:
It's important to note that user profiles are a standard Android feature, as are Private Space and work profiles nested within the Owner user. None of the core privacy and security features of GrapheneOS require using user profiles. We make certain enhancements to user profiles and Private Space. For user profiles, that's mainly allowing making more users, using more standard functionality (end session, more toggles to control access) and notification forwarding. For Private Space, we enable using them in secondary users and provide the important improvement of controlling clipboard sharing with the parent profile. Those profile improvements are a very tiny portion of what GrapheneOS provides. There's a common misconception that sandboxed Google Play requires profiles but that's not the case and they're regular sandboxed apps when installed in the Owner user too.
Huh? To me, Graphene just feels like unbloated Android with a few convenient ways of customizing google stuff and that's it. I like that it actually gets out of my way and I don't really understand how it "coddles" you.
Apart from having to tweak some location permissions for when I wanted to copy the BankID credentials from my old phone I haven't had to any tweaking or anything to get it to just work.
Google Play and associated services are not bundled with GrapheneOS, they are completely optional.
> I found the profile feature to be only slightly more convenient than having two physical devices.
User Profiles is a feature inherited from AOSP. This is what AOSP says about the feature: "Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty."
In the community it is popular to use multiple profiles to compartmentalise personas or group apps with hard google service dependencies together, but this is all completely optional. GrapheneOS as a project gently suggest keeping everything in the same initial owner profile and then moving things around to suit your comfort level.
> It's my device, not google's, and certainly not Graphene's.
You've clearly endured a lot of frustration when using the OS. Are there any specific things you remember trying to do that were blocked or prevented by GrapheneOS? It's not a project with unlimited resources, but actionable information about limitations and bugs can potentially be addressed if known.
As an alternative to running something like GrapheneOS to limit intrusive proprietary apps you can disable such apps and only enable them when required for some reason, then disable them again. To do so you'll want a rooted device, Termux and Termux:Widget for easy access to the enabling/disabling scripts. Here's an example of such a script, this one can be used to enable or disable Google services:
#!/data/data/com.termux/files/usr/bin/bash
PACKAGE="com.google.android.gms com.google.android.gms.policy_sidecar_aps com.google.android.gsf com.android.vending"
PATH="/data/data/com.termux/files/usr/bin:$PATH"
command=$(echo "$0"|cut -d: -f2)
pman () {
action=$1
shift
for package in $@; do
sudo pm $action $package
done
}
case $command in
disable|enable)
pman $command $PACKAGE
;;
*)
echo "command '$command' not supported"
;;
esac
exit 0
The script is stored in ~/.shortcuts/Name_of_package:enable and hardlinked to ~/.shortcuts/Name_of_package:disable. Its action depends on by which name it is called. The scripts can be started through a Termux widget from the launcher.
Notice that the script can enable/disable multiple packages by adding package names to the $PACKAGES variable.
I enable and disable things like Google Services manually but the scheme can be extended as much as you wish, eg. by creating spin lock files to indicate whether a specific package is needed as a dependency for another package. This is left as an exercise for the reader.
They're describing a bad experience with heavily using Android's user profiles for compartmentalization, not GrapheneOS. An incredibly tiny portion of what GrapheneOS provides has to do with user profiles. GrapheneOS does not restrict/limit users in the way they're describing. They're attributing a very niche way they chose to set up and use the device to GrapheneOS when it's not tied to it. See https://news.ycombinator.com/item?id=45244497.
Disabling Google Play apps as you're describing will heavily break other apps and will cause lots of issues. It will not reduce what they can do or access. It's not an alternative to the privacy or security features provided by GrapheneOS. What the person above is describing has little to do with GrapheneOS specifically and doesn't make sense as an approach to using it.
An alternative (and possibly easier) way that doesn't require root is to use Hail + Shizuku.
Shizuku helps normal apps to use system APIs without root. You can enable it with from a computer with adb or from the phone itself using wireless debugging. Hail uses Shizuku's API access and lets you select apps to freeze. You can then unfreeze / refreeze apps with a quick tap in Hail.
If you already have root, all this becomes easier. If you do the wireless debugging method, Shizuku's API access won't survive a reboot. You'll have to go thru the wireless debugging procedure again before you can use Hail. https://shizuku.rikka.app/guide/setup/
You might prefer /e/OS: It's another de-googled Android variant but in contrast to Graphene the focus is on privacy and everyday usability. They aren't trying to produce an OS hardened against nation-state attackers, just one that doesn't routinely leak all your data to advertisers.
GrapheneOS provides much better privacy, stability and app compatibility than /e/ rather than only security. GrapheneOS entirely exists as a privacy project and focuses on security too in order to protect privacy. GrapheneOS is a privacy project aimed at being highly usability. There's a good third party comparison between them here:
/e/ regularly lags many weeks and months behind on essentially privacy and security patches for Android, the browser engine used by many apps, the Linux kernel, drivers and firmware. It doesn't preserve the standard Android privacy and security model either. It isn't safe from a privacy or security perspective for those reasons. It doesn't take a nation state attacker to exploit not having patches for many known browser/OS privacy and security vulnerabilities.
Despite the misleading marketing, /e/ always uses multiple Google services and integrates them into the OS with privileged access unavailable to other services. They automatically download and run Google code with privileged access along with giving privileged access to certain Google apps when they're installed including Android Auto.
Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches:
Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service:
perhaps its something you missed, but you can use a work profile. put all your google apps in there and its a tap of a button (quick setting pull down) to jump into. then another to turn it off. you get the benefits of sandboxing a bunch of apps, while using the same user profile. its very convenient.
I personally don't use the separate user profiles at all. I agree they are clunky, due to how segregated they are. though with a work profile, and if needed (I don't use it atm) the newly added android feature, a private space, I feel there are plenty of compartmentalisation/sandboxing options available within a single user profile.
Private Space is from Android 15 so GrapheneOS has provided support for it since October 2024 when Android 15 was released. Profiles are a standard Android feature, not something added by GrapheneOS, and are not required to benefit from the privacy and security it provides. Sandboxed Google Play does not depend on putting it in a secondary profile.
> It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
There are no restrictions on what people can do added by GrapheneOS compared to the Android Open Source Project / stock Pixel OS.
> Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
GrapheneOS doesn't come with Google Play. You would have had to install it yourself and those run as regular sandboxed apps with no special access. It doesn't make sense to turn it off and on which will break apps set up to depend on it. If you only want to use it with specific apps when needed, the right approach is using a dedicated profile for it. By turning it off, you were breaking apps installed in the same profile with it which use it.
Using a single profile with sandboxed Google Play is perfectly fine and doesn't ruin the privacy and security provided by GrapheneOS. Putting it into a separate profile is optional. Sandboxed Google Play are regular apps in the regular app sandbox with zero special access or privileges. Using multiple profiles to split things up is a more advanced approach.
> I found the profile feature to be only slightly more convenient than having two physical devices.
That's the purpose of secondary users. There are also the more convenient work profiles and Private Spaces. All 3 of these features are standard Android features. GrapheneOS enhances user profiles and Private Spaces in various ways but they're not at all mandatory and there's nothing pushing people to use them more than the stock OS. There's a widespread misconception that the sandboxing of sandboxed Google Play is tied to profiles but it's not.
> The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
GrapheneOS deeply cares about user experience including app compatibility. We have limited resources so we haven't been able to replace or overhaul all of the AOSP apps yet, which is the main weakness of the out-of-the-box experience. Those can all be replaced by the user's choice of apps.
> Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
No, not at all.
> Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Profiles are an Android feature, not a GrapheneOS feature, and only a tiny portion of our features have to do with them. The features page at https://grapheneos.org/features covers most of the features added by GrapheneOS, and very little of that has to do with profiles. It sounds like you chose to heavily use secondary users and didn't like that, which has little to do with GrapheneOS specifically.
> Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices.
>
> I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
GrapheneOS did not create Android's user profile feature. It makes enhancements to it but it's not a major focus of what we work on. You aren't missing many of the GrapheneOS features if you don't use user profiles. Enabling more standard user profile functionality, notification forwarding, allowing more user profiles and a few other minor things are all we do with those. We have a substantial set of privacy and security features and nearly none of it has to do with profiles. Adding clipboard control to Private Space and enabling making Private Spaces in secondary users are how we improve those. Many GrapheneOS users only use an Owner user or Owner with a Private Space and/or work profile. Secondary users are a much more specialized thing. It's not expected that people split things across a bunch of secondary users, that's an advanced power user approach.
> GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
It really is sad that there isn't any ROM with Graphene's permission and sandboxing features while still leaving the user in control. IIRC it's theoretically possible since they publish the code, but one assumes it would be a non-trivial effort:\
As described in the README, the combination of root access and locking the bootloader has the caveat that it's easy to brick your boot partition by accidentally making changes to it. That causes the signature check to fail, and then you have to unlock the bootloader and wipe all your data to re-flash it.
I don't know if there's any good solution to this, since all this seems to be necessary for the security model.
EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other)
Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?
After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.
> I dint understand why you insist on this massive risk to be laid on on everyone.
Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.
Giving the user control does not mean giving the user root. Giving root breaks Android security model. Whatever capability you want should be implemented as a proper feature to avoid breaking the security of the device.
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
That would be nice, but trying to get those kinds of functionality upstreamed into GOS so they can be exposed tovapps in a structured way with the usual permissions model is a high effort.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.
The same is true even of an operating system such as QubesOS. And it's a minimal risk.
Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.
Quoting inline since parent has been rewritten multiple times now...
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think
> An accessibility service trivially has root access.
is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.
> In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.
> A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
I use Graphene for years now and it's the most out of my way OS I have used on my phones so far. It Just Works™, no bundleware, all the freedom I need.
To be fair, "it just works" is a relatively recent feature of Graphene. It used to not be able to support things like Uber, Google Maps, etc.
And, I still haven't been able to get it to properly support Google Fi, wherever I switch profiles it confuses the carrier and my access gets reset.
My solution has been to have two phones, one with Google Fi that I use to hotspot my Graphene device. Everything else seems to work fine on Graphene, including Uber and maps and calendar and VPNs and isolated profiles for gaming vs work vs socializing, etc
The sandboxed Google Play compatibility layer was added in July 2021 and quickly advanced from there, being able to support nearly all Play Store apps depending on Play services by around the end of the year.
Note Google Maps used to work without sandboxed Google Play without account-based functionality and it having a hard dependency on Google Play happened around a year ago or so.
That is something to do with Google Fi, not GrapheneOS. You can work around it by having the Google Fi app installed in the secondary profile and signed into the Google account associated with your service. Although I don't see much point in that. Anyway, it's not an issue caused by GrapheneOS, just Google Fi expecting to be present to grant service access.
Yeah, I suspect this really is a YMMV situation. I approach phones from my PC / Linux background, with a specific subset of software I wanna use, and it was a perfect match for that. If someone expects it to be "Android, but somehow better", then it likely won't deliver.
Sincere question: what is the point of using this OS for privacy and then using Google services? The intro runs though how it’s very easy to do this. Maybe I’m missing something.
Google Play Services is a dependency for some apps, and GrapheneOS allows for people to take steps to protect their privacy while still being able to use those apps.
First, with GrapheneOS google play services run in a sandbox like any other app. (play services have more privileged access in vanilla android)
It also works well with a multi-user setup. The default account in Android is the "owner account" and in GrapheneOS (and AOSP) you can use the owner account to create multiple distinct user accounts on the device. Then, you can only install google play services in one user account. Google play services won't start if you're not logged into that user account.
Google play services won't have visibility into your other user accounts and what you're doing there. And even in your account with play services installed, there's a bit more privacy because of the sandboxing (although I believe google play will know all of the apps installed in that user account)
Edit: I am a web security researcher and longtime user of GrapheneOS and have always been impressed by the features, frequent security updates, and focus on usability, security, and privacy. They've upstreamed numerous security improvements to Android and other open source projects (so if you're running Android, they've probably made your phone more secure!).
Why is this in any way superior to microg, apart from compatibility? Microg simply spoofs/shims the API while not actually contacting Google servers at all.
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.
Which itself is not guaranteed to work even on ”stock” Android, let alone GOS — which multiple people (myself included) have been experiencing firsthand.
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.
Readit News
At checkout they looked at me like I was up to no good when I said I didn’t want to give them my name, address, and phone number just to purchase the device. I didn’t set up a plan. They said it was for “restocking” or something.
Fortunately they accepted obviously fake info. These front line sales people just don’t care as long as they can say they followed the policy.
The user containers are very helpful. I have to have TikTok for work and I put it in a container all by itself with a vpn on kill switch. And for one app that needs google play services, I have it a container with that.
The duress passcode is super clever, too. You enter a different device passcode and it just wipes the device.
I use a google account for convenience for some purposes, and host my own email (out of principle, not exactly super interesting material). It would be nice if when I enter the 'duress' password it erased everything except the gmail related activity.
A physical pop-up? The online google store requires a google account that has your personal info already..
That's a thing in the US? Here, clerks in various stores ask me for postal code but nothing else and I could refuse giving that info.
You mean different user accounts? Those are available on stock Android, too.
Our more prominent 2-factor fingerprint authentication feature is also relevant when switching between users a lot.
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
Edit: "experts" > "workers"
Although GrapheneOS puts a lot of work into sandboxing and protecting against Google Play, don't assume that you have to go that direction.
An alternative direction, if you wish, is to simply minimize the set of apps you use. And maybe it turns out that you don't really need anything from Google Play.
For example, I limit myself to a few open source apps (e.g., email, TOTP authenticator, maps, calendaring).
Anything else, either I don't need to do it from my phone, or I can get by with the Web site version of it in the phone's Web browser.
I also recently went through and deleted some open source apps that were a good idea to try, and which initially seemed like a good idea to keep on hand, but that I really wasn't using, and didn't expect to use without opportunity to reinstall them, so were just clutter and risk (e.g., Matrix, XMPP, Signal).
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
The biggest factor that forced upgrading was poor call quality on the dumbphones I tried. (And this was really forced by bombing a particular important phone call because I couldn't be understood well.)
Then, once I found a smartphone that I kinda liked (GrapheneOS, after Apple sold out on surveillance), there were reasons to start carrying it. Rather than simply keeping it in a drawer at home.
But fortunately not sufficient reason so far to go full Google Play.
Email, Web, maps, authenticator, camera, and calls are all things I sometimes could use when out.
Though I normally don't have to have any of those, but I've been experimenting with it for a year or so, and seeing whether it's worthwhile.
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.
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.
Notice that the script can enable/disable multiple packages by adding package names to the $PACKAGES variable.
I enable and disable things like Google Services manually but the scheme can be extended as much as you wish, eg. by creating spin lock files to indicate whether a specific package is needed as a dependency for another package. This is left as an exercise for the reader.
Disabling Google Play apps as you're describing will heavily break other apps and will cause lots of issues. It will not reduce what they can do or access. It's not an alternative to the privacy or security features provided by GrapheneOS. What the person above is describing has little to do with GrapheneOS specifically and doesn't make sense as an approach to using it.
Recommend reading https://grapheneos.org/features and looking at https://eylenburg.github.io/android_comparison.htm for an understanding of what GrapheneOS provides.
Shizuku helps normal apps to use system APIs without root. You can enable it with from a computer with adb or from the phone itself using wireless debugging. Hail uses Shizuku's API access and lets you select apps to freeze. You can then unfreeze / refreeze apps with a quick tap in Hail.
If you already have root, all this becomes easier. If you do the wireless debugging method, Shizuku's API access won't survive a reboot. You'll have to go thru the wireless debugging procedure again before you can use Hail. https://shizuku.rikka.app/guide/setup/
https://eylenburg.github.io/android_comparison.htm
/e/ regularly lags many weeks and months behind on essentially privacy and security patches for Android, the browser engine used by many apps, the Linux kernel, drivers and firmware. It doesn't preserve the standard Android privacy and security model either. It isn't safe from a privacy or security perspective for those reasons. It doesn't take a nation state attacker to exploit not having patches for many known browser/OS privacy and security vulnerabilities.
Despite the misleading marketing, /e/ always uses multiple Google services and integrates them into the OS with privileged access unavailable to other services. They automatically download and run Google code with privileged access along with giving privileged access to certain Google apps when they're installed including Android Auto.
Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches:
https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nich...
Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service:
https://community.e.foundation/t/voice-to-text-feature-using...
Information from the founder of the Divested projects:
Issues with /e/: https://codeberg.org/divested-mobile/divestos-website/raw/co... ASB update history: https://web.archive.org/web/20241231003546/https://divestos.... Chromium update history: https://web.archive.org/web/20250119212018/https://divestos.... Chromium update summary: https://infosec.exchange/@divested/112815308307602739
I personally don't use the separate user profiles at all. I agree they are clunky, due to how segregated they are. though with a work profile, and if needed (I don't use it atm) the newly added android feature, a private space, I feel there are plenty of compartmentalisation/sandboxing options available within a single user profile.
There are no restrictions on what people can do added by GrapheneOS compared to the Android Open Source Project / stock Pixel OS.
> Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
GrapheneOS doesn't come with Google Play. You would have had to install it yourself and those run as regular sandboxed apps with no special access. It doesn't make sense to turn it off and on which will break apps set up to depend on it. If you only want to use it with specific apps when needed, the right approach is using a dedicated profile for it. By turning it off, you were breaking apps installed in the same profile with it which use it.
Using a single profile with sandboxed Google Play is perfectly fine and doesn't ruin the privacy and security provided by GrapheneOS. Putting it into a separate profile is optional. Sandboxed Google Play are regular apps in the regular app sandbox with zero special access or privileges. Using multiple profiles to split things up is a more advanced approach.
> I found the profile feature to be only slightly more convenient than having two physical devices.
That's the purpose of secondary users. There are also the more convenient work profiles and Private Spaces. All 3 of these features are standard Android features. GrapheneOS enhances user profiles and Private Spaces in various ways but they're not at all mandatory and there's nothing pushing people to use them more than the stock OS. There's a widespread misconception that the sandboxing of sandboxed Google Play is tied to profiles but it's not.
> The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
GrapheneOS deeply cares about user experience including app compatibility. We have limited resources so we haven't been able to replace or overhaul all of the AOSP apps yet, which is the main weakness of the out-of-the-box experience. Those can all be replaced by the user's choice of apps.
> Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
No, not at all.
> Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Profiles are an Android feature, not a GrapheneOS feature, and only a tiny portion of our features have to do with them. The features page at https://grapheneos.org/features covers most of the features added by GrapheneOS, and very little of that has to do with profiles. It sounds like you chose to heavily use secondary users and didn't like that, which has little to do with GrapheneOS specifically.
> Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices. > > I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
GrapheneOS did not create Android's user profile feature. It makes enhancements to it but it's not a major focus of what we work on. You aren't missing many of the GrapheneOS features if you don't use user profiles. Enabling more standard user profile functionality, notification forwarding, allowing more user profiles and a few other minor things are all we do with those. We have a substantial set of privacy and security features and nearly none of it has to do with profiles. Adding clipboard control to Private Space and enabling making Private Spaces in secondary users are how we improve those. Many GrapheneOS users only use an Owner user or Owner with a Private Space and/or work profile. Secondary users are a much more specialized thing. It's not expected that people split things across a bunch of secondary users, that's an advanced power user approach.
Dead Comment
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:\
See: github.com/chenxiaolong/avbroot
I don't know if there's any good solution to this, since all this seems to be necessary for the security model.
EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other) Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.
> I dint understand why you insist on this massive risk to be laid on on everyone.
Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
It's true only if user is the threat for the user, e.g. a user with low IQ but high curiosity, but such user usually cannot install GrapheneOS.
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
The same is true even of an operating system such as QubesOS. And it's a minimal risk.
Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.
Yes, I'm sure it is. But I don't consider that a tolerable tradeoff, and I believe we could have a system that has most of the best of both worlds.
Would this have been easier or more possible if Android had a full capability-based security model?
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think
> An accessibility service trivially has root access.
is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.
> In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.
> A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
Agreed, that's not what I want.
And, I still haven't been able to get it to properly support Google Fi, wherever I switch profiles it confuses the carrier and my access gets reset.
My solution has been to have two phones, one with Google Fi that I use to hotspot my Graphene device. Everything else seems to work fine on Graphene, including Uber and maps and calendar and VPNs and isolated profiles for gaming vs work vs socializing, etc
Note Google Maps used to work without sandboxed Google Play without account-based functionality and it having a hard dependency on Google Play happened around a year ago or so.
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.
I’m just wondering what the selling point for using Graphene with Google is. Very Graphene curious.
The recommended app is "Shelter". https://f-droid.org/en/packages/net.typeblog.shelter/
Secondary users, work profiles and Private Spaces are standard Android features but GrapheneOS does provide improvements to secondary users and Private Spaces such as control over clipboard sharing with a Private Space, enabling having a Private Space for each secondary user, cross-user notification forwarding, etc. https://grapheneos.org/features has a good overview of most (not all) GrapheneOS features.