19 ms·

Introduction to GrapheneOS

236 points by renehsz 1y ago

yjftsjthsd-h 1y ago
> 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:\
- ranger_danger 1y ago
  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.
  - yjftsjthsd-h 1y ago
    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.
  - cakealert 1y ago
    > 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.
    - b112 1y ago
      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.
  - yjftsjthsd-h 1y ago
    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/ 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.
    - ranger_danger 1y ago
      > 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.
  - ysnp 1y ago
    >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?
    - yjftsjthsd-h 1y ago
      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.
      - ysnp 1y ago
        >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.
        yjftsjthsd-h 1y ago
        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.
- subscribed 1y ago
  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.
  - jampekka 1y ago
    If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
    - bornfreddy 1y ago
      Pssst, quiet, don't give them any ideas... :-/
    - paulhart 1y ago
      That's a Chromebook, no?
      - jampekka 1y ago
        Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guides/device/developer-mode/ https://www.chromium.org/chromium-os/developer-library/guide...
    - ajjahs 1y ago
      [dead]
    - codethief 1y ago
      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.
- crapple8430 1y ago
  You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting. See: github.com/chenxiaolong/avbroot
  - tarruda 1y ago
    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?
    - chuckadams 1y ago
      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)
      - strcat 1y ago
        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.
      - sterlind 1y ago
        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.
        strcat 1y ago
        Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu....
- charcircuit 1y ago
  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.
  - oneshtein 1y ago
    > 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.
    - charcircuit 1y ago
      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."
      - oneshtein 1y ago
        So, your proposition is to remove their ability to install antivirus software, like Google does in Android? Users know about this problem and know how to mitigate it. Get out of my way, please.
        Scrubbed4426 1y ago
        No, the goal is to move to a system that doesn't rely on badness enumeration (antivirus) as a primary defense. You can rely on the app sandbox and the security model of the system to keep it in check. Antivirus scanners are essentially useless on modern mobile OSes because they are limited to accessing the same things a malicious app or file would be.
fsflover 1y ago
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 https://news.ycombinator.com/item?id=45101400
- ajjahs 1y ago
  [dead]
- ysnp 1y ago
  >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.
  - strcat 1y ago
    See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
  - fsflover 1y ago
    >> their security model is the only reasonably secure approach in the world >They have not said anything like that. Quote (https://news.ycombinator.com/item?id=30769666 https://news.ycombinator.com/item?id=30769666): > Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required. The reality is that Librem 5 is secure according to a different threat model than the one GrapheneOS follows. This doesn't make it "incredibly" insecure, unless you believe that only you can define good threat models.
electric_muse 1y ago
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.
- codethief 1y ago
  > The user containers are very helpful You mean different user accounts? Those are available on stock Android, too.
  - a0sud0a8s 1y ago
    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.
  - ysnp 1y ago
    I think it depends on the Android distribution. I am not sure it is available on Samsung's One UI.
    - gertop 1y ago
      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.
      - ysnp 1y ago
        Apparently multiple user profiles is available on their tablets but not on their smartphones.
NoiseBert69 1y ago
Bought an Google Pixel Tablet only for GOS. Installation worked like a charm and all my applications are still working without problems. Loving it.
- TranquilMarmot 1y ago
  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)
  - ysnp 1y ago
    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.
    - NoiseBert69 1y ago
      Paypal tap-to-pay works according to reports.
      - strcat 1y ago
        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.
    - TranquilMarmot 1y ago
      My main use of Google Wallet is to pay for the bus where I live, but we do have physical cards that I can also get. I do use it at the store sometimes but I also always have my physical wallet on me, so that's not a big deal.
- mark_l_watson 1y ago
  Great idea! I have wanted to experiment with GrapheneOS but didn’t want it to use it for banking or calls.
junkblocker 1y ago
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.
- throawayonthe 1y ago
  you need the google messaging app for RCS
  - goda90 1y ago
    Is it because no one else has tried implementing the RCS standard or because Google has some proprietary hold over it?
    - cpa 1y ago
      Apple has RCS, compatible with Android, at least in the EU. You don't get the blue bubble though.
      - Klonoar 1y ago
        I think they’re asking about on Android. The point is whether there’s an alternative RCS client to run on GOS.
    - alethic 1y ago
      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 https://github.com/search?q=rcs+android&type=repositories
  - yellowapple 1y ago
    Which itself is not guaranteed to work even on ”stock” Android, let alone GOS — which multiple people (myself included) have been experiencing firsthand.
