It has been reported to Google (as a security bug) and to GrapheneOS as a comment in one of the very similar VPN leak issue on github. GrapheneOS has deleted my comment, probably because they assumed it was AI-generated or something, I've copied the report I sent to Google there.
It was believed to be an AI generated comment and the issue is already known. We solved it as part of VPN lockdown mode which means it isn't solved for profiles not using a VPN in lockdown mode yet. We could expand our already working approach to always be active but we were concerned about compatibility so we scoped it to VPN lockdown mode.
Since we're steelmanning, I would like to add a bit more.
GrapheneOS will never be closed source/proprietary because they believe code freedom (and user freedom by extension) is paramount. They have repeatedly said they don't have the resources to build a ChromeOS-esque firmware authentication and warning flow for ephemeral user-accessible root and support those builds alongside the existing production environment. They have NOT said it is something they have no interest in even discussing. They have also repeatedly said that where the utility is clearly demonstrated and can be architected in a maintainable way, they are open to contributions (and continued maintenance) that properly enable functions that people unnecessarily need to abuse root privileges for.
The main goal of their project is a system that can protect your personal thoughts, associations and memories to the best of its ability (against thieves, attackers, surveillance etc.) while preserving your interaction with the world. Current OSes (including GrapheneOS and iOS) are already far behind where they should be given the wealth of privacy enhancing technology, computer hardware security, systems engineering and OS design knowledge that has existed for decades- so their work is cut out for them and they are putting everything they have into leading the industry. Their hands are already full. For clear use cases the path of least resistance would be to contribute and commit to maintaining features everyone would benefit from.
If it is a feature/function someone understands they would benefit from personally but do not see the value to impose on others, we can circle back to the original fact which is that GrapheneOS is open source and can be bent/built to your will.
Very little if anything at all. Depends a bit how you draw the line between an app and the base OS.
Contactless payments dont work with Google Pay - but that is due to Google using attestatiom to check if the OS is GMS lincesed (GrapheneOS is not).
There are alternative contactless payment options that work fine.
There's quite a list you can get even from GrapheneOS's posts - among other things, there's a rather large set of apps that will outright crash when MTE is enabled.
GrapheneOS have mentioned wanting to expand the logging/intrusion detection capabilities of their Auditor app but contend with the need to include it as a system app which is against their philosophy (PoLP). It is not accurate to say they don't want to do anything about spyware.
They are also completely against Play Integrity as implemented on principle.
Could you please explain why supporting MTE/potentially EMTE in production as a goal represents a niche use case? Isn't mitigating memory corruption issues a mainstream ideal? How else would you propose to do it?
The OEM is Motorola. The partnership was announced earlier this year.
You are correct about them not getting early access from Google. There was a post within the last few months saying that Google no longer releases a lot of the code via git, but instead requires submitting a form and downloading the code via Google Drive. Google are actively trying to make third-party development difficult.
We are told the OEM in question is not Motorola, and it's likely some benefits of the Mototola partnership aren't yet in effect due to silly bureaucracy. Not sure there is any reason to lie about this.
Embargoed ASB patches started being used in release 2025092500, but I can't find now the message where a Motorola employee (confirmed by a community moderator, spring-onion, in a Side of Burritos interview) first reached out publicly on the GrapheneOS Discord guild about how to obtain further technical guidance than the requirements list in the website which claims to be non-exhaustive, in order to confirm such message's date. Still, GrapheneOS claims (after the partnership announcement March this year) that ASB patches are provided by (effectively) a distinct undisclosed OEM, really meaning an employee is leaking them. Maybe even the person didn't disclose the OEM they work for but they must be associated to one in order to have access to this material.
>For example they have stated they won't try to spoof SafetyNet because "we don't lie about security features"
They said they don't want to do it because it would stop working in the future when Google move to enforcing hardware-based attestation and it is not sustainable.
I have mentioned F-Droid many times in the official Matrix before they moved to Discord and not been banned. You might be misunderstanding what actually happened or have not asked the moderators why someone was banned.
>Citation needed. grapheneos themselves sure doesn't understand this
The GrapheneOS team understand full well that in cases where the Play Store does not allow installing an app on your device due to device or georestrictive rules you may have no choice. I have seen them mention this and acknowledge it first hand. What they do not want is for people to become satisfied with subpar solutions instead of striving for bare minimum privacy/security standards. They want a Play Store alternative front end to at least be able to guarantee you are receiving the right app you want instead of being a substitution attack risk. I don't think that is unreasonable.
>The official website has an install guide for google's background services, saying it's fine because it's in their security model.
The context is that before sandboxed-play-services were introduced people were sourcing APKs in unsafe/via unverified routes and having all sorts of problems with app compatibility because since GrapheneOS is a privacy project that do not accept sending copious amounts of data to one party with a mediocre privacy policy they included no Google services at all. sandboxed-play-services is a specific solution to the problem of apps being dependent on Google Mobile Services for functionality, and in that sense it is entirely optional. It was the best way for them to provide compatibility without destroying the privacy of their platform by introducing a privileged Google binary that can glean and abuse your production environment. It's reduced to the same level as any other app the user might choose to install themselves (which GrapheneOS want absolutely no say over as a user freedom protecting project).
GrapheneOS do not bundle any Google services in their official installation. They do not endorse Google's data collection and service practices. They do not believe Google tracking is fine in anyway, and the evidence is here: https://eylenburg.github.io/android_comparison.htm
What they have done is provide a workaround for people who have no alternative, while making sure it does not violate the device owners device in a special way compared to any other app they might install.
> What they do not want is for people to become satisfied with subpar solutions instead of striving for bare minimum privacy/security standards. They want a Play Store alternative front end to at least be able to guarantee you are receiving the right app you want
Aurora is a lot less invasive while achieving that same goal, but they recommend installing Googleware instead. Wouldn't the open source front-end be the "bare minimum" standard to strive for, with all the added tracking when installing GMS falling below that standard?
> It was the best way for them to provide compatibility without destroying the privacy of their platform
Again mixing up threat models and equating it to privacy. It may not compromise the technical security (as GrapheneOS goes to incredible lengths to point out while implying that this covers everything), in that it doesn't allow Google to access data on the device that Android's security model says they shouldn't have, but Android's security model isn't my threat model. My threat model, and many other people's, includes Google tracking me. If nothing else, the servers can always see which IP addresses I pop up on together with other people and build a social graph if they wish (or if they're ordered to)
By just grabbing the apk files from their servers whenever I open aurora.apk, that issue can be almost entirely avoided, for example. There's the matter of microG but just to show that there are easy wins to be made that work for a lot of apps already (that don't depend on the rest of the framework) that GrapheneOS vehemently opposes 'for security'
It's not strange that they offer a way to install GMS in a secure manner, it's strange that they don't recommend open alternatives where possible
And you're surely aware of the obvious bias of that link you shared. It's like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. Whoever made that takes GrapheneOS' statements at face value and assumes it must be great. And that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one can outweigh all others
>Aurora is a lot less invasive while achieving that same goal, but they recommend installing Googleware instead... GrapheneOS vehemently opposes 'for security'..
It's more accurate to say they suggest improvements not vehemently oppose. The community/project have opened issues with the Aurora Store project to get them closer to that goal of making sure the app downloads cannot be intercepted https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/697 and mitigating the TOFU problem by ensuring the first install is definitely the one the developer distributed via Play https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/1177
This is what I meant by standards. They only suggest Play Store because it is an existing solution that already meets those standards.
>Again mixing up threat models and equating it to privacy. My threat model, and many other people's, includes Google tracking me.
GrapheneOS are very conscious of avoiding sending data to Google where unnecessary. The evidence of that is in the link previously shared, but also in third-party reviews like https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter...
They also do advise that if you want to avoid Google's gaze you should explore non-Play Store apps if they can meet all your needs because Play Store apps are extremely likely to include Google libraries and dependencies that expose even more data to Google. Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store. I believe that from their perspective it takes a lot of careful consideration and planning to avoid exposing data to Google. This consideration and planning would never end with just Aurora Store so hopefully you can understand why they would not recommend it as a well thread-modelled privacy solution for Google. Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically. Does my explanation make sense?
>... like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. ...that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one can outweigh all others
I agree. Checklists are a bad way of conveying verified information and importance of each feature, and I do think the table can be improved. Thankfully it is open to contributions from Github account owners.
The first ticket you link is not by someone who seems to work on GrapheneOS, at least there's nothing in their profile to suggest as much. The improvement they suggest is hardening, preventing basically nation state attackers who either compromise or compel a CA to issue a false certificate for Google's servers
The second ticket is about checking if the data that Google sent via TLS has a second signature from Google. It doesn't prove what you claim about ensuring the key is from the developers. This is more useful for places like apkmirror that distribute apps and could include the signature that Google tacked on, for people who trust but cannot use Google; to verify Google's signature without needing to be able to connect to Google. That's not what Aurora does, so it's not relevant to the project. Can be defense-in-depth in case Google's front-ends are compromised but the signing back-end is not, but again, that's less likely than getting struck by lightning and such a powerful attacker could also just compel the developers to make a special update that performs malicious actions on their target
This is the level of misunderstanding that I find very common among GrapheneOS users btw: it all sounds good if you don't know much about it, but when you drill down to what it actually does and consider a specific threat model, it's no reason to recommend Google Play over Aurora for 99% of people's threat models. If you're an oppressed journalist in Iran or whistleblower in the USA, then the cert pinning could help, but most of us are more impacted by everyday tracking than by targeted nation state attacks
> Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store.
I'm probably misunderstanding you, but nobody said downloading an app via Aurora changes the contents of the download to become privacy-friendly. Like, downloading a .exe via an open source browser also doesn't change the download compared to if you download it with Google Chrome
You still have to be wary of what you download, deny it internet access if applicable, etc. It's just that you don't have to have google's stuff running in the background all the time, toggling internet access on (letting it upload queued telemetry) anytime you want to download or update an app that is distributed only via google
Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
> Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically.
What do you mean by nonsensically? I didn't know they recommend it under any circumstance though, that's cool. Do you happen to have a link for that, or remember where they wrote that?
>preventing basically nation state attackers who either compromise or compel a CA
I don't think the compromising, self-compromise or compelling of a Certificate Authority is a feat reserved for state-level attackers. I am not sure why it would exclude any malware that gains enough privileges, or existing campus-enterprise mobility management apps/parental control/antivirus that get compromised or hijacked. But really it comes back to one of the original points which was that GrapheneOS are comfortable recommending and promoting solutions with a high level of security/privacy as a general rule.
>The second ticket
Yeah, I believe I confused the 'frosting metadata' part with the important whole APK Signing Block. The part I wanted which the app store client should verify would be the signing certificate hash which you compare to what the server says the package should give you. As far as TOFU mainstream users basically trust in Google's Play Security & reviews process instead of developer signing certificates/keys because most developers do not publish that out-of-band somewhere they individually control. Widget on Dev's Socials/Site + Publishing hurdles + Developer Console auth + Google security/review add up to a non-zero chance the listing is good. When you get the app you have the benefit of certificate pinning and app signature verification to make sure that non-zero isn't majorly reduced in distribution/transit.
GrapheneOS don't even recommend getting apps from Play anyway if you can verify and source the apps directly from the developer.
>very common among GrapheneOS users btw
Can't say anything for your experiences, but of course I only speak for myself. I can say though that the GrapheneOS developers themselves will never tell you the OS is specifically for high-risk oppressed journalists and whistle-blowers. Another big disconnect is that GrapheneOS believe things need to be much more attack/abuse-resistant for the 99% than they are now, so asking them to aim a little lower than current standards will cause a lot of misunderstandings: https://xcancel.com/GrapheneOS/status/2044440381803069778#m
>You still have to be wary of what you download, deny it internet access if applicable, etc. Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
I agree mostly with this, but I think you can see it would be a bit painful and tedious for GrapheneOS to say "We can't endorse violating Google's TOS but Aurora Store is an option under specific circumstances and technical conditions. Apps from Play/Aurora may not contain any Google libraries, GMS dependencies or involve sending data to Google as potentially stated in their privacy policy but there is no accessible way to determine this per-app at a glance." every time they need to talk about Aurora Store.
>Do you happen to have a link for that, or remember where they wrote that?
reply