Remix.run Logo
estimator7292 2 days ago

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.

depingus 2 days ago | parent | next [-]

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

strcat 2 days ago | parent [-]

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.

zevon 2 days ago | parent | prev | next [-]

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.

ysnp 2 days ago | parent | prev | next [-]

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

hagbard_c 2 days ago | parent | prev | next [-]

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.

strcat a day ago | parent | next [-]

They're describing a bad experience with heavily using Android's user profiles for compartmentalization, not GrapheneOS. An incredibly tiny portion of what GrapheneOS provides has to do with user profiles. GrapheneOS does not restrict/limit users in the way they're describing. They're attributing a very niche way they chose to set up and use the device to GrapheneOS when it's not tied to it. See https://news.ycombinator.com/item?id=45244497.

Disabling Google Play apps as you're describing will heavily break other apps and will cause lots of issues. It will not reduce what they can do or access. It's not an alternative to the privacy or security features provided by GrapheneOS. What the person above is describing has little to do with GrapheneOS specifically and doesn't make sense as an approach to using it.

Recommend reading https://grapheneos.org/features and looking at https://eylenburg.github.io/android_comparison.htm for an understanding of what GrapheneOS provides.

depingus 2 days ago | parent | prev [-]

An alternative (and possibly easier) way that doesn't require root is to use Hail + Shizuku.

Shizuku helps normal apps to use system APIs without root. You can enable it with from a computer with adb or from the phone itself using wireless debugging. Hail uses Shizuku's API access and lets you select apps to freeze. You can then unfreeze / refreeze apps with a quick tap in Hail.

If you already have root, all this becomes easier. If you do the wireless debugging method, Shizuku's API access won't survive a reboot. You'll have to go thru the wireless debugging procedure again before you can use Hail. https://shizuku.rikka.app/guide/setup/

strcat a day ago | parent [-]

This all has little to do with the privacy and security features provided by GrapheneOS. See https://news.ycombinator.com/item?id=45244497 in response to the original post with complaints about Android user profiles, which are not a GrapheneOS feature. Nearly the entirety of the GrapheneOS added features can be used without ever making/using a secondary user. It's not required by sandboxed Google Play at all. Secondary users are useful but not a feature added by GrapheneOS.

depingus a day ago | parent [-]

That's true and I agree. I was responding to the comment about using termux to disable apps.

ForHackernews 2 days ago | parent | prev | next [-]

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.

strcat 2 days ago | parent [-]

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

ForHackernews 2 days ago | parent [-]

OP has found Graphene to be unusable and my experience has been similar. In contrast, I find /e/OS to be friendly and approachable as a daily driver. To be honest, I don't care if it's a few weeks behind on ASOP patches, it's still far better than the average OEM Android distribution.