tietjens 1y ago
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.
- krior 1y ago
  Afaik, Google services are run in a sandbox on Graphene OS.
  - tietjens 1y ago
    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.
    - thothless 1y ago
      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.
      - strcat 1y ago
        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.
ewuhic 1y ago
Do bank apps work with GrapheneOS?
- ysnp 1y ago
  In my country most of them do. It depends on the bank and their application. https://privsec.dev/posts/android/banking-applications-compatibility-with-grapheneos/ https://privsec.dev/posts/android/banking-applications-compa... offers a possibility to check which apps may work fine.
- npteljes 1y ago
  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.
  - ewuhic 1y ago
    What is SafetyNet?
    - npteljes 1y ago
      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/ 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.
estimator7292 1y 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.
- zevon 1y ago
  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.
- ReluctantLaser 1y ago
  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.
npteljes 1y ago
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.
- Taek 1y ago
  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
  - npteljes 1y ago
    Yeah, I suspect this really is a YMMV situation. I approach phones from my PC / Linux background, with a specific subset of software I wanna use, and it was a perfect match for that. If someone expects it to be "Android, but somehow better", then it likely won't deliver.
  - strcat 1y ago
    The sandboxed Google Play compatibility layer was added in July 2021 and quickly advanced from there, being able to support nearly all Play Store apps depending on Play services by around the end of the year. Note Google Maps used to work without sandboxed Google Play without account-based functionality and it having a hard dependency on Google Play happened around a year ago or so.
  - Scrubbed4426 1y ago
    That is something to do with Google Fi, not GrapheneOS. You can work around it by having the Google Fi app installed in the secondary profile and signed into the Google account associated with your service. Although I don't see much point in that. Anyway, it's not an issue caused by GrapheneOS, just Google Fi expecting to be present to grant service access.
romanpoet 1y ago
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/ https://f-droid.org/en/packages/net.typeblog.shelter/
- strcat 1y ago
  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 https://grapheneos.org/features has a good overview of most (not all) GrapheneOS features.
raybb 1y ago
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)
- strcat 1y ago
  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.
- BLKNSLVR 1y ago
  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.
angusturner 1y ago
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.
- strcat 1y ago
  > The user profiles was slow to set up and not having shared filesystem between the user profiles creates friction. But I love that I can effectively sandbox my work apps, sandbox the Zuck apps etc, with different VPN profiles for each user. 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.
  - angusturner 1y ago
    Interesting... Maybe I need to investigate PayPal as an option here. Best case would be my bank eventually adds tap to pay natively
neilv 1y ago
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).
- EvanAnderson 1y ago
  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 https://github.com/tmo1/sms-ie
- hsbauauvhabzb 1y ago
  Why stop there when you can just not have a phone at all?
  - neilv 1y ago
    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.
whatsupdog 1y ago
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.com/GrapheneOS/os-issue-tracker/issues/2083 https://web.archive.org/web/20250123135603/https://github.co... 1. https://www.youtube.com/watch?v=Dl1x1Dy-ej4 https://www.youtube.com/watch?v=Dl1x1Dy-ej4
- fluidcruft 1y ago
  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).
- cjonas 1y ago
  From what I can tell sounds like this guy's stepped away from the project? Curious what the latest status is.
  - stoltzmann 1y ago
    He didn't step away. He made a post where he "stepped down" as the project lead and instead got replaced by a "GrapheneOS Foundation director", of which there are 3 including him. That post has been deleted. As far as I can tell, nothing has changed other than obscuring the leadership of the project a tiny bit. strcat is still active here in the comments.
    - matheusmoreira 1y ago
      Is strcat the person who supposedly stepped down? If so, I'm glad he's still project lead. I would have immediately written off GrapheneOS as a lost cause if he wasn't. I have spent many hours browsing his comment history and reading his extremely detailed posts on Android and smartphone security. He obviously knows what he's doing. Not only is he competent, it's also clear that he cares way too much about GrapheneOS and is personally invested in it. Competence and actually giving a shit are the two attributes I respect most in a person. I wouldn't want anyone else making decisions. And that's coming from a guy who publicly disagreed with him on some ideological issue literally three days ago: https://news.ycombinator.com/item?id=45214818 https://news.ycombinator.com/item?id=45214818
