A growing number of apps are using the Play Integrity API to enforce installation from the Play Store. This is clearly highly illegal anti-competitive behavior. It doesn’t impact GrapheneOS users installing apps with the sandboxed Play Store but does impact other install sources.

This is being done alongside Google recommending app developers forbid installing their apps from the Play Store on operating systems not licensing Google Mobile Services. The combination of these feature ends up blocking users from easily using the apps without modifying them.

We’re going to add a secure way of working around this without breaking the app source security model. We’ll be adding support for having the OS automatically verify the Play Store signing metadata and then inform Play services those apps were installed from the Play Store.

It’s worth noting Android has a standard hardware attestation API for verifying the hardware, firmware, OS and app. This supports alternate roots of trust and non-stock operating systems if apps choose to support it. Apps could perform stronger checks while allowing GrapheneOS.

Android’s hardware attestation API has anti-competition issues due to the official verification libraries hard-wiring the Google roots and encouraging only permitting the stock OS. However, it does fully support any other OS with verified boot and can be used with other root CAs.

Google’s Play Integrity API is quite different and only supports verifying devices licensing Google Mobile Devices with the stock OS. It has support for enforcing installing apps from the Play Store. None of this has anything to do with security. It’s purely anti-competitive.

Google Play Integrity permits highly insecure devices with years of missing High/Critical severity security patches. They pretend any device licensing Google Mobile Services is secure while running the stock OS and anything else is insecure. This is a lie to lock out competition.

There’s no security value to enforcing using devices licensing Google Mobile Services. The vast majority of those devices are highly insecure. Software-based attestation (device integrity) is also highly insecure and easy for attackers to bypass. This is only hurting competition.

Hardware-based attestation can be secure, but the way the Play Integrity API uses it is also highly insecure. It can be bypassed via leaked keys from the most insecure Android devices in the ecosystem. Secure way to use it is pinning, not trusting everything chaining to a root.

Even if apps insist on doing these kinds of integrity checks, they can still permit GrapheneOS. We provide a guide on verifying GrapheneOS via hardware attestation at https://grapheneos.org/articles/attestation-compatibility-guide. They can still fall back to Play Integrity API for insecure devices without this.

Multiple prominent banking apps in Europe have already implemented support for GrapheneOS via hardware attestation. The pace of apps adopting the Play Integrity API is unfortunately currently faster than apps adding support for GrapheneOS. This is due to Google marketing it.

If you run into apps banning using GrapheneOS with Play Integrity, make a Play Store review with no links asking to stop banning a more secure OS. Next, make a customer support request linking https://grapheneos.org/articles/attestation-compatibility-guide. Multiple apps have permitted GrapheneOS due to these efforts.

  • illi@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    13 days ago

    I had this happening with just one app so far, but it is frustrating as it is a paid one. Good to hear there might be some ways around it, will see. Also good thing to have something to refer the devs to.

      • illi@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        12 days ago

        Root, it’s a digital version of my favorite boardgame. Said it’s not compatible suddenly a few months back when I had to update it. Went through Aurora and worked just fine again but now it checks against the playstore and doesn’t let me launch it, as it is not listed on the play store because of the “incompatibility”

    • Maiq@lemy.lol
      link
      fedilink
      English
      arrow-up
      11
      ·
      13 days ago

      The only phone that has the hardware security that GOS requires is the Pixel. I hope one day fairPhone has a secure enough hardware to support GOS.

      I didn’t want to support google and buy a pixel either. I did and put GOS on it the second I bought it. Turns out I love GOS so much now that I don’t regret the phone purchase that much. I get it though, sucks to have to buy something from google.

        • Maiq@lemy.lol
          link
          fedilink
          English
          arrow-up
          3
          ·
          12 days ago

          Cant expect a custom OS to sacrifice their business model and standards. Obviously they cant provide what they do on other devices and what they do is provide the most secure OS available on android.

            • Maiq@lemy.lol
              link
              fedilink
              English
              arrow-up
              4
              ·
              12 days ago

              While I agree that everyone should be able to enjoy privacy and security, i don’t agree that GOS should compromise their standards and invite new/more threat model’s that compromise their standards for security.

              I’m not downvoting you BTW. I don’t think your trolling and think you would like to enjoy GOS but can’t for one reason or another.

              Any way nave a nice evening/day.

            • akc3n@lemmy.mlM
              link
              fedilink
              English
              arrow-up
              4
              ·
              11 days ago

              privacy is a team game, so still not much point. the most secure os ever barely anyone can use.

              GrapheneOS cannot provide a high level of privacy and security on other Android devices not meeting our requirements, which is why we don’t support them. There aren’t other devices providing those important industry standard security features with support for us using them. We’ve tried to get OEMs to do it.

            • PenguinCoder@beehaw.org
              link
              fedilink
              English
              arrow-up
              1
              ·
              11 days ago

              Privacy and security are required with Graphene. Devolving either for convenience is contradicting to their mission and the security of the users.

        • monovergent 🛠️@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          12 days ago

          I think you would have enjoyed DivestOS back when it was maintained.

          For both Maiq and ☂️, would a used Pixel be an option? I wasn’t keen on letting Google profit directly off of me either, so I got both of my Pixels in gently used condition off eBay.

        • akc3n@lemmy.mlM
          link
          fedilink
          English
          arrow-up
          2
          ·
          11 days ago

          no point in making a super private os that only a tiny moneyed minority can run. and honestly i don’t buy it that compatmentalization like this can’t be done on other phones.

          The main reason no other devices meet our requirements is because the most secure non-Pixel Android devices do not allow using another OS or disable a bunch of important security features with one. The devices not crippling non-stock OS support are much lower security devices.

    • akc3n@lemmy.mlM
      link
      fedilink
      English
      arrow-up
      3
      ·
      11 days ago

      ok now do it on any phone that isn’t a pixel

      We can support other devices not specifically made for GrapheneOS which meet the requirements: https://grapheneos.org/faq#future-devices
      Unfortunately, none currently do.

      These are very reasonable requirements and Pixels are the only Android devices with the hardware/firmware security meeting industry standard features.

      There are other devices providing the required features, but without non-stock OS support for them.