[MattJ100]

Fact check: The Digital Markets Act explicitly calls out end-to-end encryption as a feature that MUST be preserved if the platform supports it.

From Article 7:

"The level of security, including the end-to-end encryption, where applicable, that the gatekeeper provides to its own end users shall be preserved across the interoperable services."

[Vt71fcAqt7]

The way appositives work is that they qualify the preceding subject. Here you have two appositives so you can read "where applicable" as qualifying "including end-to-end encryption" or "the level of security." If "where applicable" is qualifying "the level of security" the staement reads "the level of security, where applicable, that the gatekeeper provides to its own end users shall be preserved accross the interoperable services." (And this seems to me the most accurate meaning. In any case it can be read that way.) Even if it is qualifying "the level of security" it is still in the end only "where applicable" which can still be read to mean the same thing. In fact, reading "where applicable" to mean "where already existing" as you implied, is redundant because it is already given in "shall be preserved" and "the level of security." Now we can read "where applicable" to imply that e2ee does not apply when the EU says it shouldn't.

[EMIRELADERO]

Civil law countries don't like textualism. The spirit/intent of the law can often trump a literal interpretation of the text, so all this grammatical arguing is moot.

[Vt71fcAqt7]

Even worse.

[EMIRELADERO]

Care to explain why?

[Vt71fcAqt7]

If we can ignore what the law says in favor of its spirit, then the law certainly means that the EU can "shut off" e2ee at any point, given their track record. Second, even if the above is false, it doesn't matter as whoever gets to decide "the spirit" of this law can say that it doesn't apply to terrorists, or doesn't apply durring x type of situation.

[closetnerd]

Is there more on this? Can this as is really be enough to maintain the security guarantees Apple currently provides?

[spogbiper]

Apple currently provides no encryption at all when their users communicate with the owners of the 75% of mobile devices that are not Apple. Apple could do better for it's customers.

[f_devd]

What security guarantees do Apple currently provide?

I can't imagine much more than E2EE & maybe encrypted-at-rest (which is not a protocol-level feature anyway).

[hedora]

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?

[dcow]

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.

[hedora]

It is a fork of this:

https://people.cs.ksu.edu/~danielwang/BAS/klein-2014-microke...

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.

[dcow]

Didn't realize you were talking about secure enclave.

[f_devd]

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.

[hedora]

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).

[f_devd]

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).

[0]: https://theconversation.com/what-if-the-fbi-tried-to-crack-a...