GrapheneOS Profile picture
May 17, 2025 14 tweets 3 min read Read on X
Similar to iOS lockdown mode, Android 16's Advanced Protection feature is misguided. It adds security features exclusive to it which require using all of the other features. This prevents people using new security features if they need to avoid 1 feature.

security.googleblog.com/2025/05/advanc…
Most of the features already existed. The new ones are cloud-based intrusion logging, inactivity reboot (hard-wired to 72 hours), a new mode of USB protection and disabling auto-connect to a small subset of insecure Wi-Fi networks. Production MTE support is also essentially new.
GrapheneOS added locked device auto-reboot in July 2021. We proposed it to Google for Android in January 2024 as part of reporting exploitation by forensic data extraction companies. They implemented several of our other proposals, but not this until iOS added it in October 2024.
Both GrapheneOS and iOS enabled lock device auto-reboot by default, at 18 and 72 hours respectively. It can be set between 10 minutes and 72 hours on GrapheneOS along with having an opt-out. Putting this behind a feature barely anyone will use makes the real world impact minimal.
Advanced Protection mode support for the ARM Memory Tagging Extension (MTE) is misleading. It won't be using it for the kernel, most of the base OS or 99.999999% of apps. It will only be enabled for certain base OS components and a tiny minority of apps explicitly enabling it.
Certain apps like Molly opt-in to MTE, but this doesn't really do anything since so far Android isn't providing any production MTE support. This tiny minority of apps enabling the feature will finally have it on certain devices for < 0.001% of users using Advanced Protection.
Chrome / Chromium provides a very misleading "V8 Optimizer" toggle which contrary to popular belief does not disable the Just-In-Time compiler and therefore cannot block dynamic code generation. It's not a default JIT disable like iOS lockdown mode or default GrapheneOS.
Chrome's "V8 Optimizer" toggle started out as a JIT toggle. However, Chromium's WebAssembly support currently requires JIT and they quickly crippled the setting in an emergency update. It now only disables the highest 2 tiers of the JIT, so a lot of the security value is missing.
Microsoft implemented a simple WebAssembly interpreter for Microsoft Edge as part of their earlier JIT disable feature. Microsoft submitted their WebAssembly interpreter to Chromium and got it merged after a long time. Chrome / Chromium doesn't use it, maintain it or test it.
Since they aren't maintaining or testing it, other Chromium-based browsers can't use this feature without taking on the responsibility of maintaining it. Google could easily start maintaining it to fix their very misleading "V8 Optimizer" toggle but so far has neglected to do so.
It's entirely possible to provide the new security features standalone and then group them together in a mode enabling all of them, but with the option to disable certain features. That could then show up as a warning that the mode isn't fully enabled. Instead, they copied iOS.
Apple chose a poor design for lockdown on iOS to due to an aversion to adding settings. There's little reason for Android to copy this. Android already had most of the features as standalone options. Gatekeeping features behind a badly designed Apple approach makes little sense.
Part of enabling Android's Advanced Protection feature is disallowing users from installing apps from outside of the Play Store. This can currently be bypassed using Android Debug Bridge via developer options, but that's awful for security and they'll likely crack down on it too.
Apps coming from the Play Store doesn't make them trustworthy, safe or secure. Most malware apps on Google Mobile Services devices are installed from the Play Store. Similarly to the Play Integrity API, it's Google reinforcing their monopolies with security as an excuse for it.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with GrapheneOS

GrapheneOS Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GrapheneOS

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

SELinux is based on explicitly listing out everything that's permitted and anything not listed isn't allowed. AOSP uses strict, fine-grained SELinux policies for the whole OS. Instead of simply permitting everything that's used in a fine-grained way, the rest of the OS is developed with it in mind.
Android makes extensive use of neverallow rules to define and enforce the security goals for the SELinux. Since SELinux uses an allowlist approach, neverallow rules don't directly disallow anything at runtime but rather prevent creating rules violating the constraints. It does this for socket types.

Here's where Android defines a neverallow for many types of sockets including AF_ALG for regular sandboxed apps:

