MicroG requires privileged access. It also downloads and runs proprietary google code within this privileged context. MicroG additionally has very poor app compatibility and has had severe privacy issues in the past.

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.

Thanks, but there's no way anybody here hasn't already heard all of that. GrapheneOS' statements are inevitably reposted to every thread and subthread that touches on the topic.

Yes, I knew it's in a sandbox at the time of writing my comment above; no, that doesn't make it a privacy paradise compared to microG.

The sandbox still needs internet access for a lot of GMS' functions and lots of apps send information into it. For example, Signal will actively reach out for notification bundling, so Google gets to know who runs Signal, what IP address they're on, with who else they share that address as they go to school and work, build a social graph... So while the sandbox is definitely very useful and I'm glad it exists as open source software that other Android distributions can be inspired by, it doesn't definitively solve fundamental problems with running unwanted software on your device

Do you know what privileged context means? As in, what access this grants concretely? I tried to look it up once, ended up in Android source code trees, and left more confused than I went in. It looked like it gets no extra file access at all, which is strange right? What does privileged mean if not that? I tried su'ing to the user ID of GMS and this confirmed that the GMS user can't access other apps' data folders. So I'm no longer sure what to even make of this wording. Is it maybe about syscall hardening that isn't applied to privileged apps or so, so like exploit protection rather than normal permissions? The benefit of that would be protecting from exploits that Google could send. Do we think they'd legit do that, short of receiving an NSL that compels them?

Rather than running the unwanted proprietary (but necessary) software wholesale and attempt to sandbox it, I'd much rather substitute as much as possible with open code (where we know what it does) and have a much smaller set of proprietary components that need to be kept around in a sandbox and active only when necessary. For example, microG will replace Gmaps with Mapbox, reducing how much data is sent out about you to Google (they don't get to see which city you are probably in while using the map in Too Good To Go, for example).

It seems fairly obvious to me that less data sharing plus less proprietary code (that needs to be sandboxed) is better than letting Google go wild and installing their apps as-is with self-updating functionality (in said sandbox). What threat would sandboxed microG pose that sandboxed GMS doesn't? Is there any logic to GrapheneOS not wanting to build upon microG to get the remaining proprietary parts properly sandboxed, rather than starting over from scratch?

note where I wrote:

> su'ing to the user ID of [another app]

Look, I have root, so you can hack me! And my bootloader is wide open, too! In your words:

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

I'm serious that anyone should feel free to prove the point by sending me a responsible disclosure notice about having found a way in, but the threat clearly isn't serious enough for that to actually be concretely possible. Which is not to say that it's never relevant, but "such a device shouldn't be used" is not valid as a blanket statement

For context, GMSCompat is Google Mobile Services Compatibility. GrapheneOS installed the google play store and services as normal apps, and worked backwards to make it behave. There is no google specific sandbox, rather it uses the standard android user app sandbox. This means google is bound by the same rules, as special casing anything creates more maintenance burden and attack surface. GMSCompat is fully open source.

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

GrapheneOS has 99% app compatibility with sandboxed google play. Apps do not have issues with sandboxed google play at this time.

When is the last time you tried the MyQ garage opener app?

Note that Fairphone does not provide software updates for anywhere near as long as they claim, and using a modern device with 7 years of support, such as a pixel or iphone, will be far better in the long term. Fairphone is basically e-waste out of the box.

Somehow that stands in stark contrast with the many Fairphone users that I know use their device for many years. One of them uses it as their primary computing device, not owning something like a laptop because the Ubuntu Touch that runs on it plugs into a screen and keyboard and works like a desktop as well as a phone for them. I don't understand why the derogatory statement about that being e-waste out of the box when it obviously works great, at least for those willing to pay the premium for as-fair-as-they-can-make-it part sourcing

Im not disputing the ability to use the device for many years. Using the device for a long time and the device being supported for a long time are different things.

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.

I have the Fairphone 5, for which they picked the IoT equivalent of the mobile chipset so they could ensure 10 years of driver availability from the vendor (8 years of majors + 2 of security patching IIRC).

Fairphone 2 came out in December 2015 and saw the last release in March 2023. That's 8 years of software updates when Android devices from that era barely got 3, and you had to pick the flagship.

Kernel updates used to be bound to Android versions because of how the kernel modules development was handled, not really limited by the company or the hardware. I owned a OnePlus 5 and the custom ROM was stuck with older kernels for a while too, until the community stepped up to port it, because there just wasn't an easy way to build kernels with updated custom vendor modules for the hardware. Google addressed at least that part thanks to the Kernel Module Interface (read e.g. https://arstechnica.com/gadgets/2021/09/android-to-take-an-u... ). So newer kernels may still lag a bit based on the manpower available and priorities, but they should be easier to do.