A lot of the rest of this post reads as hostile FUD: /e/OS ships with microg (https://en.wikipedia.org/wiki/MicroG) that provides FLOSS reimplementations for some Google services - users can optionally choose to log in with their Google account. Providing this choice out of the box is controversial for people who want a complete and total break from Google.

strcat a day ago | parent [-]

> OP has found Graphene to be unusable

No, they're describing heavily using user profiles as not being usable. User profiles are a standard Android feature. GrapheneOS provides small improvements for user profiles as a tiny part of what we do. Using user profiles is in no way required to benefit from what GrapheneOS offers. They're describing a specific way they chose to use the device that's not GrapheneOS related as not being usable. What does any of what they said about user profiles being inconvenient and painful to heavily use for isolating groups of apps have to do with GrapheneOS specifically?

> my experience has been similar

Your reply shows you lack experience with GrapheneOS.

> In contrast, I find /e/OS to be friendly and approachable as a daily driver.

This is the direct opposite of nearly everyone's experience who has tried both, which you do not appear to have done.

> To be honest, I don't care if it's a few weeks behind on ASOP patches, it's still far better than the average OEM Android distribution.

/e/ lags many months and even years behind on privacy and security patches, not a few weeks. The amount it's behind depends on the device. On the Pixel 7, they're multiple years behind on kernel, driver and firmware security patches.

> A lot of the rest of this post reads as hostile FUD

No, it's your inaccurate claims about GrapheneOS privacy and usability which are accurately described that way. Everything in my posts about /e/ here is accurate and verifiable information. People should check the third party sources I linked and do research on it.

> /e/OS ships with microg

Our sandboxed Google Play compatibility layer is also open source. Both microG and sandboxed Google Play exist to provide compatibility with closed source code running on the device. microG receives substantial privileged access and the closed source code which it downloads/runs as part of itself and which runs in the apps using it has much more access to your data than it does on GrapheneOS. The Google services themselves don't become any more open source and neither do the Google Play libraries within apps, which often don't require Play services to function.

> users can optionally choose to log in with their Google account

GrapheneOS has no Google services built in and installing/using sandboxed Google Play does not require an account.

> Providing this choice out of the box is controversial for people who want a complete and total break from Google.

GrapheneOS provides the option to use Google apps and apps depending on them but doesn't bake in privileged Google services to the OS which are always enabled like /e/. On /e/, there's no way to avoid connecting to multiple Google services or to avoid how they're baked in with privileged access. A subset of these are covered in https://eylenburg.github.io/android_comparison.htm but not the ones added by /e/, only the ones present in AOSP which are not replaced by it.

ForHackernews a day ago | parent | next [-]

FYI https://community.e.foundation/t/e-os-and-security-updates/7...

(I googled this, cannot attest to the accuracy of these rebuttals)

strcat 10 hours ago | parent [-]

This post ignored the vast majority of what was said and gave very inaccurate and misleading responses to the rest. There are even many responses in their own forum to that post and others debunking the claims. Beyond the privacy and security issues, it helps demonstrates that Murena and /e/ are not trustworthy due to covering up severe privacy and security vulnerabilities on a consistent basis.

ForHackernews a day ago | parent | prev [-]

> Our

You are a partisan. I'm sure all your points are correct in some narrow technical sense, but I agree with OP: Graphene is an OS for geeks who want to geek out about security, not for normal people who want to use a smartphone without surrendering all their digital privacy.

Independent researchers have confirmed that /e/OS leaks very little data, and that's good enough for me https://www.tcd.ie/news_events/articles/study-reveals-scale-...

If you're a security nerd, live in an authoritarian state, or you're a targeted activist, Graphene is a better choice – although, really, you should be using a burner phone or staying offline.

strcat 9 hours ago | parent [-]

> You are a partisan.

I provided accurate and verifiable information. You are yourself clearly here to promote /e/ and attack GrapheneOS, which you're doing with objectively false claims about both.

/e/ has far lower app compatibility and stability. It lags many months and years behind on critical privacy and security patches. Their services were down for many months recently. It has major issues with stability and functionality across devices. Those are facts.

People can verify that what I've said is accurate along with looking at the third party sources from actual experts, contrary to the phony inaccurate study from 2021 done in coordination with /e/ that you've provided.

> I'm sure all your points are correct in some narrow technical sense

They're all accurate and not only in a narrow sense.

> Graphene is an OS for geeks who want to geek out about security, not for normal people who want to use a smartphone without surrendering all their digital privacy.

GrapheneOS objectively provides far better app compatibility and stability than /e/. It's far better tested and provides the current generation Android functionality and usability rather than being based on old versions.

> Independent researchers have confirmed that /e/OS leaks very little data

The paper doesn't claim any such thing and /e/ has added multiple kinds of invasive telemetry and services since 2021. You should check the much more up-to-date and better researched information from Mike Kuketz and Divested. Your claim that they're independent researchers is unsubstantiated and contradicted by information which has come out about the motivations and methodology behind what they published. /e/ was involved in it.

> If you're a security nerd, live in an authoritarian state, or you're a targeted activist, Graphene is a better choice – although, really, you should be using a burner phone or staying offline.

/e/ isn't safe to use due to lack of current privacy and security patches. It should be avoided by anyone who cares the slightest about privacy or security. Going years without receiving important patches for serious privacy and security issues is a severe problem.

Contrary to what you're claiming, GrapheneOS provides much better app compatibility and stability.

Murena's services were recently down from early October 2024 through March 2025, for an idea of what people can expect from the OS and services:

https://community.e.foundation/t/service-outage-announcement...

ReluctantLaser 2 days ago | parent | prev | next [-]

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.

strcat 2 days ago | parent [-]

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.

strcat 2 days ago | parent | prev | next [-]

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

lawn 2 days ago | parent | prev | next [-]

I have the exact opposite experience.

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

hydraraptor81 a day ago | parent | prev [-]

[dead]