bpiroman 1y ago
There has to be a better open source mobile OS out there.
- fsflover 1y ago
  Better in terms of what? Do PureOS, Mobian, postmarketOS work for you?
  - bpiroman 1y ago
    Thanks I'll check them out. Which one do you recommend?
    - fsflover 1y ago
      I'm using PureOS on my Librem 5 as a daily driver, happy user.
o999 1y ago
This post would be better if it focused on the differences with android. They can be found on GOS feature page, https://grapheneos.org/features https://grapheneos.org/features , some security features are difficult to understand for non-developers, like ability to block Web JIT and native code debugging.
nunobrito 1y ago
It seems every single day there is a new article here favoring that distro. Reminder: It forces you to use hardware suspected as compromissed from Google. Even this same month they were advocating you to use Tor, a VPN created and sponsored by the same agencies trying to get your private data. Read other comments here, many others will point out the obvious red flags. It isn't spontaneous either that every day or so there is an article about this distro. Don't fall into this trap, there are other options out there that deserve your attention.
- pandemic_region 1y ago
  Then list the other options, please.
  - jech 1y ago
    LineageOS is just fine if you have a well-supported device. If you need to run proprietary apps, you'll need MicroG (which runs just fine as a user application) and the Aurora store. Unfortunately, now that CalyxOS has died, the other choices are all forks of LineageOS (Iodé, /e/). The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet.
    - slashtab 1y ago
      stop spreading misinformation
    - tholdem 1y ago
      If you are fine running an OS with horrible security and privacy, then LineageOS and it's forks are fine. If you want the best privacy and security, then GrapheneOS is the best option.
    - strcat 1y ago
      LineageOS, iodé and /e/ are in a much different space than GrapheneOS. They greatly reduce the privacy and security of the Android Open Source Project rather than greatly improving it. They do not provide current privacy/security patches or keep all of the standard protections intact, let alone providing similar privacy and security enhancements to GrapheneOS. https://eylenburg.github.io/android_comparison.htm https://eylenburg.github.io/android_comparison.htm is a high quality third party overview comparing them with a focus on privacy and security. CalyxOS was not a hardened OS either, it just didn't roll back privacy and security quite as much as LineageOS. > The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet. GrapheneOS is a non-Google Linux distribution. Google heavily contributes to the Linux kernel and is responsible for a massive portion of the security work upstream. The same goes for LLVM, GCC and many other projects. If you have an issue with using lots Google code including as the biggest driver of security in these projects, you're going to need to avoid Linux too. Waydroid uses an ancient Android releases and largely disables the privacy and security model. Android apps running in Waydroid are much less sandboxed than in the standard Android app sandbox. It's not a sandbox for running Android but rather a partially working way to run an insecure fork of Android on top of a less private and secure non-Android distribution at a huge cost to privacy and security. It's not a good approach and moving to a much less private and secure OS is not progress in those areas.