android.googlesource.com/platform/syste…

Android has a versioned app sandbox which gets stricter for new API levels. The versioned domains inherit from that untrusted_app_all domain.
Android's usage of SELinux is drastically different from mainstream desktop and server Linux distributions where it's only lightly used in a very targeted way. This is a nice example showing how it massively reduces Linux kernel attack surface on AOSP-based operating systems including GrapheneOS.

Android splits SELinux into system and vendor policies. Both of these must conform to the extensive neverallow rules. The vendor policies are defined as part of implementing hardware support for a device and permit what's required by the drivers. Most of the driver code is sandboxed userspace code.

Android extended SELinux with support for ioctl command allowlists to reduce kernel attack surface. These ioctl command allowlists are used for sockets and many other core kernel devices to limit attack surface. It's also used with drivers in the vendor policies such as GPU ioctl command allowlists.
Read 6 tweets
Apr 20
We've added a JSON API making it easier for services to permit GrapheneOS in addition to Google-certified operating systems:

grapheneos.org/attestation.js…
grapheneos.org/attestation.js…

The verifiedBootKeys array lists GrapheneOS key fingerprints to permit via Android hardware attestation.
It can be extended with a list of key attestation root certificates once we have devices using an alternative to Google's Android key attestation ecosystem. Each of will have their own certificate revocation list for apps to check if they care. There's no need for anything more.
Apps which are forced by regulations or liability reasons to implement integrity checks should use the standard Android hardware attestation API. The Play Integrity API is insecure and anti-competitive. The Play Integrity API creates massive legal liability for the apps using it.
Read 10 tweets
Apr 11
/e/ and Murena have been been promoting their products by misleading people about GrapheneOS for years. This has turned into an all out war on GrapheneOS by their company and supporters. We began regularly debunking their inaccurate claims and they try to frame it as aggression.
They've created widespread misconceptions about the GrapheneOS project with inaccurate claims about the purpose of the project and what it provides to users. Many people incorrectly believe they aren't our target audience or that it wouldn't be a good fit for them due to this.
GrapheneOS is a privacy project which is intended to be usable by everyone. Usability and app compatibility are top priorities. Our userbase largely isn't highly technical. It's very easy to install and use. Devices can be purchased around the world with GrapheneOS preinstalled.
Read 26 tweets
Apr 5
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 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 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.
/e/ has far worse privacy and security than the Android Open Source Project. They fail to keep up with important standard privacy and security patches for Android, Linux, firmware, drivers and HALs. They fail to provide current generation Android privacy and security protections.
Read 24 tweets
Mar 27
GrapheneOS started in 2014 and was originally named CopperheadOS. In late 2015, the Copperhead company was founded which was meant to support the project. Copperhead didn't create CopperheadOS and didn't own or control it. Copperhead made a failed takeover attempt on it in 2018.
GrapheneOS still has the original CopperheadOS repositories on GitHub. Copperhead seized a bunch of the project's infrastructure and accounts. They created a closed source fork of GrapheneOS called CopperheadOS after the split which was not the same CopperheadOS as the original.
Copperhead remained entirely dependent on GrapheneOS and had to keep forking our code for each major Android update. Despite depending on GrapheneOS, they waged a war against it trying to destroy the project and attempting to ruin the lives of our team, especially our founder.
Read 11 tweets
Mar 26
There are at least a dozen people spending at least several hours attacking GrapheneOS across platforms on a daily basis. It's a very strange situation. How do these people have so much time and dedication to keep making posts across platforms attacking us? It's relentless.
Every day, dozens of new accounts join our chat rooms to spread the same fabrications about GrapheneOS including via direct messages.

On Hacker News, one of the accounts making personal attacks based on fabrications in most threads about GrapheneOS has been doing it for 8 years.
Y Combinator (@ycombinator) has a financial stake in numerous surveillance and exploit development companies. Hacker News is a platform they own and the moderators on it have permitted years of vile harassment towards our team which they'd normally remove if others were targeted.
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(