> "Thanks, but there's no way..."

Its reposted because the information is accurate, and misinformation regarding it is very prevalent.

> "Yes, I knew it's in a sandbox..."

Relative to MicroG, sandboxed google play is much more private, secure, and usable. I would not describe it as a privacy paradise, but MicroG does not improve upon this, and instead makes these aspects worse.

> "The sandbox still needs internet access..."

Most google libraries operate independently of google services and do not depend on them to function. FCM is an exception due to how push notifications are optimized (by using one app for the connection). MicroG does not avoid this.

> "For example, Signal will actively reach..."

You do not need to provide an identity to google. This can also be avoided with a VPN, and is not specific to google. There is the concern of metadata but Signal sends empty notifications without any identifying info. They are only used to wake the app up to fetch its own notifications.

> "So while the sandbox is definitely very useful..."

It confines google services to the same rules and restrictions as all other apps. MicroG does not. MicroG also does not avoid running unwanted software, referring to the google libraries in apps and the google code MicroG downloads.

> "Do you know what privileged context means..."

MicroG violates the security model by necessitating signature spoofing, which puts it in a position to receive data it was not intended to receive, there is also attack surface exposed by having access forbidden by the app sandbox. Sandboxed google play is bound by the same app sandbox as all other apps, and would not be any more or less capable of exploiting the device than any other app. The idea that google would try to exploit the device is nonsensical though. But granting both google and a 3rd party privileged access is still unacceptable.

> "Rather than running the unwanted proprietary (but necessary) software..."

Google play services runs in the android user app sandbox. It is not an "attempt", it is successful at doing this. MicroG being open source does not matter in regards to privacy or security. It did not change how MicroG has leaked location to apps without location permissions, it does not change how it downloads and runs google code both privileged and outside of its own APK, and it does not change how other apps are running google libraries anyway. Note that the proprietary code it downloads is not confined to the app sandbox.

> "For example, microG will replace Gmaps..."

Im unsure if you are referring to the app Google Maps, or google maps integration. GrapheneOS reroutes googlefusedlocation requests to the OS, rather than google services. You can use an app other than google maps, and apps with google map integration can simply send your location to google directly, independent of google services or MicroG.

> "It seems fairly obvious to me that less data sharing..."

Googles access to data is not limited by using MicroG, relative to sandboxed google play. And the size of proprietary code is irrelevant, that code can be anything. It can be malicious with 2 lines, or benign with 2 million. Access is what is vital, not size. Google is not permitted to "run wild", and is granted no additional access compared to any other app. Im unsure what you mean by self updating functionality, but for apps from the playstore, nearly all of them are signed with a key that google holds, and MicroG can do nothing about this. GrapheneOSs App Store is responsible for updating google play and google services, it cannot update itself.

> "What threat would sandboxed microG pose that sandboxed GMS doesn't?..."

Using MicroG necessitates GrapheneOS violate the android security model, trust a 3rd party unnecessarily, cripple 99% perfect compatibility, use code that is not near as battletested as play services, run google code as privileged, and run a software that has had serious privacy violations in the past. Not only is the base insufficient, but any finished product based on it still would not compare to GMSCompat. The logic is that GrapheneOS wants the best compatibility, the least changes to the android app sandbox, 0 privileged google components, no violations to the android security model, and no need to maintain a reimplementation when google services and store are already maintained by a huge organization.

Fairphone doesnt make their own phones, its outsourced to an ODM and Fairphone has very little input on how its designed. They havent "sourced" anything. Fairphone also stops providing kernel updates very quickly and delays userspace/driver/firmware backports for months. They delay yearly updates for years too. This doesnt even touch upon the fact they used public signing keys in the past.

It is not derogatory to say that it is e-waste out of the box, it is simply accurate. Choosing to continue using it despite how unsafe it is does not change the abysmal support it is given. A modern iPhone/android used from launch to the end of its 7 year support time, then properly recycled, would be far better for privacy, security, and for the environment. A support window that long would also provide a strong used market to continue using these devices. Cheap ODM phones with short support windows, and not benefiting from economies of scale, is a waste.

Every month, vulnerabilities are published and publicly accessible. The more out of date a device becomes, the more vulnerabilities are available. This is made worse when the integrity of the operating system cannot be verified and root access is exposed. Avoiding this is not a high level threat model, that is the bare minimum.

GrapheneOS points out how its improved privacy and security should mean that it is accepted in a system like play integrity. But this is just to outline how flawed the logic of play integrity is. It is by no means an endorsement of play integrity. GrapheneOS wants people to know that google is lying and breaking the law, and uses its own exclusion as that evidence. Even if GrapheneOS were accepted into play integrity, it would still exclude any and all forks and self-signed builds of GOS, which is unacceptable. If companies absolutely insist on using this approach despite its flaws, they should use the generic attestation available in android, and permit using 3rd party roots of trust in some form, rather than outsourcing this verification to 3rd parties like google.

