I see quite a few people claiming that Graphene OS is the only way to stay private on Android or that anything but Graphene OS is insecure. In this post, I will describe why I personally do not care for Graphene OS and some alternatives I would suggest.

First off, let’s address the security features of Graphene OS. A lot of the security of Graphene OS comes from AOSP itself. In fact, AOSP has a very good track record. If you get malware on your device, you most likely can just uninstall it. For reference, here is the Android security page: https://source.android.com/docs/security/features

There are some Graphene OS unique security features. For instance, it has a hardened kernel and restricts access. I think this is actually pretty useful but I haven’t seen a need for it much in the real world. The tightened permissions are nice, and I think that is the main benefit of Graphene OS over AOSP. It is also nice that device identifiers are restricted from a privacy perspective. However, from my perspective, you should not run apps that are bad for privacy. Running it in the web browser will be more secure than bare metal could ever be.

One place I strongly disagree with Graphene OS is the sandboxed Google services framework. They say having Google in a sandbox is more secure. It may be more secure, but it isn’t going to be as private as MicroG. The real benefit of MicroG is that it is community-built. It isn’t a black box like Google framework, and any data sent back is randomized. I think it is a mistake for Graphene OS not to have support for it, even if it is also run in a sandbox.

Another thing I have noticed is that Graphene OS prioritizes security above all else. That doesn’t mean it isn’t private as it itself is great for privacy. However, if you start installing privacy-compromising applications such as Gmail and Instagram, your privacy is quickly lost. The apps may not be able to compromise the OS, but for them to be used, they need permissions. To be fair, this is a problem that is not unique to Graphene OS, but I think its attempts to be closer to Google Android make it more tempting for people to stick to poor privacy choices.

I think other ROMs such as Calyx OS take the ethical component much more seriously. Unlike Graphene, it promotes F-droid and FOSS software like MicroG. Graphene purely focuses on security while Calyx OS focuses on privacy and freedom. On first setup, it offers to install privacy-friendly FOSS applications such as F-droid and the like. I realize that MicroG is not perfectly compatible, and some people need apps, but I think alternatives are going to always be better.

One of the most annoying parts about Graphene OS is the development team and some of the community. They refuse to take criticism and have been known to delete any criticism of Graphene OS. Not only that, they have a history of trying to harm any project or person they don’t like.

Here is a page that isn’t written by me that sums it up: https://opinionplatform.org/grapheneos/index.html I think their take is fairly extreme, but I agree with them in many ways. I also understand how upsetting it can be to be censored.

  • Andromxda 🇺🇦🇵🇸🇹🇼@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    4
    ·
    4 months ago

    Since microG obviously doesn’t use the official Google Play Services binary, it has to spoof the signature of the app, in order to get other apps that rely on Play services to think that microG is in reality Google Play. Android usually prevents this by checking and enforcing an application’s signature, but it can be bypassed using root. This further decreases security, since it also bypasses any SELinux policies.
    Since GrapheneOS uses the official Google Play services binary and runs it in the Android application sandbox, the signature is still valid and no spoofing, and no root privileges are required. Running third-party code as root unnecessarily increases attack surface, and it completely destroys Android’s security model, which is based on the principle of least privilege (which is very common to see in cybersecurity).

    • Possibly linux@lemmy.zipOP
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      4
      ·
      4 months ago

      Well I personally can’t stand the idea of Google GSF. MicroG is the best option as it isn’t Google.

      MicroG also is very flexible on how it works. It is broken down into lots of different services.

      • Andromxda 🇺🇦🇵🇸🇹🇼@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        4 months ago

        Well I personally can’t stand the idea of Google GSF

        I can actually understand that, and I had the same thought when I started using GrapheneOS. But microG is just an open source layer that requires proprietary Google blobs in the background, which sits between the proprietary Google Play services library in proprietary apps and proprietary Google network services. You gain almost nothing from using it, while simultaneously increasing attack surface, due to microG’s requirement for root privileges.

        MicroG also is very flexible on how it works. It is broken down into lots of different services.

        Can you really control which parts of microG are active? This suggests the opposite: https://discuss.grapheneos.org/d/4290-sandboxed-microg/18

        From the thread:

        Signal is a perfect example where the app works fine without Google Play including with push but will not work correctly in a setup you proposed in the other thread of using it with FCM disabled. That breaks the app and it won’t get calls or push notifications anymore, unlike using it in a profile without Google Play

        (Yes, I know that the GrapheneOS Forum might be a biased source when talking about this topic, but I currently don’t have any way of testing this out with microG. If you don’t believe what the Graphene dev is saying in the forum thread, you can try it out for yourself)

        The only part of microG that I would really consider using is UnifiedNLP, together with a privacy-friendly network location service. There was actually a discussion about including UnifiedNLP in GrapheneOS, but I think there were some licensing issues. (GrapheneOS can’t use GPLv3 code. GPLv2, MIT and Apache are fine though). But Graphene’s SUPL & PSDS-based approach for obtaining location information currently works well enough, and they might integrate an open, privacy-friendly NLP like beaconDB in the future.