noirscape 1y ago
For me the big blockers for GrapheneOS are still pretty much the same: * The community is unnecessarily toxic from what I've seen: there's a lot of following dogma without asking "why". It leads to this very insular userbase that often turns outwardly toxic towards other projects, which is an issue that goes forever unfixed (ie. This post on the F-Droid forums originally was far more aggressive towards the F-Droid project before moderators edited it to be less aggressive: https://forum.f-droid.org/t/google-will-require-developer-verification-to-install-android-apps-including-sideloading/33123 https://forum.f-droid.org/t/google-will-require-developer-ve... ). Other, older places I've seen this come "from the top" include hostile relicensing of Vanadium's patches to prevent other Chromium forks from making use of them. * Instead of blockading SafetyNet as being a user hostile solution, GOS instead... implements their own version of it. Which is hard to see as anything other than basically recreating the same walled garden you get on stock Android. * Pixel exclusivity is dumb and remains dumb. Pixels are very mediocre devices from a usability angle; they're large, have pretty inefficient battery life and in my experience are prone to becoming hot very easily. (I also managed to randomly brick one during a routine stock system upgrade, so there's that; not on GOS obviously, just noting that the Google side of the flagship Android is pretty lackluster too.) There's also a forever hypocrisy in defeating Google spying... by giving more money to Google. The motives for this seem to mostly be tied to a promise about the Pixel's security chip being open sourced eventually, but this is a forever promise Google isn't willing to cash out on. GOS has a token line on their site saying that most patches can be used on other OSes with little effort, but there's zero effort from any community to actually make these. (The reason for this can be blamed squarely on point 1; there's an insanely hostile reaction to anyone trying to do a fork for this sort of thing, which is basically enabled by the lead devs because of what they did w/ the Vanadium license.) * Finally, GOS doesn't let you do hosts based adblocking, instead encouraging you to use the Android VPN service instead. A simple solution... that isn't really realistic because the Android VPN service only covers running one VPN at a time, meaning you have to pick between adblocking and privacy/accessing your own internal network. Finally, a broader problem is that from what I can tell, GOS as a project doesn't quite grasp the relationship between app developer and app user and how it's become toxified over the years. Things like their ongoing signing beef with the F-Droid project (an incredibly niche issue that doesn't matter for most users) suggest to me that GOS is at best extremely naive/unrealistic on the issues that affect app usage for the common user. The problem these days is usually the developer going bad, not a third party.
aswerty 1y ago
Is it just me or does it seems very odd that GrapheneOS only runs on a phone produced by the company that makes Android. Meaning that ironically, it isn't a Google alternative. I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.
- tranq_cassowary 1y ago
  The reasoning is explained here: https://grapheneos.org/faq#device-support https://grapheneos.org/faq#device-support Note that Google is in active talks with an major Android OEM for a few months already to help them meet the requirements for a subset of their future devices. They are very optimistic about that.
pull_my_finger 1y ago
I like the idea of loading all apps from the "root" user profile, and pushing them to sub-user accounts, that seems natural as an administrative feature, but when you do it that way, any kind of privacy you'd have separating apps from seeing each other seems like it would be lost. I don't want apps to know what other apps on my phone, that would be part of the promise of user profiles in the first place... I'm not sure how to remedy that, but I've seen this advice in TFA and also on a youtube channel @sideofburritos, that covers GOS and security stuff, and it seems counter-productive in that sense.

236 points by renehsz 1y ago

> 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:\

ranger_danger 1y ago
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.
- yjftsjthsd-h 1y ago
  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.
- cakealert 1y ago
  > 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.
  - b112 1y ago
    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.
- yjftsjthsd-h 1y ago
  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/ 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.
  - ranger_danger 1y ago
    > 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.
- ysnp 1y ago
  >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?
  - yjftsjthsd-h 1y ago
    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.
    - ysnp 1y ago
      >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.
      - yjftsjthsd-h 1y ago
        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.
subscribed 1y ago
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.
- jampekka 1y ago
  If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
  - bornfreddy 1y ago
    Pssst, quiet, don't give them any ideas... :-/
  - paulhart 1y ago
    That's a Chromebook, no?
    - jampekka 1y ago
      Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guides/device/developer-mode/ https://www.chromium.org/chromium-os/developer-library/guide...
  - ajjahs 1y ago
    [dead]
  - codethief 1y ago
    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.
crapple8430 1y ago
You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting. See: github.com/chenxiaolong/avbroot
- tarruda 1y ago
  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?
  - chuckadams 1y ago
    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)
    - strcat 1y ago
      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.
    - sterlind 1y ago
      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.
      - strcat 1y ago
        Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu....
charcircuit 1y ago
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.
- oneshtein 1y ago
  > 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.
  - charcircuit 1y ago
    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."
    - oneshtein 1y ago
      So, your proposition is to remove their ability to install antivirus software, like Google does in Android? Users know about this problem and know how to mitigate it. Get out of my way, please.
      - Scrubbed4426 1y ago
        No, the goal is to move to a system that doesn't rely on badness enumeration (antivirus) as a primary defense. You can rely on the app sandbox and the security model of the system to keep it in check. Antivirus scanners are essentially useless on modern mobile OSes because they are limited to accessing the same things a malicious app or file would be.

fsflover 1y ago

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 https://news.ycombinator.com/item?id=45101400

