I mean for the Microsoft Android phones it kinda makes sense, since they're not exactly shipping Android by choice. They'd much rather you use the Windows Phones which this says ARE locked down.
Apologies for being unclear, it's true Microsoft didn't have the option of Windows Phone for their Surface Duo devices, so they had no choice but to use Android. To clarify, when I phrase something as being an unwilling outcome it does not mean both were equally viable options and they picked the one they wanted, rather that Microsoft's hand was forced due to this development. I hope this helps.
They mix up Google-vendor (pixels are absolutely the best and most unlocking-friendly hardware at this point), with Google Play Services services/limitations (ie dominant player in android ecosystem) AND Google, the dominant contributor to AOSP project.
And it's also partially false, as Gemini works just fine after unlocking/relocking, and all the advanced features (full performance of the cameras, NPU access, secure element) work even on non-Google OS. Things that do not work (mostly wallet) are valid issue, but then again, they work just fine after flashing OEM firmware And relocking The bootloader.
So I can only guess the quality of the contribution is similar with other phone brands.
Unfortunately, it's hard to make Fairphone secure. No separate secure element (so much easier to do brute force PIN attacks) and always lags in monthly security bulletin patches and major OS releases (remember that the monthly patches typically only address high/critical vulnerabilities, for the rest you need OS updates, QPRs, etc.).
Until Graphene works out the deal with the OEM that they are talking to, Pixel is pretty much the only secure phone that allows installing alternative firmware.
We're working with a major Android OEM and it's going well so far. It's still in an early phase where they've assigned a small amount of resources to it to determine everything which needs to be done and then make the case for a much larger investment of resources. We expect that to happen and for it to go well.
As someone else mentioned, GOS requires that the bootloader properly support relocking with a custom key. Additionally, GOS has a rule that any device supported must keep up with all security and quarterly patches in a timely manner, and none of the Fairphone devices do.
No secure element, no memory tagging support, no proper cellular baseband isolation, no verified boot, taking months to ship security updates .. the list is long.
From a security/privacy perspective the fairphone is on the worse side of options unfortunately.
> From a security/privacy perspective the fairphone is on the worse side of options unfortunately.
Compared to Pixel phones this is without a doubt true, but how does it compare against your average mid-range Android device? Do those typically have any of the features you mentioned?
Very roughly, and assuming mid-range is around 400-500 bucks like the fairphone:
- Memory tagging is still pixel exclusive for now, but it's part of ARMv9 so it should be available on more devices in the future unless they disable it
- Most devices now have a secure element, though the exact capabilities vary
- Baseband isolation - no idea really, most chipsets should support IOMMU (or SMMU as ARM calls it) but is not very obvious if that's setup sanely or even used at all on your average device. So I'm guessing most devices are about the same.
- Security patches certain vendors are much better (like Samsung, for their non-budget devices anyway) but a lot do much the same. It shouldn't generally be worse because of Google's requirements.
Memory tagging isn't Pixel exclusive anymore. Fairphone doesn't lack baseband isolation since it's a standard Snapdragon feature. Fairphone is worse than many OEMs at providing the standard security features and patches. Repeatedly using publicly available signing keys meant for testing for signing their OS is one example which has hopefully been fully addressed for the latest device.
Only having 16 possible tags doesn't impact the deterministic protections we provide. One of the tag values is reserved for free data, internal metadata, etc. and can also be used as a form of 16 byte guard page. For heap allocation, we also dynamically omit the most recent adjacent non-free tags and the previous non-free tag for the current slot. There are 15 possible random values but 3 are dynamically omitted.
An attack often needs to use multiple invalid memory accesses where each one would have a 1/15 chance of success from probabilistic MTE alone. MTE gets combined with other probabilistic memory allocator protections. Our main memory allocator also has slot randomization and quarantine randomization.
A future revision of MTE could be easily be increased to 8 bits and it paves the path to having much larger memory tagging in the future too.
For people out of the loop, parent is referring to TikTag[0], a side-channel speculative execution attack breaking MTE in a probabilistic defense scenario, and the weird cope coming from some people that "MTE was only supposed to be a debugging feature anyway".
However, you need some form of code execution beforehand already for this attack, and more importantly it doesn't affect any of the deterministic guarantees of MTE. And those are the main appeal to GrapheneOS in the first place, preventing things like use-after-free by tagging the memory such that it simply can't be accessed anymore. So it's very much a security feature.
The number of combinations is irrelevant if you're not relying on randomness. Graphene sets the tag to a static value on deallocation[0] to prevent use-after-free, you don't even need to guess! The same is true for a lot of buffer overflows, as their allocator ensures two adjacent allocations have different tags, so unless the vuln allows you to skip ahead you'll always trigger a fault.
We use the standard reserved tag (zero) for freed data but we also dynamically exclude the previous non-free tag for the current slot and the most recent adjacent non-free tags (i.e. the current tag for the adjacent slots or the previously used on if they're currently free). This provides a lot of deterministic protection against use-after-free especially when combined with our quarantine. It provides full deterministic protection against small or linear overflows. The fallback to probabilistic protection with 15 random values is still very valuable and does not mean only lowering exploit chance to 1/15. An exploit can require multiple invalid memory accesses. Side channels for leaking tag values aren't inherently usable in every case and an attacker can't simply choose the memory layout.
MTE mainly exists to catch the initial memory corruption in the first place rather than to protect specific targets from memory corruption. The current limitation of only having 16 possible tag values makes the fallback to probabilistic protection fall weaker than it could be but it's still very useful and multiple invalid memory accesses are often required. An invalid read is protected against as much as an invalid write. ARM acknowledged the issue of side channels able to leak side channels in certain circumstances and that's being addressed for newer hardware. Bear in mind side channels can be used to directly leak sensitive data too and it's a huge class of issues not specific to memory tagging.
I can't find the link, but a couple days ago, they said in a thread here it was due to their lack of support of some important security features, and remarked that it didn't look like they were even interested in supporting them.
Yeah, otherwise the bad guys can just wait till you're not looking at your phone, reflash your it with a backdoored version, and wait for you to unlock it (evil maid attack).
If your phone was in hands of police you better sell it anyway because they could install a physical GPS tracker, etc. So locked bootloader doesn't change much.
Also if you live in a truly democratic country you don't even need to set the PIN code - your rights are protected by the law.
It would be relatively difficult to add a physical GPS tracker to a modern phone. Also, it's unnecessary, the government just needs to take a note of the IMSI and/or IMEI and then use the cell tower records to track you (rather accurately I should add).
The problem is not the tracking inherent in the design of mobile telephony networks, which you can circumvent by using burner phones. The problem is for example abuse of tools such as cellebrite to gain warrantless access to your phone at various opportunities.
This is also why proper baseband isolation is important. Baseband firmware is unaudited and likely to have government backdoors.
If the government wants to surveil me, they'll have to put in some actual effort instead of just taking opportunities.
As others have said they have some security concerns (I don't know enough about that stuff to know how justified or surmountable those concerns are). However with the big manufacturers all locking down their devices more than ever I wonder will they have much of a choice in the end. We're going to need a manufacturer (or preferably several) to actively stand behind the possibility to use custom ROMs, and at the moment Fairphone seem like the only one who might do that.
The curious thing is that being GrapheneOS open source, I would think that somebody could potentially create a ROM for them, even if it is not as secure as GrapheneOS would like. However, absolutely nobody has done it yet...
AXP.OS (axpos.org) is LineageOS-based (formerly DivestOS-based), but includes security backports from GrapheneOS and CalyxOS. No doubt it is less secure than GrapheneOS, but surely more secure than LineageOS, and supports bootloader relocking on some devices.
It's not a security upgrade over current AOSP overall and is definitely not a port of GrapheneOS to other devices. Someone could make a partial port of GrapheneOS to other devices but this is not that.
> but includes security backports from GrapheneOS and CalyxOS
It has a small portion of the GrapheneOS features, similar to DivestOS before it. However, it's not preserving or restoring the standard security reduced by LineageOS as much as DivestOS did. DivestOS was not a strict upgrade over AOSP either.
CalyxOS isn't a hardened OS in the same space as GrapheneOS. It doesn't have similar exploit protections or privacy features. That's a misconception about it. They also haven't provided the June 2025 patches yet.
This doesn't imply it's as secure as AOSP though despite having additional security features. Starting from LineageOS as the baseline and adding more problematic changes makes it much messier than it just being AOSP with added security features. Android 16 is required for full Android privacy/security patches and the current privacy/security improvements. Soon there will be Android 16 QPR1.
So, notice Graphene OS was able to port Android 16 on all the supported devices (from Pixel 6 up) basically within a week without device trees already, without the early (OEM) access to the release.
It's a big inconvenience but not a showstopper for them. Pixels are still viable.
The only blocker with pixels would be if they stopped allowing OEM unlocking or relocking (which is a must).
> Even Graphene OS reported that they're in talks with some vendor... Have there been any updates towards that?
The startup we were working with before went bankrupt. In June, we started working with a major Android OEM which has provided resources for identifying everything which will need to be done to meet our requirements and provide official GrapheneOS support. They believe they can meet all our official requirements without much trouble and they're going to determine how much resources they want to put into it soon. We don't yet know how many resources are going to go into it.
> The main reason i used to root devices are
Note using GrapheneOS does not involve rooting.
> System level adblock using adaway
You can use RethinkDNS for filtering combined with still using a WireGuard VPN or multiple chained WireGuard VPNs. Android has a perfectly good API for this.
> Titanium backup
GrapheneOS has a built-in encrypted backup system we plan to significantly improve upon. The basics are there already.
Samsung has been doing this for a while now.
Which are the devices/vendors that still allow / encourage this?
Even Graphene OS reported that they're in talks with some vendor... Have there been any updates towards that?
The main reason i used to root devices are:
* Get longer support/OS updates than what the vendor provided
* System level adblock using adaway
* Titanium backup
These days firefox/brave browser gets me half way through adblocking and i lost interest in the ad filled apps..
Syncing gets me good level of syncing for backup on my NAS etc .