Well, the security coprocessor on every iPhone and Mac runs a formally verified operating system that manages the at-rest encrypted messages. Also, all software running on the phone is vetted before being allowed to hit consumer devices, which adds an extra level of security between malicious developers and kernel APIs.
There's no way Android will support that stuff across its entire ecosystem, so I guess it means the law is toothless? Maybe it means it will be up to each hardware manufacturer to ensure interoperability?
1. I don't think "formally verified" means what you want it to here. You mean there a hardware checks signature chain from boot to kernel, secure boot. Apple's software has too many security vulnerability to be considered "formally verified".
2. Android does support device attestation and secure boot. I 100% would love to see our future SMS replacement require frequent signatures from device attestation hardware (why not every message) and require E2EE messages.
This is not the kernel that runs on the host CPU. It is the one that handles keys in the security coprocessor. I don’t know of many hacks of that, in practice. There was one where you could guess the pin, and use a timing attack to power down the chip before it persisted the “bad guess” count, which let people brute force pins (with special hardware).
It’s worth noting that the kernel Apple ships is a fork of L4; no idea if they’ve introduced bugs since the paper was written.
Encrypted at rest does not actually do anything against interoperability of protocols (as I put in my comment), a secure element/coprocessor is nice but still does nothing against compatibility. Even if the entire protocol is somehow in the coprocessor (ala BPF/SGX) there is nothing preventing the counterparty from running it on a regular CPU.
Interoperability can break security properties though. If I send you an iMessage, I can be confident that someone that steals your phone (while it is locked) cannot read that message (ignoring things like state-sponsored attacks).
Prolonged unsupervised physical access is usually already seen as a compromise. Regardless although there is a lot more publicity on Apple's "online attack" difficulty, it's mostly the same story on any semi-recent version of android[0] (barring any unknown zero-days/backdoors from specific manufacturers).
I can't imagine much more than E2EE & maybe encrypted-at-rest (which is not a protocol-level feature anyway).