ajjahs 1y ago
[dead]
ysnp 1y ago
>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.
- strcat 1y ago
  See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
- fsflover 1y ago
  >> their security model is the only reasonably secure approach in the world >They have not said anything like that. Quote (https://news.ycombinator.com/item?id=30769666 https://news.ycombinator.com/item?id=30769666): > Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required. The reality is that Librem 5 is secure according to a different threat model than the one GrapheneOS follows. This doesn't make it "incredibly" insecure, unless you believe that only you can define good threat models.

electric_muse 1y ago

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.

codethief 1y ago
> The user containers are very helpful You mean different user accounts? Those are available on stock Android, too.
- a0sud0a8s 1y ago
  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.
- ysnp 1y ago
  I think it depends on the Android distribution. I am not sure it is available on Samsung's One UI.
  - gertop 1y ago
    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.
    - ysnp 1y ago
      Apparently multiple user profiles is available on their tablets but not on their smartphones.

NoiseBert69 1y ago

Bought an Google Pixel Tablet only for GOS. Installation worked like a charm and all my applications are still working without problems. Loving it.

TranquilMarmot 1y ago
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)
- ysnp 1y ago
  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.
  - NoiseBert69 1y ago
    Paypal tap-to-pay works according to reports.
    - strcat 1y ago
      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.
  - TranquilMarmot 1y ago
    My main use of Google Wallet is to pay for the bus where I live, but we do have physical cards that I can also get. I do use it at the store sometimes but I also always have my physical wallet on me, so that's not a big deal.
mark_l_watson 1y ago
Great idea! I have wanted to experiment with GrapheneOS but didn’t want it to use it for banking or calls.

junkblocker 1y ago

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.

throawayonthe 1y ago
you need the google messaging app for RCS
- goda90 1y ago
  Is it because no one else has tried implementing the RCS standard or because Google has some proprietary hold over it?
  - cpa 1y ago
    Apple has RCS, compatible with Android, at least in the EU. You don't get the blue bubble though.
    - Klonoar 1y ago
      I think they’re asking about on Android. The point is whether there’s an alternative RCS client to run on GOS.
  - alethic 1y ago
    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 https://github.com/search?q=rcs+android&type=repositories
- yellowapple 1y ago
  Which itself is not guaranteed to work even on ”stock” Android, let alone GOS — which multiple people (myself included) have been experiencing firsthand.

tietjens 1y ago

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.

krior 1y ago
Afaik, Google services are run in a sandbox on Graphene OS.
- tietjens 1y ago
  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.
  - thothless 1y ago
    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.
    - strcat 1y ago
      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.

ewuhic 1y ago

Do bank apps work with GrapheneOS?

ysnp 1y ago
In my country most of them do. It depends on the bank and their application. https://privsec.dev/posts/android/banking-applications-compatibility-with-grapheneos/ https://privsec.dev/posts/android/banking-applications-compa... offers a possibility to check which apps may work fine.
npteljes 1y ago
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.
- ewuhic 1y ago
  What is SafetyNet?
  - npteljes 1y ago
    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/ 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.

estimator7292 1y 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.

zevon 1y ago
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.
ReluctantLaser 1y ago
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.

npteljes 1y ago

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.

Taek 1y ago
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
- npteljes 1y ago
  Yeah, I suspect this really is a YMMV situation. I approach phones from my PC / Linux background, with a specific subset of software I wanna use, and it was a perfect match for that. If someone expects it to be "Android, but somehow better", then it likely won't deliver.
- strcat 1y ago
  The sandboxed Google Play compatibility layer was added in July 2021 and quickly advanced from there, being able to support nearly all Play Store apps depending on Play services by around the end of the year. Note Google Maps used to work without sandboxed Google Play without account-based functionality and it having a hard dependency on Google Play happened around a year ago or so.
- Scrubbed4426 1y ago
  That is something to do with Google Fi, not GrapheneOS. You can work around it by having the Google Fi app installed in the secondary profile and signed into the Google account associated with your service. Although I don't see much point in that. Anyway, it's not an issue caused by GrapheneOS, just Google Fi expecting to be present to grant service access.

romanpoet 1y ago

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/ https://f-droid.org/en/packages/net.typeblog.shelter/

strcat 1y ago
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 https://grapheneos.org/features has a good overview of most (not all) GrapheneOS features.

