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.
On GrapheneOS they're profiles. Pretty much the same as with the stock aosp, but they add very extensive support - like notifications forwarding and a perfect balance between security and convenience, 2FA with shorter pin.
It's incredibly useful! I have one profile for the "social" apps I don't trust (TikTok, Reddit, etc.). They can commingle. And there's another profile that contains the apps that rely on Google Play Services (e.g. something relies on google maps). As far as I understand it, it's like a strong firewall between them such that they are pretty close to having multiple different phones.
I understand that you have a concern, but may I ask what you mena specifically by "trust", and how would profiles help? Is it about accessing phone data or something else? As far as fingerprinting goes, I don't think profiles matter -- they already know who you are and can associate you with data from other sources.
I've successfully used Material Files [1] to set a nework shared folder (I think it was FTP) on one Android profile, and accessing it ("connecting" to it) from the other. So this might also work between GrapheneOS profiles.
You can share with file synchronisation apps like Syncthing/Ouisync [0], exploit a temporary weakness in the isolation model with Inter Profile Sharing [1], or simply copy the files over to an external storage device and transfer them that way.
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.
Secure folder is an older approach to what Android provides via the standard Private Space feature since Android 15. Private Space and work profiles are based on the same infrastructure as secondary users including per-profile encryption keys, although typically work profile management apps don't take advantage of it.
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.
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.
Why is it that whenever someone makes an accusation of bad behaviour from GrapeheneOS devs, they always end the posts with citations that lead to absolutely nowhere? Where, specifically in that first link as I don't consider a Louis Rossmann video a credible source, are these indications of "unresolved mental issues"?
Don't post another link or quote from anywhere else. You provided that link as evidence and I want to see specifically what it is you expect people to take from it.
Strcat gets harassed based on frivolties, manufactured outrage. There have been repeated accusations of mental health issues without any substantive evidence, including from the person I was just replying to. The evidence they do give is usually of the developer expressing frustration at dealing with those accusations, which is ironic given that those accusations are self evidently true given that the people making those posts are usually accusing them!
All I see in Rossman's video is someone frustrated by a influential person giving a platform to an organisation that, to be frank, has shown themselves to be considerably less trustworthy than GrapheneOS. I believe strcat has been the target of harassment, I believe them because I've seen it happen and given the sensitive nature of GrapheneOS I also think it's not terribly unlikely there was an organized disinfo effort.
That I've seen "This is informative and unfortunate." come up over and over again as if it were some mantra, I guess is sorta telling. People aren't thinking for themselves, they're just uncritically absorbing the opinions of the charming people they're watching on youtube.
Idk anything about this drama, but "frustrated" is generous interpretation. Dude left an comment on a YouTube video and the guy freaked out on him. Seems like exactly the type of behavior he's claiming isn't real. I just want to know the OS I'm installing on my phone isn't at the whims of anyone who could pull a "colours/faker" stunt. But hopefully the project has governance and control that no single person could that that anyways (otherwise it'd be hard to calm it's a "secure" alternative)
I don't 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 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
> GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
It really is sad that there isn't any ROM with Graphene's permission and sandboxing features while still leaving the user in control. IIRC it's theoretically possible since they publish the code, but one assumes it would be a non-trivial effort:\
As described in the README, the combination of root access and locking the bootloader has the caveat that it's easy to brick your boot partition by accidentally making changes to it. That causes the signature check to fail, and then you have to unlock the bootloader and wipe all your data to re-flash it.
I don't know if there's any good solution to this, since all this seems to be necessary for the security model.
EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other)
Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?
It also has the caveat that protecting against privileged attacker persistence doesn't work by definition, so it only provides protection against physical attacks. The protection against physical attacks is also reduced through having the keys available on a lower security device as would typically be the case.
After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
You can use most banking apps on GrapheneOS but a subset block using any alternate OS. GrapheneOS supports hardware attestation and some banking apps explicitly permit GrapheneOS via hardware attestation such as Swissquote which recently added it. Banking app compatibility on GrapheneOS is better than any other alternate OS due to some apps choosing to special case allowing it.
Google will not using their service for tap-to-pay.
My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.
I'm okay with losing access to Google wallet while using Graphene os (I can just use plain old credit cards), but I would like to have the option to revert it in the future.
Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no.
(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.
Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.
> I dint understand why you insist on this massive risk to be laid on on everyone.
Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
Use your own keys to sign and you're golden.
The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't.
I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both.
It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
And lastly, it's okay if you don't consider it a massive risk. I do.
For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
> You either build a debug image, so you just have it,
It is my understanding that that only gives root to adb, not apps, so no.
> or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
If we're at the point of patching source trees, then no, we've left the realm of "very easy" behind. Installing Magisk is easy. Building Android from source, let alone patching it, is not.
> It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
I really disagree. Knowing when to click the allow button or not is a separate skill from building/patching a ROM from source.
I'd love to, but you'll have to mention what they might be. Both of those links treat root as nearly synonymous with compromise but never bother to explain how that compromise would occur, just 1. root 2. ??? 3. malware. That's fear-mongering, not a threat model.
> I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
Or, we could avoid Appeal to Authority and talk threat models. The only one I've seen yet in this thread is people claiming that malware can fake out permission dialogs and that this is a problem for root permissions but somehow leaves the rest of Android's permission model in a usable state, which is... an interesting claim.
> Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
Many people making vague claims might technically be a "consensus" but it's not actually meaningful. If you've got an actual threat model, let's hear it, otherwise there's not much point to this.
And there's reason why normal windows / Linux laptops are less secure.
Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?
And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?)
I hope you're at least running your laptop with selinux in enforcing mode :)
> Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?
The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.
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.
Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user?
By the way, personal attacks are against the HN Guidelines.
Ah yes thats a real good faith argument you got there.
GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.
The same is true even of an operating system such as QubesOS. And it's a minimal risk.
Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.
Arguably Android has a capability-based security model, though it suffers from being ... well, it's not what you'd build if you were doing it from scratch today. Hindsight is 20/20. But I'd tentatively say not really, because the point of root is to get outside the existing capabilities. As an example: For a while, the most common root app I ran was one to limit charging to 80% or whatever to make the battery age more gracefully.[0] The whole reason that needed root is because there wasn't a capability/permission for that; the app couldn't ask the OS to let it control charging, because nobody even thought to expose that API surface.
[0] This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.
>This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.
For what it's worth, my understanding is that this has always been the position of GrapheneOS too. Given the resources and enough benefit/cost to allocate, the project would rather integrate or implement usability features at the OS level instead of encouraging people to expose attack surface. Specifically because GrapheneOS is a project meant to be primed to defend some of the most intimate and personal aspects of a person's life.
Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.
Quoting inline since parent has been rewritten multiple times now...
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think
> An accessibility service trivially has root access.
is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.
> In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.
> A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
> Android has an established way to handle permission dialogs that require the user to confirm their approval
With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
> including use of fingerprint/PIN/password to authenticate
IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
> With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
So you're using a version of Android patched to remove all permissions? After all, in your threat model all apps can get permission to use the microphone and camera, make phone calls, access fine-grained location information, read and write files at will, etc. Frankly, I'm not sure what they'd get out of root at this point.
> IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
Likewise, surely this applies to any permission system, and every other permission. The system UI controls every other permission in the system; if we assume it compromised, then everything else is already lost.
Possibly. Yes, hiding from auditing would be a possible advantage, but I think an app with accessibility permissions could already draw over the settings app to hide the real list of permissions from your view without root. Off the top of my head I think there's a whole mess of permissions needed to allow that, but we're discussing a threat model where permission dialogs can be effectively bypassed so that's no obstacle.
Giving the user control does not mean giving the user root. Giving root breaks Android security model. Whatever capability you want should be implemented as a proper feature to avoid breaking the security of the device.
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
That would be nice, but trying to get those kinds of functionality upstreamed into GOS so they can be exposed tovapps in a structured way with the usual permissions model is a high effort.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
This kind of mentality is why malware became such a big issue on Windows. It turned out ignoring security and just relying on the user to not be stupid doesn't work. That mistake shouldn't be made again and there is no reason to artificially restrict the audience of an OS to people who don't have "low IQ."
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.
No, they can be installed as regular sandboxed apps and you don't need to grant them any of the standard permissions such as Location. They have the same app sandbox and permission model as other apps including all of the GrapheneOS improvements. For example, if you want to use a Google Play feature requiring Contacts access, you can use Contact Scopes instead. However, barely any Google Play functionality needs more than the added Network permission.
Location services work perfectly fine without Google Play installed. For apps depending on Google Play and using the Google Play location API, GrapheneOS redirects the requests to the OS by default. If you want network-based location for location detection without satellite reception, you can enable the network-based location service built into GrapheneOS. The only reason to give the Location permission to Google Play would be if you want to use a feature they provide depending on it such as location sharing.
as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.
cool_cherry explained exactly how I've been using it, with my main 'owner' account not having play services installed at all, only instead installed on another user, which only takes a few seconds to switch to.
you can easily install owner apps onto other user profiles.
or grant/forbid the other user profiles to install apps themselves.
users are not tied to google accounts, only your google play installations.
I was able to install google play apps on 'owner' user and then uninstalled google play services and play store. if they don't require play services to function, they work fine, otherwise they just might not function or may function/look surprisingly differently when they don't have their network connections.
location, network, other permission have defaults and can set them on per-app basis like on normal android.
a unique device MAC address is generated for each wifi connection.
It's worth noting they're still regular sandboxed apps regardless of whether you use dedicated profiles for this. The main reason to use a separate profile for this is for fine-grained control over which apps can/will use Google Play. Apps in the same profile can see it's there and choose to use it.
For example, Signal will use Google Play services for push notifications via Firebase Cloud Messaging (FCM) when it's in the same profile. If it's not there, Signal uses their own inefficient WebSocket-based push which uses significantly more power due to lack of optimization. Molly is a fork of Signal with support for UnifiedPush as an efficient alternative to FCM.
Many apps from the Play Store don't use Play services, while many others be used with or without Play services where they may have extra functionality or different behavior when Play services is available. Others have a hard dependency on it.
There are many other ways to apps to get apps than the Play Store. For getting apps from the Play Store, there's both the sandboxed Play Store and Aurora Store as options. Play Store requires an account for installing/updating apps but it can be a throwaway one like the ones Aurora Store uses by default. Note Aurora Store does not currently check the store's signature metadata to secure the initial install better than HTTPS alone.
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.
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.
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.
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.
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.
Apps that need SafetyNet to be in a particular state won't work. I never experienced the downside, even with my smaller bank's app, it works seamlessly.
Although, keep in mind, this is subject to change. All they need to do is just introduce the requirement in an app update, and then you're screwed.
Software tamperproofing. Or, at least an attempt to it. Apps can request the info from Android: "hey, is this a legit Android system? Everything in factory condition?" and this mechanism would respond. Some apps request this in the name of security. In an attempt to ensure that the user and their data via the app are safe.
Normal, unmodified Android systems report back that they are untouched. The system detects LineageOS, /e/OS, Graphene etc as modifications though, so then it reports that the system is compromised. As an option, it can be hacked, so it reports A-OK even on a modified phone - but this hack is prone to breaking, and not the easiest to do to begin with.
It's not straightforward which apps need this thing. I found a compilation here:
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.
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.
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.
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:
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.
> 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.
Installing it on a tablet is a good idea. I hesitate to install it on my phone because I'm concerned about a few things I rely on not working (RCS, tap to pay, nearby devices to unlock rental cars)
Contactless payments via phone would only be possible if you had a banking app that provided the feature independently. Google Wallet/Google Pay does not work on OSes not certified by Google.
Curve Pay also works, as do European banks using the standard approach not dependent on Google Play. Tap-to-pay is not an issue for GrapheneOS users in the UK and EU.
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.
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.
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.
What utter nonesense. Just because the GrapheneOS Team doesn't do free work to support devices you like doesn't mean they prevent you from doing it. It's still 100% opensource and you are free to port it yourself to whatever device you please. The entitlement of people that want the grapheneos project to work for them for free is insane. Fucking hire a dev to work on this for a few month yourself if you don't like the device support.
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.
Did you pay cash? If not, you already gave them your real name and info.
> The user containers are very helpful
You mean different user accounts? Those are available on stock Android, too.
On GrapheneOS they're profiles. Pretty much the same as with the stock aosp, but they add very extensive support - like notifications forwarding and a perfect balance between security and convenience, 2FA with shorter pin.
> but they add very extensive support
Huh, I didn't realize they had added additional functionality not present on stock Android. Thanks!
It's incredibly useful! I have one profile for the "social" apps I don't trust (TikTok, Reddit, etc.). They can commingle. And there's another profile that contains the apps that rely on Google Play Services (e.g. something relies on google maps). As far as I understand it, it's like a strong firewall between them such that they are pretty close to having multiple different phones.
I understand that you have a concern, but may I ask what you mena specifically by "trust", and how would profiles help? Is it about accessing phone data or something else? As far as fingerprinting goes, I don't think profiles matter -- they already know who you are and can associate you with data from other sources.
What about settings, though? Don't you have to set up each user profile separately?
Also, what if you ever want to share a file across user profiles?
I've successfully used Material Files [1] to set a nework shared folder (I think it was FTP) on one Android profile, and accessing it ("connecting" to it) from the other. So this might also work between GrapheneOS profiles.
[1]: https://f-droid.org/packages/me.zhanghai.android.files/
Sharing files requires a bit of creativity.
You can share with file synchronisation apps like Syncthing/Ouisync [0], exploit a temporary weakness in the isolation model with Inter Profile Sharing [1], or simply copy the files over to an external storage device and transfer them that way.
[0]https://github.com/Catfriend1/syncthing-android
[0]https://github.com/equalitie/ouisync
[1]https://github.com/VentralDigital/InterProfileSharing
See: https://github.com/VentralDigital/InterProfileSharing
It also shows that profiles can't really prevent an app from correlating profiles on the same device, by listening on a local socket.
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.
I think it depends on the Android distribution. I am not sure it is available on Samsung's One UI.
Multiple user is available on Samsung. Both multiple profiles as well as work profile.
Samsung also has "secure folder" which isolates apps and files and presumably uses multiple users to do the isolation.
Secure folder is an older approach to what Android provides via the standard Private Space feature since Android 15. Private Space and work profiles are based on the same infrastructure as secondary users including per-profile encryption keys, although typically work profile management apps don't take advantage of it.
Apparently multiple user profiles is available on their tablets but not on their smartphones.
> I have to have TikTok for work
I'm sorry but what? Your job demands what apps you have installed on your PRIVATE phone!?
Well, nobody's forced it, but my company publishes content on TikTok that drives customers, and I want to be able to see it myself. You'd be surprised how many CISOs and security workers are on TikTok.
Edit: "experts" > "workers"
Tiktok.com
?
I would assume for advertising/business account. There are things you can only do on the TikTok app that you can't do on the web.
All jobs I've had since the mid 2010s essentially did the same for me by requiring 2fa in certain contexts
Suggestion for people trying GrapheneOS...
Although GrapheneOS puts a lot of work into sandboxing and protecting against Google Play, don't assume that you have to go that direction.
An alternative direction, if you wish, is to simply minimize the set of apps you use. And maybe it turns out that you don't really need anything from Google Play.
For example, I limit myself to a few open source apps (e.g., email, TOTP authenticator, maps, calendaring).
Anything else, either I don't need to do it from my phone, or I can get by with the Web site version of it in the phone's Web browser.
I also recently went through and deleted some open source apps that were a good idea to try, and which initially seemed like a good idea to keep on hand, but that I really wasn't using, and didn't expect to use without opportunity to reinstall them, so were just clutter and risk (e.g., Matrix, XMPP, Signal).
Re: not using Google Play
I'm not using GrapheneOS (I am unwilling to give Google money directly), but I did recently move to my second Android phone after having been a decade-plus iPhone user.
When I got my first Android phone I decided to "sideload" all non-stock software on the phone. I never have setup a Google Play account. I kept all the APKs for the software I loaded over the three years I used the old phone.
When I got the new phone I loaded all the software I use day-to-day and imported my SMS, contacts, and call logs using a nice FOSS app[0]. It felt remarkably like moving to a new PC does. It was nice.
You definitely don't need Google Play to get a lot of functionality. I have run into a number of apps that I can't get to "sideload" (basically any xapk-packaged apps) but I don't need any of the badly enough to care.
I am really sad Google is ending this moving forward. Jackasses.
[0] https://github.com/tmo1/sms-ie
Why stop there when you can just not have a phone at all?
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.
The only reason I ditched GrapheneOS is because it doesn’t support automatic call recording. Sure, you can hit the record button every time you pick up, but who remembers to do that? Plenty of people have asked for this feature on GitHub [0], and the way the lead developer responds makes it look like there are some serious unresolved mental issues at play. Then I watched Louis Rossmann’s video [1] about him, and that sealed it. I refuse to touch Graphene OS with a 20 foot pole.
0. https://web.archive.org/web/20250123135603/https://github.co... 1. https://www.youtube.com/watch?v=Dl1x1Dy-ej4
Why is it that whenever someone makes an accusation of bad behaviour from GrapeheneOS devs, they always end the posts with citations that lead to absolutely nowhere? Where, specifically in that first link as I don't consider a Louis Rossmann video a credible source, are these indications of "unresolved mental issues"?
Don't post another link or quote from anywhere else. You provided that link as evidence and I want to see specifically what it is you expect people to take from it.
Do you think Louiss fabricated that chat he was showing in realtime? Seemed pretty unhinged to me...
Strcat gets harassed based on frivolties, manufactured outrage. There have been repeated accusations of mental health issues without any substantive evidence, including from the person I was just replying to. The evidence they do give is usually of the developer expressing frustration at dealing with those accusations, which is ironic given that those accusations are self evidently true given that the people making those posts are usually accusing them!
All I see in Rossman's video is someone frustrated by a influential person giving a platform to an organisation that, to be frank, has shown themselves to be considerably less trustworthy than GrapheneOS. I believe strcat has been the target of harassment, I believe them because I've seen it happen and given the sensitive nature of GrapheneOS I also think it's not terribly unlikely there was an organized disinfo effort.
That I've seen "This is informative and unfortunate." come up over and over again as if it were some mantra, I guess is sorta telling. People aren't thinking for themselves, they're just uncritically absorbing the opinions of the charming people they're watching on youtube.
Idk anything about this drama, but "frustrated" is generous interpretation. Dude left an comment on a YouTube video and the guy freaked out on him. Seems like exactly the type of behavior he's claiming isn't real. I just want to know the OS I'm installing on my phone isn't at the whims of anyone who could pull a "colours/faker" stunt. But hopefully the project has governance and control that no single person could that that anyways (otherwise it'd be hard to calm it's a "secure" alternative)
This is informative, and unfortunate
I don't use call recording and also don't care about some guy I've never heard of ranting for 18min about some pointless comment he made on youtube causing drama (but I do care about NFC payments so that's why I haven't tried GrapheneOS yet).
From what I can tell sounds like this guy's stepped away from the project? Curious what the latest status is.
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
> GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
It really is sad that there isn't any ROM with Graphene's permission and sandboxing features while still leaving the user in control. IIRC it's theoretically possible since they publish the code, but one assumes it would be a non-trivial effort:\
You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting.
See: github.com/chenxiaolong/avbroot
As described in the README, the combination of root access and locking the bootloader has the caveat that it's easy to brick your boot partition by accidentally making changes to it. That causes the signature check to fail, and then you have to unlock the bootloader and wipe all your data to re-flash it.
I don't know if there's any good solution to this, since all this seems to be necessary for the security model.
EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other) Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?
It also has the caveat that protecting against privileged attacker persistence doesn't work by definition, so it only provides protection against physical attacks. The protection against physical attacks is also reduced through having the keys available on a lower security device as would typically be the case.
After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?
You can use most banking apps on GrapheneOS but a subset block using any alternate OS. GrapheneOS supports hardware attestation and some banking apps explicitly permit GrapheneOS via hardware attestation such as Swissquote which recently added it. Banking app compatibility on GrapheneOS is better than any other alternate OS due to some apps choosing to special case allowing it.
Google will not using their service for tap-to-pay.
My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.
I'm okay with losing access to Google wallet while using Graphene os (I can just use plain old credit cards), but I would like to have the option to revert it in the future.
Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader.
Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no.
(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)
Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.
it'd be really nice to exert pressure on GPay or at least banking apps to add GOS's keys. accepting only Google's keys is anticompetitive.
Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
I dint understand why you insist on this massive risk to be laid on on everyone.
GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user.
> GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.
It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated.
> I dint understand why you insist on this massive risk to be laid on on everyone.
Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
No, it is very easy.
You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
Use your own keys to sign and you're golden.
The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't.
I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both.
It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
And lastly, it's okay if you don't consider it a massive risk. I do.
Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...
For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
> You either build a debug image, so you just have it,
It is my understanding that that only gives root to adb, not apps, so no.
> or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it.
If we're at the point of patching source trees, then no, we've left the realm of "very easy" behind. Installing Magisk is easy. Building Android from source, let alone patching it, is not.
> It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it.
I really disagree. Knowing when to click the allow button or not is a separate skill from building/patching a ROM from source.
> Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-prote...
I'd love to, but you'll have to mention what they might be. Both of those links treat root as nearly synonymous with compromise but never bother to explain how that compromise would occur, just 1. root 2. ??? 3. malware. That's fear-mongering, not a threat model.
> I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle.
Or, we could avoid Appeal to Authority and talk threat models. The only one I've seen yet in this thread is people claiming that malware can fake out permission dialogs and that this is a problem for root permissions but somehow leaves the rest of Android's permission model in a usable state, which is... an interesting claim.
> Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.
Many people making vague claims might technically be a "consensus" but it's not actually meaningful. If you've got an actual threat model, let's hear it, otherwise there's not much point to this.
If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
Pssst, quiet, don't give them any ideas... :-/
And there's reason why normal windows / Linux laptops are less secure.
Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?
And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?)
I hope you're at least running your laptop with selinux in enforcing mode :)
> Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it?
The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
I'm willing to take the very slight chance of getting compromised in exchange for getting things done.
From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
Android of course requires root for installing and configuring applications. It just grants the root automatically.
No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
Developers cannot trust a random phone «owner».
Have a look at https://qubes-os.org to understand why you're mistaken.
I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.
That's a Chromebook, no?
Chromebooks have Developer Mode that gives full root.
https://www.chromium.org/chromium-os/developer-library/guide...
[dead]
They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.
> That will give you adb root access.
I don't want adb root access? I want to be able to run apps with root access.
> massive risk
Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
Non sequitur?
GOS is not running a flavour of mainline Linux, but Android. They're nevertheless planning on moving to virtualisation as well https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-r...
For now it's as good as it gets.
Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user?
By the way, personal attacks are against the HN Guidelines.
Ah yes thats a real good faith argument you got there.
GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed.
The same is true even of an operating system such as QubesOS. And it's a minimal risk.
Not providing optional root access on GOS makes it only useful if you have a constrained application in mind for the phone. I don't have time to compile GOS with root so I just use LineageOS instead.
It's useful for general use just fine.
But you could always do both. Compile it, but preinstall a specific set of apps as root, no su.
EDIT: This is a reply to the 2nd(?) version of your comment before it was silently changed into something different.
Yes, I'm sure it is. But I don't consider that a tolerable tradeoff, and I believe we could have a system that has most of the best of both worlds.
>This is not what people are referring to when they talk about rooting on Android
Would this have been easier or more possible if Android had a full capability-based security model?
Arguably Android has a capability-based security model, though it suffers from being ... well, it's not what you'd build if you were doing it from scratch today. Hindsight is 20/20. But I'd tentatively say not really, because the point of root is to get outside the existing capabilities. As an example: For a while, the most common root app I ran was one to limit charging to 80% or whatever to make the battery age more gracefully.[0] The whole reason that needed root is because there wasn't a capability/permission for that; the app couldn't ask the OS to let it control charging, because nobody even thought to expose that API surface.
[0] This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.
>This was later obsoleted by the OS adding that feature natively, which is an interesting angle to consider; directly supporting the things people root for definitely helps, but you're unlikely to ever get everything so it's not a panacea.
For what it's worth, my understanding is that this has always been the position of GrapheneOS too. Given the resources and enough benefit/cost to allocate, the project would rather integrate or implement usability features at the OS level instead of encouraging people to expose attack surface. Specifically because GrapheneOS is a project meant to be primed to defend some of the most intimate and personal aspects of a person's life.
Yeah, I definitely think it's an excellent goal to erode the cases that need root. It is a powerful escape hatch, and I think it's important that it exist, but it's also a good thing to not need it. The difference is that I don't believe the system will ever cover everything I want to do, so I consider that escape hatch to be really important.
Quoting inline since parent has been rewritten multiple times now...
> If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.
Android has an established way to handle permission dialogs that require the user to confirm their approval, including use of fingerprint/PIN/password to authenticate. If it's good enough to unlock and decrypt the device, it's good enough to control root access. Besides which, I think
> An accessibility service trivially has root access.
is hitting https://xkcd.com/1200/ ; an a11y service already has access to everything inside the sandbox (including all your sensitive data), and the system settings that control permissions and sandboxing.
> In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.
I'm tentatively willing to agree, but I don't see the point? 1. If an attacker controls persistent state, don't they already control all the other permissions, including what security domains exist and what permissions are given to apps. 2. You don't have to persist it; even just one-off root access is quite useful.
> A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.
Agreed, that's not what I want.
> Android has an established way to handle permission dialogs that require the user to confirm their approval
With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
> including use of fingerprint/PIN/password to authenticate
IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
> With the advent of choicejacking I don't think I want to trust permission dialogs anymore.
So you're using a version of Android patched to remove all permissions? After all, in your threat model all apps can get permission to use the microphone and camera, make phone calls, access fine-grained location information, read and write files at will, etc. Frankly, I'm not sure what they'd get out of root at this point.
> IMO if you have the UI layer able to grant root access at all, even with requiring re-authentication, it still already has root access itself and is therefore not sandboxed.
Likewise, surely this applies to any permission system, and every other permission. The system UI controls every other permission in the system; if we assume it compromised, then everything else is already lost.
> Frankly, I'm not sure what they'd get out of root at this point.
A permission that allows them to hide that they have access to everything, including other apps' data?
Possibly. Yes, hiding from auditing would be a possible advantage, but I think an app with accessibility permissions could already draw over the settings app to hide the real list of permissions from your view without root. Off the top of my head I think there's a whole mess of permissions needed to allow that, but we're discussing a threat model where permission dialogs can be effectively bypassed so that's no obstacle.
Giving the user control does not mean giving the user root. Giving root breaks Android security model. Whatever capability you want should be implemented as a proper feature to avoid breaking the security of the device.
Equating control to root is an outdated way of thinking that comes from a time before the principle of least privilege existed. The way UNIX did things should not be put on a pedestal.
That would be nice, but trying to get those kinds of functionality upstreamed into GOS so they can be exposed tovapps in a structured way with the usual permissions model is a high effort.
There needs to be some escape hatch that you can use, even if your grandma doesn't have access to it.
There doesn't need to be an easy escape hatch. The escape hatch is to wipe and flash a fork.
Then you lose all your data. You could also install a more traditional Linux phone OS too.
The point is that you should always be some supported workflow instead of the user having to go out of their way and modifying the base system.
> Giving root breaks Android security model.
It's true only if user is the threat for the user, e.g. a user with low IQ but high curiosity, but such user usually cannot install GrapheneOS.
This kind of mentality is why malware became such a big issue on Windows. It turned out ignoring security and just relying on the user to not be stupid doesn't work. That mistake shouldn't be made again and there is no reason to artificially restrict the audience of an OS to people who don't have "low IQ."
Sincere question: what is the point of using this OS for privacy and then using Google services? The intro runs though how it’s very easy to do this. Maybe I’m missing something.
It's actually really great!
Google Play Services is a dependency for some apps, and GrapheneOS allows for people to take steps to protect their privacy while still being able to use those apps.
First, with GrapheneOS google play services run in a sandbox like any other app. (play services have more privileged access in vanilla android)
It also works well with a multi-user setup. The default account in Android is the "owner account" and in GrapheneOS (and AOSP) you can use the owner account to create multiple distinct user accounts on the device. Then, you can only install google play services in one user account. Google play services won't start if you're not logged into that user account.
Google play services won't have visibility into your other user accounts and what you're doing there. And even in your account with play services installed, there's a bit more privacy because of the sandboxing (although I believe google play will know all of the apps installed in that user account)
There's a full explanation here: https://grapheneos.org/usage#sandboxed-google-play
Edit: I am a web security researcher and longtime user of GrapheneOS and have always been impressed by the features, frequent security updates, and focus on usability, security, and privacy. They've upstreamed numerous security improvements to Android and other open source projects (so if you're running Android, they've probably made your phone more secure!).
https://grapheneos.org/faq#upstream
I encourage folks to join me in making a regular small donation to the project if you have some cash to spare. They're doing good work.
https://grapheneos.org/donate
Why is this in any way superior to microg, apart from compatibility? Microg simply spoofs/shims the API while not actually contacting Google servers at all.
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.
Afaik, Google services are run in a sandbox on Graphene OS.
Hm ok but location data etc still goes to them? What about the device fingerprint?
I’m just wondering what the selling point for using Graphene with Google is. Very Graphene curious.
> but location data etc still goes to them
No, they can be installed as regular sandboxed apps and you don't need to grant them any of the standard permissions such as Location. They have the same app sandbox and permission model as other apps including all of the GrapheneOS improvements. For example, if you want to use a Google Play feature requiring Contacts access, you can use Contact Scopes instead. However, barely any Google Play functionality needs more than the added Network permission.
Location services work perfectly fine without Google Play installed. For apps depending on Google Play and using the Google Play location API, GrapheneOS redirects the requests to the OS by default. If you want network-based location for location detection without satellite reception, you can enable the network-based location service built into GrapheneOS. The only reason to give the Location permission to Google Play would be if you want to use a feature they provide depending on it such as location sharing.
as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.
cool_cherry explained exactly how I've been using it, with my main 'owner' account not having play services installed at all, only instead installed on another user, which only takes a few seconds to switch to.
you can easily install owner apps onto other user profiles. or grant/forbid the other user profiles to install apps themselves.
users are not tied to google accounts, only your google play installations.
I was able to install google play apps on 'owner' user and then uninstalled google play services and play store. if they don't require play services to function, they work fine, otherwise they just might not function or may function/look surprisingly differently when they don't have their network connections.
location, network, other permission have defaults and can set them on per-app basis like on normal android.
a unique device MAC address is generated for each wifi connection.
It's worth noting they're still regular sandboxed apps regardless of whether you use dedicated profiles for this. The main reason to use a separate profile for this is for fine-grained control over which apps can/will use Google Play. Apps in the same profile can see it's there and choose to use it.
For example, Signal will use Google Play services for push notifications via Firebase Cloud Messaging (FCM) when it's in the same profile. If it's not there, Signal uses their own inefficient WebSocket-based push which uses significantly more power due to lack of optimization. Molly is a fork of Signal with support for UnifiedPush as an efficient alternative to FCM.
Many apps from the Play Store don't use Play services, while many others be used with or without Play services where they may have extra functionality or different behavior when Play services is available. Others have a hard dependency on it.
There are many other ways to apps to get apps than the Play Store. For getting apps from the Play Store, there's both the sandboxed Play Store and Aurora Store as options. Play Store requires an account for installing/updating apps but it can be a throwaway one like the ones Aurora Store uses by default. Note Aurora Store does not currently check the store's signature metadata to secure the initial install better than HTTPS alone.
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.
I've seen several complaints here about how GOS does "user profiles", specifically complaining they make the UX too poor. There is a weaker form of user profiles called "work profiles" that one can use to have separation between apps but in a more user-friendly way.
The recommended app is "Shelter". https://f-droid.org/en/packages/net.typeblog.shelter/
Private Spaces are available since Android 15 and provides a similar nested profile without the need for a management app. They're better integrated into the OS user interface.
Secondary users, work profiles and Private Spaces are standard Android features but GrapheneOS does provide improvements to secondary users and Private Spaces such as control over clipboard sharing with a Private Space, enabling having a Private Space for each secondary user, cross-user notification forwarding, etc. https://grapheneos.org/features has a good overview of most (not all) GrapheneOS features.
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.
There did not seem to be an RCS story. Whether the device is RCS capable or not seems to be up to some unfathomable Google logic the tickling of which didn't work for me. Having old RCS chat histories and new RCS chats not work made me go back to stock quick.
Official support for Google Messages on GrapheneOS is being developed instead of needing to set it up in a very particular way where it can be fragile. In the long term, we plan to make our own RCS app.
you need the google messaging app for RCS
Is it because no one else has tried implementing the RCS standard or because Google has some proprietary hold over it?
No one else has tried implementing the RCS standard.
There just aren't any open-source Android libraries for RCS out there, much less anything in AOSP.
https://github.com/search?q=rcs+android&type=repositories
Apple has RCS, compatible with Android, at least in the EU. You don't get the blue bubble though.
I think they’re asking about on Android. The point is whether there’s an alternative RCS client to run on GOS.
Which itself is not guaranteed to work even on ”stock” Android, let alone GOS — which multiple people (myself included) have been experiencing firsthand.
RCS is an abomination.
There has to be a better open source mobile OS out there.
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.
Do bank apps work with GrapheneOS?
In my country most of them do. It depends on the bank and their application. https://privsec.dev/posts/android/banking-applications-compa... offers a possibility to check which apps may work fine.
Apps that need SafetyNet to be in a particular state won't work. I never experienced the downside, even with my smaller bank's app, it works seamlessly.
Although, keep in mind, this is subject to change. All they need to do is just introduce the requirement in an app update, and then you're screwed.
What is SafetyNet?
Software tamperproofing. Or, at least an attempt to it. Apps can request the info from Android: "hey, is this a legit Android system? Everything in factory condition?" and this mechanism would respond. Some apps request this in the name of security. In an attempt to ensure that the user and their data via the app are safe.
Normal, unmodified Android systems report back that they are untouched. The system detects LineageOS, /e/OS, Graphene etc as modifications though, so then it reports that the system is compromised. As an option, it can be hacked, so it reports A-OK even on a modified phone - but this hack is prone to breaking, and not the easiest to do to begin with.
It's not straightforward which apps need this thing. I found a compilation here:
https://xdaforums.com/t/apps-games-need-pi-list.4677050/
But the list has YouTube, and I can report that I'm happily using that for years on a phone without this mechanism, so, I cannot vouch for this list.
I ran Graphene for several months and hated every minute of it. It's incredibly and unjustifiably inflexible and treats the user like they're the primary security threat.
Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
I found the profile feature to be only slightly more convenient than having two physical devices. I could not find any real use for it. I thought I'd set up a work profile to attach to my work gsuite account. Nope, unsupported. I can't attach my work google account at all. Maybe I can just put all my google play dependent apps in a profile? Sure, but to get to them is just about as convenient as rebooting the phone from cold. And notifications are not forwarded to other profiles. If an event happens in another profile, you get a notification that there is a notification. You still have to drop everything to reboot into the other profile to check that you got an emote reaction to your Discord message. Great use of my time.
The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices.
I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
> Sure, but to get to them is just about as convenient as rebooting the phone from cold.
This just isn't true. Switching profiles is nothing like rebooting the phone. It takes about 8 seconds to go thru the entire procedure. That's including about 3 seconds to load the 2nd profile (even an unloaded profile). The procedure on my Pixel 7 goes:
- Swipe down to open the Notification Panel
- Swipe down again to expand the Quick Settings
- Tap the User icon at the bottom
- Select the user profile you want to open
- Wait 3 seconds
- Enter the 2nd user's PIN to log in
That's 4 taps + 3 seconds of load time.
It's important to note that user profiles are a standard Android feature, as are Private Space and work profiles nested within the Owner user. None of the core privacy and security features of GrapheneOS require using user profiles. We make certain enhancements to user profiles and Private Space. For user profiles, that's mainly allowing making more users, using more standard functionality (end session, more toggles to control access) and notification forwarding. For Private Space, we enable using them in secondary users and provide the important improvement of controlling clipboard sharing with the parent profile. Those profile improvements are a very tiny portion of what GrapheneOS provides. There's a common misconception that sandboxed Google Play requires profiles but that's not the case and they're regular sandboxed apps when installed in the Owner user too.
Huh? To me, Graphene just feels like unbloated Android with a few convenient ways of customizing google stuff and that's it. I like that it actually gets out of my way and I don't really understand how it "coddles" you.
> Sure it's cool you can turn off google play
Google Play and associated services are not bundled with GrapheneOS, they are completely optional.
> I found the profile feature to be only slightly more convenient than having two physical devices.
User Profiles is a feature inherited from AOSP. This is what AOSP says about the feature: "Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty."
In the community it is popular to use multiple profiles to compartmentalise personas or group apps with hard google service dependencies together, but this is all completely optional. GrapheneOS as a project gently suggest keeping everything in the same initial owner profile and then moving things around to suit your comfort level.
> It's my device, not google's, and certainly not Graphene's.
You've clearly endured a lot of frustration when using the OS. Are there any specific things you remember trying to do that were blocked or prevented by GrapheneOS? It's not a project with unlimited resources, but actionable information about limitations and bugs can potentially be addressed if known.
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.
You might prefer /e/OS: It's another de-googled Android variant but in contrast to Graphene the focus is on privacy and everyday usability. They aren't trying to produce an OS hardened against nation-state attackers, just one that doesn't routinely leak all your data to advertisers.
GrapheneOS provides much better privacy, stability and app compatibility than /e/ rather than only security. GrapheneOS entirely exists as a privacy project and focuses on security too in order to protect privacy. GrapheneOS is a privacy project aimed at being highly usability. There's a good third party comparison between them here:
https://eylenburg.github.io/android_comparison.htm
/e/ regularly lags many weeks and months behind on essentially privacy and security patches for Android, the browser engine used by many apps, the Linux kernel, drivers and firmware. It doesn't preserve the standard Android privacy and security model either. It isn't safe from a privacy or security perspective for those reasons. It doesn't take a nation state attacker to exploit not having patches for many known browser/OS privacy and security vulnerabilities.
Despite the misleading marketing, /e/ always uses multiple Google services and integrates them into the OS with privileged access unavailable to other services. They automatically download and run Google code with privileged access along with giving privileged access to certain Google apps when they're installed including Android Auto.
Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches:
https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nich...
Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service:
https://community.e.foundation/t/voice-to-text-feature-using...
Information from the founder of the Divested projects:
Issues with /e/: https://codeberg.org/divested-mobile/divestos-website/raw/co... ASB update history: https://web.archive.org/web/20241231003546/https://divestos.... Chromium update history: https://web.archive.org/web/20250119212018/https://divestos.... Chromium update summary: https://infosec.exchange/@divested/112815308307602739
As an alternative to running something like GrapheneOS to limit intrusive proprietary apps you can disable such apps and only enable them when required for some reason, then disable them again. To do so you'll want a rooted device, Termux and Termux:Widget for easy access to the enabling/disabling scripts. Here's an example of such a script, this one can be used to enable or disable Google services:
The script is stored in ~/.shortcuts/Name_of_package:enable and hardlinked to ~/.shortcuts/Name_of_package:disable. Its action depends on by which name it is called. The scripts can be started through a Termux widget from the launcher.Notice that the script can enable/disable multiple packages by adding package names to the $PACKAGES variable.
I enable and disable things like Google Services manually but the scheme can be extended as much as you wish, eg. by creating spin lock files to indicate whether a specific package is needed as a dependency for another package. This is left as an exercise for the reader.
> 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.
Bought an Google Pixel Tablet only for GOS. Installation worked like a charm and all my applications are still working without problems.
Loving it.
Installing it on a tablet is a good idea. I hesitate to install it on my phone because I'm concerned about a few things I rely on not working (RCS, tap to pay, nearby devices to unlock rental cars)
Contactless payments via phone would only be possible if you had a banking app that provided the feature independently. Google Wallet/Google Pay does not work on OSes not certified by Google.
Paypal tap-to-pay works according to reports.
Curve Pay also works, as do European banks using the standard approach not dependent on Google Play. Tap-to-pay is not an issue for GrapheneOS users in the UK and EU.
Great idea! I have wanted to experiment with GrapheneOS but didn’t want it to use it for banking or calls.
GrapheneOS developers keep insisting [0] that their security model is the only reasonably secure approach in the world, despite that Qubes OS proved that wrong.
https://news.ycombinator.com/item?id=45101400
>their security model is the only reasonably secure approach in the world
They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems.
QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.
See the response at https://news.ycombinator.com/item?id=45244398.
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.
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.
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.
See the response at https://news.ycombinator.com/item?id=45244398.
Your link does not support the text in your comment.
See the response at https://news.ycombinator.com/item?id=45244398.
What utter nonesense. Just because the GrapheneOS Team doesn't do free work to support devices you like doesn't mean they prevent you from doing it. It's still 100% opensource and you are free to port it yourself to whatever device you please. The entitlement of people that want the grapheneos project to work for them for free is insane. Fucking hire a dev to work on this for a few month yourself if you don't like the device support.
See the response at https://news.ycombinator.com/item?id=45244398.
[dead]