GrapheneOS Profile picture
May 17 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

Jun 18
@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ is what we recommend for a comparison but it does not compare to iOS. iOS has a lot more substance behind the privacy and security marketing than nearly any niche products/projects though. iOS does get targeted more right now but that's not all bad.
@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ You can see from that GrapheneOS is not only on the radar of companies developing exploits but they put work into trying to support it. If there's something successfully protecting people and it's gaining adoption, effort will be put into exploiting it.discuss.grapheneos.org/d/14344-celleb…
@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ The back and forth between attackers and defenders results in increasing security and more difficult exploits. Platforms like iOS and AOSP or Pixels and iPhones putting lots of effort into doing better and defeating attacks have ended up way ahead of those not targeted much.
Read 5 tweets
Jun 12
We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run GrapheneOS () and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost.grapheneos.org/faq#future-dev…
In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early.
We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release.
Read 21 tweets
Jun 11
In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable (). Android 16 launched today and porting is going to be significantly more difficult than we were expecting.
We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports.
Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making GrapheneOS devices sooner than we expected.
Read 6 tweets
May 29
Our Contact Scopes and Storage Scopes features provide essential privacy functionality that's missing on standard Android. Scopes are a replacement for the standard contacts, storage and media permissions. We offer these as an alternative when apps request access to any of those.
When you enable Contact Scopes or Storage Scopes, GrapheneOS makes the app believe you've granted the requested permissions. However, it doesn't receive access to any more additional data not created by itself. Most apps work by simply enabling these without doing anything more.
For Contact Scopes, you can choose to give the app read access to a subset of the data for specific contacts. For more convenience, we support grouping contacts together and granting access to a group. It's very useful even without granting access to anything to pretend you have.
Read 17 tweets
Apr 25
@MishaalRahman Android 12 API for this will stop most of Cellebrite's current attacks since they target Linux kernel USB peripheral drivers. However, they could switch to targeting the Linux USB-C protocol implementation which doesn't get disabled by the Android 12 API, only high level drivers.
@MishaalRahman By default, our feature blocks new connections in both software (similar to the standard toggle) and hardware but allows existing connections established while unlocked to continue. Once those end, it disables USB-C and pogo pins data (USB-C is more than USB) at a hardware level.
@MishaalRahman The approach of allowing existing connections to continue in the default mode allows us to have it enabled by default. Users can set it to a stricter mode for higher security. Charging-only mode is the next stricter setting disabling USB connections and data all of the time.
Read 4 tweets
Mar 27
@matthew_d_green Signal itself is not hardened against attacks. It doesn't use sandboxing for media or WebRTC. Chromium-based browsers run those in the renderer sandbox, Signal simply runs them unsandboxed as part of the rest of the app. It doesn't use more than basic exploit protections, etc.
@matthew_d_green Signal for Android is at least almost entirely written in memory safe code (Kotlin and Java) with lots of dependencies not having memory unsafe code, but media handling and especially WebRTC are not particularly secure. Signal is not currently putting much effort into this area.
@matthew_d_green Even if you're not sharing your phone number or opening any links, there's plenty of attack surface via Signal itself. Opening links in a browser would also be generally safer than simply accepting a call via Signal, which is Chromium WebRTC with imperfect updates and no sandbox.
Read 4 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!

:(