raybb 1y ago

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)

strcat 1y ago
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.
BLKNSLVR 1y ago
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.

angusturner 1y ago

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.

strcat 1y ago
> The user profiles was slow to set up and not having shared filesystem between the user profiles creates friction. But I love that I can effectively sandbox my work apps, sandbox the Zuck apps etc, with different VPN profiles for each user. 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.
- angusturner 1y ago
  Interesting... Maybe I need to investigate PayPal as an option here. Best case would be my bank eventually adds tap to pay natively

neilv 1y ago

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

EvanAnderson 1y ago
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 https://github.com/tmo1/sms-ie
hsbauauvhabzb 1y ago
Why stop there when you can just not have a phone at all?
- neilv 1y ago
  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.

whatsupdog 1y ago

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.com/GrapheneOS/os-issue-tracker/issues/2083 https://web.archive.org/web/20250123135603/https://github.co... 1. https://www.youtube.com/watch?v=Dl1x1Dy-ej4 https://www.youtube.com/watch?v=Dl1x1Dy-ej4

fluidcruft 1y ago
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).
cjonas 1y ago
From what I can tell sounds like this guy's stepped away from the project? Curious what the latest status is.
- stoltzmann 1y ago
  He didn't step away. He made a post where he "stepped down" as the project lead and instead got replaced by a "GrapheneOS Foundation director", of which there are 3 including him. That post has been deleted. As far as I can tell, nothing has changed other than obscuring the leadership of the project a tiny bit. strcat is still active here in the comments.
  - matheusmoreira 1y ago
    Is strcat the person who supposedly stepped down? If so, I'm glad he's still project lead. I would have immediately written off GrapheneOS as a lost cause if he wasn't. I have spent many hours browsing his comment history and reading his extremely detailed posts on Android and smartphone security. He obviously knows what he's doing. Not only is he competent, it's also clear that he cares way too much about GrapheneOS and is personally invested in it. Competence and actually giving a shit are the two attributes I respect most in a person. I wouldn't want anyone else making decisions. And that's coming from a guy who publicly disagreed with him on some ideological issue literally three days ago: https://news.ycombinator.com/item?id=45214818 https://news.ycombinator.com/item?id=45214818

bpiroman 1y ago

There has to be a better open source mobile OS out there.

fsflover 1y ago
Better in terms of what? Do PureOS, Mobian, postmarketOS work for you?
- bpiroman 1y ago
  Thanks I'll check them out. Which one do you recommend?
  - fsflover 1y ago
    I'm using PureOS on my Librem 5 as a daily driver, happy user.

o999 1y ago

This post would be better if it focused on the differences with android. They can be found on GOS feature page, https://grapheneos.org/features https://grapheneos.org/features , some security features are difficult to understand for non-developers, like ability to block Web JIT and native code debugging.

nunobrito 1y ago

It seems every single day there is a new article here favoring that distro. Reminder: It forces you to use hardware suspected as compromissed from Google. Even this same month they were advocating you to use Tor, a VPN created and sponsored by the same agencies trying to get your private data. Read other comments here, many others will point out the obvious red flags. It isn't spontaneous either that every day or so there is an article about this distro. Don't fall into this trap, there are other options out there that deserve your attention.

pandemic_region 1y ago
Then list the other options, please.
- jech 1y ago
  LineageOS is just fine if you have a well-supported device. If you need to run proprietary apps, you'll need MicroG (which runs just fine as a user application) and the Aurora store. Unfortunately, now that CalyxOS has died, the other choices are all forks of LineageOS (Iodé, /e/). The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet.
  - slashtab 1y ago
    stop spreading misinformation
  - tholdem 1y ago
    If you are fine running an OS with horrible security and privacy, then LineageOS and it's forks are fine. If you want the best privacy and security, then GrapheneOS is the best option.
  - strcat 1y ago
    LineageOS, iodé and /e/ are in a much different space than GrapheneOS. They greatly reduce the privacy and security of the Android Open Source Project rather than greatly improving it. They do not provide current privacy/security patches or keep all of the standard protections intact, let alone providing similar privacy and security enhancements to GrapheneOS. https://eylenburg.github.io/android_comparison.htm https://eylenburg.github.io/android_comparison.htm is a high quality third party overview comparing them with a focus on privacy and security. CalyxOS was not a hardened OS either, it just didn't roll back privacy and security quite as much as LineageOS. > The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet. GrapheneOS is a non-Google Linux distribution. Google heavily contributes to the Linux kernel and is responsible for a massive portion of the security work upstream. The same goes for LLVM, GCC and many other projects. If you have an issue with using lots Google code including as the biggest driver of security in these projects, you're going to need to avoid Linux too. Waydroid uses an ancient Android releases and largely disables the privacy and security model. Android apps running in Waydroid are much less sandboxed than in the standard Android app sandbox. It's not a sandbox for running Android but rather a partially working way to run an insecure fork of Android on top of a less private and secure non-Android distribution at a huge cost to privacy and security. It's not a good approach and moving to a much less private and secure OS is not progress in those areas.