As for the pinned attestation approach, that is Trust On First Use, and is used to verify the integrity of a device based on the security of the devices early bootchain. The initial attestation is what future attestation is pinned to. This allows you to verify a device is the same one, it has not been downgraded, has not been tampered with, etc. This is awesome, and lets you do things like what GrapheneOS does with Auditor. But this is not used to restrict what operating systems are used. Root based attestation somewhat tries to resolve the Trust On First Use approach, but is used to arbitrarily ban operating systems in practice. It is super flimsy as any leaked keys can bypass it.

My only concern is your claim that GrapheneOS is for this technology when it is most certainly against it. The nuance is that pinned attestation is a different approach with different properties, and advocating for it does not mean GrapheneOS is not an ally against play integrity.

Auditor also functions as a proof of concept for the potential of attestation, check here for more info: https://attestation.app/about

The policies and applications running on top of or in the linux kernel do not change its distro classification. Lacking root access is a massive step forward for privacy and security. Root access is insecure and a hacky shortcut to proper functionality.

Sandboxed google play does not grant google code any kind of privileged access. It is confined to the same app sandbox and permission model as all other apps and can be installed and uninstalled like any other app.

Note that apps with google libraries grant google the same, unprivileged access google services gets on GrapheneOS. MicroG fails to meet the privacy, security, and usability requirements GrapheneOS has in place when it comes to google play compatibility.

So, you can pick MicroG, which is bundled, privileged, poorly made, has poor compatibility, and trusts an additional party...

Or, you can pick sandboxed google play, which is not bundled, optional, unprivileged, fully sandboxed, and does not trust additional parties. Oh, and you can uninstall and reinstall whenever.

It is evident which option gives the user freedom, and a choice.

GrapheneOS is one of, if not the most vocal organization against the abuse of attestation mechanisms. GrapheneOS and its userbase feel the consequences of play integrity every single day.

Im not sure where you got the idea that all GrapheneOS wants is to be accepted by play integrity, because that is not the case. GrapheneOS has been working with regulators to get play integrity banned. Being accepted by play integrity, but nothing else changing, is not good enough for GrapheneOS. It would only be a small victory along the path of abolishing this nonsense.

So, no, GrapheneOS and its community are definitely against play integrity. The "signs" that they are "starting to notice" are not there. They are already fully aware of what attestation is and how it can be abused. They are definitely not ignorant on the subject.

You might be confusing root based attestation with pinned attestation. Root based attestation is flimsy and allows tools like play integrity to ban operating systems they do not like. Pinned attestation, on the other hand, has real security properties and cannot be abused to block certain operating systems. GrapheneOS uses pinned attestation as a part of their Auditor app, and it has other cool uses we could see in the future.

I do know what these terms mean in a legal context. I am claiming that play integrity is an anticompetitive and monopolistic tool, of which VW decided to use. I am not claiming VW is a monopoly. What you are claiming is their right to do, is not their right at all, and is illegal.

Contrary to popular belief, exploitation of vulnerable devices is a lot more common, and a lot easier than people pretend it is. You dont need to be targeted either, mass exploitation can, has, and will occur.

LineageOS does not have privacy, security, or usability comparable to GrapheneOS. LineageOS is missing many important features and falls behind android updates. GrapheneOS will be the far better choice in all 3 of these categories.

The features GrapheneOS provides, such as the network permission, cannot be replicated with a firewall app. The network permission properly covers all forms of network access for an app, where firewall apps do not have the ability to prevent all network communication. They are leaky.

The AGNSS servers and proxies are very, very tiny aspects of what GrapheneOS provides. You would be losing out on many more high impact privacy, security, and usability features.

Root access and an unlocked bootloader are insecure, even for low threat models. These devices are vulnerable and should not be used for any sensitive data.

LineageOS is not the better choice for any privacy, security, or usability usecases relative to GrapheneOS.

Play integrity is an anticompetitive tool that ignores this, and artificially limits itself on GrapheneOS. It is not due to any incompatibility.

Tools such as play integrity are illegal. Using anticompetitive and monopolistic tools is not the right of application developers.

The issue is not that this application isnt tested on GOS, its that an anticompetitive, illegal tool is being used to ban non-certified OSs when these apps would work perfectly otherwise.

GrapheneOS is also not responsible for bugs in this app. Any bug reports coming from GOS are likely to be from the hardening toggles, which uncover bugs in the app. This is the apps fault, and these bugs still exist on other OSs. It should be resolved for the benefit of all users.

Dont let their boilerplate responses fool you, tools like play integrity only serve to push anticompetitive practices. The claims about not being able to support GOS are nonsense, and all they did was break existing support.

Oh, and Android 17 has been released so there is hype for that.