Now that replacement cycles have become longer because hardware is good enough that you don't need to change phone every year, and Android supports KMI and other features that make maintenance easier, more vendors decided to extend support, so at least there's some more choice.

From the environment point of view, I can now finally easily repair my phone. A friend of mine always had bad luck with pixels, so bad that he went through 4 phones in ~5 years (2 bought, 2 replacements). I am at my third phone in 12 years (OP1, OP5, Fairphone).

GrapheneOS is designed for everyone, including average users. It does not require a high threat model, and the features it provides are not only useful to people with high threat models.

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.

> Contrary to popular belief

Extraordinary claims require extraordinary evidence. Got any?

The rest of the comment consists of even vaguer statements about how it's better in every way and then (circularly) drawing the conclusion that it's always the right choice because it's better in every way. I have no idea how to respond to these opinions than either writing a book that goes into every subtopic you're touching on, or just concluding "ok that's your opinion". Maybe consider that others may disagree by having different values and priorities than you, and so it's not strictly always the best option

You cant respond to any opinion because I have not provided any. Security is objective. What security someone may need can vary, yes, but that does not change how the security of a device works. You are downplaying serious issues and claiming features that nearly everyone benefits from are unnecessary.

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 requires a locked bootloader and supports using deveice attestation via the generic attestation functionality in the Android Open Source Project.

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

The GrapheneOS supporters are not on our sides, apparently. The seem to actually like remote attestation. They just don't like that they are not in on Play Integrity. But what is won if attestation includes official GrapheneOS releases but would still otherwise be exactly the same evil stuff that takes control of the user's device?

I still am hoping that at one point they understand the full consequences of remote attestation. There are some signs they start to notice, but it's slow...

GrapheneOS users can hold two opinions at the same time in a consistent way:

- Remote attestation is bad, anti-competitive, and reduces privacy.

- Given in a world where remote attestation exists, GrapheneOS should pass attestation, since there are no security reasons not to.

Both battles should be fought at the same time, because if governments do not want to ban remote attestation, you want to make sure that at least it's not in the hands of companies that abuse it to maintain their duopoly.

Focusing on only one of them can lead to worse outcomes.

Note that I am a GrapheneOS supporter. You seem to have a few misconceptions.

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.

My opinion: Any kind of attestation that is delivered to a non-user-controlled server about the state of a user's end device that the user (possibly using means outside of the end device) cannot change will be abused, e.g for anti-competitve purposes. I am hearing lots of arguments that grapheneOS is more secure (it is) and should therefore be included in remote attestation.

The pinning you are proposing, does it imply that there is again some certification of the "official" GrapheneOS, versus e.g. the user's own fork of GrapheneOS?

How would any of the existing proponents of remote attestation agree to anything like this, given what we consider abuse is exactly their reason of implementing it in the first place? Here, VW wants to stop use of the API by anything else than their App, in order to stop hobbyists and sell API access to commercial middle men. If the user could pin their own software's attestation or even register an arbitrary public key to cover updates, then the user would as well be able to code his own API client that just emulates the attestation. Is there any write up or discussion of the pinning you propose?

I am really not yet convinced how you want to counter the inevitable abuse that app developers and service providers will subject the user to if the OS security model gives them that kind of power over the user's end device.

To start, all attestation is remote. It fundamentally has to be remote, be it a server or another device.

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

GrapheneOS is based on the Android Open Source Project and retains near perfect android app compatibility. It cannot call itself android for legal reasons, but the legal definition does not affect its app compatibility.

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

The legal definition of the OS does not matter at all when considering the difference between failing to support something, and using a tool that explicitly stops something from working that otherwise works without issue. Play integrity is a tool which does not base any of its certification decisions in privacy or security, rather leverages it for anticompetitive reasons. This is known and trivially verifiable.

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.

You've made a lot of leaps. IF something were declared to be anticompetitive, it would be in the context of the provider of the service. There is no law or moral issue with Volkswagen using it.

You may disagree with the concept of Device Integrity, but it is a feature with plenty of history and demand. Companies want their services accessed from secure platforms for security, and this is not inherently anticompetitive.

The basis of your argument, that users want these developers to support another platform, does not make sense, because GrapheneOS does not require apps add explicit support for it. GrapheneOS has 99% android app compatibility.

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 maintains 99% android app compatibility. It does not require any additional funding or expenses to support GrapheneOS, and is actually more expensive to add these anticompetitive tools responsible for banning GrapheneOS.

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.

The funny thing is, nothing needs to be done to support GOS. GOS has 99% android app compatibility. The issue isnt that GOS requires changes in the app to support it, rather, the tools they are using explicitly ban non-certified OSs.

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.

GrapheneOS has an official partnership with a large OEM (Motorola), has near perfect app compatibility, is constantly improving upon user experience, and has been well known and regarded in the privsec community and by many trusted security experts. It appears to be gaining more mainstream awareness as a result.

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