noirscape 1y ago

For me the big blockers for GrapheneOS are still pretty much the same: * The community is unnecessarily toxic from what I've seen: there's a lot of following dogma without asking "why". It leads to this very insular userbase that often turns outwardly toxic towards other projects, which is an issue that goes forever unfixed (ie. This post on the F-Droid forums originally was far more aggressive towards the F-Droid project before moderators edited it to be less aggressive: https://forum.f-droid.org/t/google-will-require-developer-verification-to-install-android-apps-including-sideloading/33123 https://forum.f-droid.org/t/google-will-require-developer-ve... ). Other, older places I've seen this come "from the top" include hostile relicensing of Vanadium's patches to prevent other Chromium forks from making use of them. * Instead of blockading SafetyNet as being a user hostile solution, GOS instead... implements their own version of it. Which is hard to see as anything other than basically recreating the same walled garden you get on stock Android. * Pixel exclusivity is dumb and remains dumb. Pixels are very mediocre devices from a usability angle; they're large, have pretty inefficient battery life and in my experience are prone to becoming hot very easily. (I also managed to randomly brick one during a routine stock system upgrade, so there's that; not on GOS obviously, just noting that the Google side of the flagship Android is pretty lackluster too.) There's also a forever hypocrisy in defeating Google spying... by giving more money to Google. The motives for this seem to mostly be tied to a promise about the Pixel's security chip being open sourced eventually, but this is a forever promise Google isn't willing to cash out on. GOS has a token line on their site saying that most patches can be used on other OSes with little effort, but there's zero effort from any community to actually make these. (The reason for this can be blamed squarely on point 1; there's an insanely hostile reaction to anyone trying to do a fork for this sort of thing, which is basically enabled by the lead devs because of what they did w/ the Vanadium license.) * Finally, GOS doesn't let you do hosts based adblocking, instead encouraging you to use the Android VPN service instead. A simple solution... that isn't really realistic because the Android VPN service only covers running one VPN at a time, meaning you have to pick between adblocking and privacy/accessing your own internal network. Finally, a broader problem is that from what I can tell, GOS as a project doesn't quite grasp the relationship between app developer and app user and how it's become toxified over the years. Things like their ongoing signing beef with the F-Droid project (an incredibly niche issue that doesn't matter for most users) suggest to me that GOS is at best extremely naive/unrealistic on the issues that affect app usage for the common user. The problem these days is usually the developer going bad, not a third party.

aswerty 1y ago

Is it just me or does it seems very odd that GrapheneOS only runs on a phone produced by the company that makes Android. Meaning that ironically, it isn't a Google alternative. I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.

tranq_cassowary 1y ago
The reasoning is explained here: https://grapheneos.org/faq#device-support https://grapheneos.org/faq#device-support Note that Google is in active talks with an major Android OEM for a few months already to help them meet the requirements for a subset of their future devices. They are very optimistic about that.

pull_my_finger 1y ago

I like the idea of loading all apps from the "root" user profile, and pushing them to sub-user accounts, that seems natural as an administrative feature, but when you do it that way, any kind of privacy you'd have separating apps from seeing each other seems like it would be lost. I don't want apps to know what other apps on my phone, that would be part of the promise of user profiles in the first place... I'm not sure how to remedy that, but I've seen this advice in TFA and also on a youtube channel @sideofburritos, that covers GOS and security stuff, and it seems counter-productive in that sense.