The perception that they are able to run rings around Google is not necessarily an accurate one. There are tradeoffs in any engineering situation and GrapheneOS devs make different ones based on different requirements. Google is one of the reasons MTE even exists. I don't think GrapheneOS devs would be capable of helping push forward that technology in the same capacity.

Fair, and also Google is not a monolith. I’m sure that their own security experts who helped push things like MTE are also confused and frustrated by the lack of internal adoption.

A lot of heavy lifting is involved at the lower levels of security and Graphene doesn’t have to deal with this work, generally. I guess my surprise comes at the “fit and finish” stage where Google regularly seems to be lacking.

Do we know if Google is operating on the frontier of the trade-off curve? What do we lose from Pixel Android when GrapheneOS security changes are made?

Google's spyware (Play Services) ceases to work normally and Graphene had to patch it to run as an unprivileged app. So that's one "loss."

I personally don't bother with Google dependencies at all. If an app requires them to work, I will do without it.

Actually functionality, stability of apps and features people use.

What functionality and features are lost in the base Pixel OS (not apps) as a direct result of GrapheneOS's changes to AOSP?

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.

Moving the goalposts to "it's not their fault that it doesn't work" doesn't really change it doesn't work.

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.

Could you list a couple of the biggest functionality losses from AOSP due to GrapheneOS changes? I might be misunderstanding what you mean.

Elsewhere in the thread, someone reports that with MTE enforcement enabled, there are lots of crashes. And app and system service developers don't seem responsive to them.

That's not something that's really acceptable on a $500+ phone... so if you're Google, you're not going to turn that on by default and you're not really going to be interested in keeping it as a feature that users can turn on.

Graphene has a different focus, so they can push the tradeoff towards enforcement and crashes rather than non enforcement and fewer crashes.

Google could perhaps do more with their crash logs and pushing app developers to fix MTE crashes, but they don't often do a lot of that; and they get called out for being developer unfriendly when they do enforcement.

That was partially true a couple years ago that there were some crashes related to it. It is absolutely not the case anymore.

Why not force it on an API change? It wouldn’t be the first time there was a breaking change.

Because it (anecdotally) crashes too much, but only on $$$ devices with cool CPUs that can use it. People buy expensive phones because they're supposed to work better.

They should really do some sort of sampling thing to generate crash dumps and find big offenders and increase the coverage over time.

For Google employee devices, 0.1% of background execution starts while charging in an idle period (overnight bedtime charging) will use MTE. When any specific device hits an MTE crash, back-off sampling for 1 week on that device. Modulate the sampling rate so crashes are manageable.

When Google employee devices are not crashing overnight at a high rate, then start sampling background execution during the day for employees and overnight background execution on general user devices. Finally, sample on foreground execution, again for Google employee devices first.

If there's significant variation in crashes by app, you probably need to setup a way to set sampling rates to zero or very low for application versions that have been identified as a known problem and don't need additional traces.

I wonder what causes the crashes. Is it a buggy MTE implementation (or buggy hardware), or are app devs doing something that would only cause crashes under MTE? Maybe it’s something they are using like a library or framework?

Its buggy apps. Ive been using MTE for pretty much all the apps on my GrapheneOS phone for 3 years without any problems.

2 apps have C++ libraries and MTE makes these crash due to memeory bugs, so I disable MTE for these.

There's a lot of speculation that US model censorship around "cyber capabilities" is about protecting an inventory of non-public vulnerabilities used for intelligence purposes. That same explanation could cover Google's MTE actions as a result of pressure from intelligence agencies. Nobody should be surprised if they prioritize what they see as national over personal security.

>Almost makes you wonder if some of those vulnerabilities are intentionally allowed to exist.

the fact that someone can say that post-Dual_EC_DRBG/project-rubicon/eternalblue/eternalromance exposure boggles the mind.

Since GrapheneOS is building on something that Google is giving away for free, I do hope that they release something better. Everything else would be.. kind of weird, no?

What do you mean? Graphene is also free software and everyone including Google can use it and learn from it.

Just to nitpick, the facilitation by AOSP & ARM is available so it is not about the OS but about Google as a Hardware manufacturer.

They're running rings around google... by enabling features that google develops/support?

99.9% od the code GrapheneOS uses and 100% of hardware (including one like Titan security chip handling storage encryption and key store) is from Google.

So what are you on about man - it's easy to take someone else's work and put tweaks on it that wouldn't work at scale.