Notices by GrapheneOS (grapheneos@grapheneos.social), page 2

Play Integrity API is highly insecure and it isn't particularly hard to temporarily bypass it. There are frameworks for spoofing the software checks and leaked keys for bypassing hardware attestation can be purchased. However, bypasses are getting harder and are becoming increasingly short lived.

It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source.

Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security.

Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them.

GrapheneOS isn't vulnerable to the 3 recently disclosed Linux kernel vulnerabilities named Copy Fail, Copy Fail 2 and Dirty Frag. Current Android Open Source Project SELinux policies block exploiting all 3 bugs. Standard AOSP GKI kernel configuration also has 2/3 of the vulnerable features disabled.

@becomethewaifu That's why we only mentioned it being the chosen attack vector for exploiting it. It's a common attack surface and attack vector for exploits which is why it was removed from Android. It's the SELinux policy disallowing access to AF_ALG outside of dumpstate which blocks exploiting it along with a standard GKI not having the userspace crypto API enabled. AOSP, stock Pixel OS and GrapheneOS don't have the relevant API enabled at all though, which we didn't realize until today.

GrapheneOS is immune to the Copy Fail vulnerability due to the deep integration of SELinux in the Android Open Source Project (AOSP). AOSP only permits using specific types of sockets throughout the OS. It only permits the dumpstate process used to create bug report zips to access AF_ALG sockets.

@aral @Framasoft @fla @aral @Framasoft @fla We've already posted numerous replies addressing why the statements they're making about GrapheneOS are extremely inaccurate. Mots of it hasn't been acknowledged. The only part which was acknowledged is the existence of Contact Scopes. Nothing has been done about the egregiously false claims of GrapheneOS not being a privacy project and not working much on privacy. It's completely backwards and in fact applies to what they're trying to promote instead.

@aral @Framasoft @fla He made one small correction. However, the article is still claiming GrapheneOS isn't a privacy project and that we don't work much on privacy which is thoroughly wrong. GrapheneOS has a bunch of major privacy enhancements both through adding important privacy features and fixing Android privacy vulnerabilities including VPN leaks. We have multiple privacy features and additional VPN leak fixes in progress. We posted a thread responding to that at https://grapheneos.social/@GrapheneOS/116382616003990894.

@aral @Framasoft @fla There's a comparison between AOSP-based operating systems at https://eylenburg.github.io/android_comparison.htm which has comparisons of privacy features and default connections. It's far from complete and only covers default connections which come from AOSP. /e/ adds multiple additional connections to Google not present in AOSP by default along with other problematic connections. They've made decisions such as adding a random unique ID to their update client connections, etc.

@aral @Framasoft @fla The most egregious inaccurate claims made about GrapheneOS haven't been addressed. Nothing has been done about the content of the podcast itself.

It's also important to note there are widespread attacks on the GrapheneOS project and our team which are largely tied to Framasoft including using their Mastodon instance. Framasoft's Mastodon instance has been a massive source of attacks on the GrapheneOS project and team including harassment for quite some time now.

@aral @Framasoft There hasn't been any correction to the outrageous claims made by @fla that GrapheneOS isn't a privacy and isn't doing much about privacy. That's extraordinarily inaccurate and dismisses the massive amount of work we've done to advance privacy. Meanwhile, he's promoting operating systems which haven't done similar work to advance privacy. They aren't fixing VPN leaks, aren't implementing comparable privacy features and don't keep up with standard privacy patches/protections.

@aral @Framasoft He directly responded to the thread we published 4 days ago addressing Murena once again claiming the kind of privacy and security hardening work done by GrapheneOS and iPhones is only useful to criminals and spies. In that thread, we directly addressed these repeated inaccurate claims about the purpose, goals and approach of GrapheneOS which wrongly portray it as a security project rather than a privacy project. His claims in the interview are more than egregiously inaccurate.

The claims made about GrapheneOS in this interview are extremely inaccurate. It heavily misrepresents the purpose of GrapheneOS and what we've worked on for years. The claim GrapheneOS is a security project rather than a privacy project is misinformation. Contacts are specifically brought up and yet our Contact Scopes feature is ignored. @fla knows GrapheneOS is a privacy project. He replied to a thread with our response to this misinformation only 4 days ago...

https://piaille.fr/@projetslibres_podcast/116379561169492214

> with the mail or the telephone, we want to change that. So we are making you a product that changes that by default for anyone.

Transcription in French:

> Il y a la surface d'attaque, là pour le coup on est pas des spécialistes de la sécurité, donc je ne pourrais pas te répondre avec précision, mais des discussions que j'ai eu, il semblerait que tout ce qu'on fait, ça réduit la surface d'attaque. Donc oui, probablement ça aide. Par contre, on a pas une approche "sécurité durcie", on développe pas un téléphone pour les pédo(bip) pour qu'ils puissent échapper à la justice. Donc il y a pas des trucs pas possibles pour voir

> si la mémoire est pas corrompue, des trucs de sécu vraiment durcis qui pourraient être utiles clairement pour des dirigeants, dans les services secrets ou que sais-je. C'est pas notre but, notre but c'est de partir d'un constat, aujourd'hui nos données personnelles sont pillées en permanence et ça serait pas légal dans la vraie vie avec le courrier ou le téléphone, on veut changer ça. Donc on vous fait un produit qui change ça par défaut pour n'importe quelle personne.

GrapheneOS exists to protect users from having their privacy invaded by arbitrary individuals, corporations and states. Privacy depends on security. GrapheneOS heavily improves both privacy and security while providing a high level of usability and near perfect app compatibility.

> we do reduces attack surface. However, we don't have a "hardened security" approach, we aren't developing a phone for pedo(censored) so they can evade justice. So there aren't difficult things to check if the memory is corrupted, really hardened security stuff that could clearly be useful for executives, in the secret service, or whatever. That's not our goal, our goal is to start from an observation: today our personal data is constantly being plundered and that wouldn't be legal in real life

Gaël Duval is the founder and president of the /e/ foundation along with the CEO of Murena. Duval and his organizations have consistently taken a stance against protecting users from exploits. In this video, he once again claims protecting against exploits is for only useful pedophiles and spies.

Translation to English:

> There's the attack surface, on that front we're not security specialists here, so I couldn't answer you precisely, but from the discussions I've had, it seems that everything