Hacker News Reader

> How exactly does that work with end-to-end encryption?

Exactly how we deal with everything else that works across platforms: standardization. We've done it at least once before (SSL/TLS), I'm sure these rich and "amazingly smart" companies can figure out how to achieve it once again.

> Isn't there, again, some hardware security issues in play with that?

Is there hardware security issues with accept CC details on the web? Assuming the computer itself isn't compromised, the web seems to (again) have figured out how to deal with it across platforms, both OSes and browsers, why can't phone OSes do it?

Ah, so now nobody can ever launch any new messaging features without reaching a consensus in a standardization body. Progress!

Nope, that's not how standardization works.

I'd refer you to the process of HTML/CSS/JavaScript if you want to see how it can work in a global manner that also works for innovation too (unless you'd argue that HTML/CSS/JavaScript is exactly the same in terms of "innovation" since they each first were created).

In short, the process is something like this: 1) a browser implements a new feature they think is useful 2) standard bodies start watching 3) another browser implements the same feature either the same way, or differently 4) standard bodies start working on a specification to unify the feature across browsers and OSes 5) Specification gets "blessed" and is now official recommendation 6) browsers modify their feature to be compliant with the specification

Step 1 of that process violates the law, if it adds new “core messaging capability”. Perhaps the EU considers “core messaging capability” to refer exclusively to functionality that already exists today, and it could not even in principle refer to anything that doesn’t already exist, but that seems vague and unlikely. If support for Unicode emoji did not already exist, would a vendor be allowed to unilaterally add it? It seems uncertain.

So now, instead of websites breaking from browser to browser. My messages will fail from each app? Browsers show how global standards fail and the only thing preventing 99.99% market share of chrome is the walled garden that is apple & safari

Yeah, web is the best example…

In short, the process is something like this: 1) Chrome implements a new feature they think is useful 2) Google uses their people in the standard committees to push it into the standards 3a) it's actually useful: other Browsers implement it or 3b) it's basically useful to Google: they'll continue blaming other browsers to not implement standards, “This website works only in Chrome” incoming

You have any evidence of this happening?

All cases I can think of for the last 4-5 years, have been Chrome/Firefox implements something -> The other implements it -> Standard pops up

What features has Chrome managed to standardize without having another browser implement the same feature?

The messaging interoperability is actually very worrying with the current discourse on scanning messages for certain content from the EU. Also various factions in the EU have been completely against end to end encryption.

What we can expect is weak protection on request of the government which puts people genuinely at risk.

If that happens I cannot possibly support the DMA or the EU on this but it'll be too late before it becomes apparent.

There's no particular reason preventing us from having interoperable E2E; we could already have interoperable E2E e-mail today if we wanted. Securely bootstrapping key exchange could be done through having one phone take a picture of a QR code on the other phone. Though, to be fair, I have no idea if any existing E2E services actually let you do this. "In-band"/electronic key introduction does require the message server operator to act as a trusted bootstrapper, but nobody seems to be worrying about that as-is.

The real concern with interoperable messaging is antispam. E-mail was an absolute disaster because there was no barrier to entry for someone who just wants to send unsolicited garbage to everyone. Google killed federated messaging for Google Chat back in the day because for every one person running their own XMPP server there were hundreds who realized Google was just giving away valuable real estate on everyone's Gmail inbox to this chat service. The EU appears to be trying to mandate federation to fix the competition problems involved with iMessage[0] and I genuinely hope there's a user opt-out for this when it inevitably gets abused for spam.

[0] Which, ironically, is more of an American problem than a European one

> E-mail was an absolute disaster because there was no barrier to entry for someone who just wants to send unsolicited garbage to everyone.

Email spam is possible because of the expectation that you can contact someone you've had no prior interaction with. (Also, it at least used to be quite easy to spoof the sender address because participants couldn't cryptographically prove their identities, but we now rely on tech like DKIM to mitigate this).

Messaging apps have an easier job because the services can refuse to deliver messages to people who haven't already received your public key (or some short, per-contact, pre-shared secret).

In fact, email encryption could also work this way, if users first had to send a standardised introduction message, and servers rejected any further messages until the recipient had marked the sender as trusted.

I like Matrix's write-up on it: https://matrix.org/blog/2022/03/25/interoperability-without-...

Also there's a line in the final full act:

>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

The "limit payment possibilities" means that, f.e., Apple cannot stop a banking app from using the on-device secure enclave and the NFC functionality from making payments available if Apple also offers a payment service using those functions (or to say it differently; If Google or Apple make a payments app, they must allow everyone to develop their own payment apps for their ecosystems and make all functions available that are necessary to have all functionality of Google or Apple's own apps).

You can easily warn a user that messaging a user using a different protocol will not be encrypted.

On the iPhone, this is done visually with the blue/green bubbles. But other solutions can be implemented.

If I am using, say, Signal, I do not want it to be possible to send me an unencrypted message at all. That philosophy of security sounds likely to run afoul of this legislation.

Signal can give you the option to disable that. They just cannot force that decision on users.

Security needs to be a default though. It will be a serious problem if this law ends up being interpreted as requiring encrypted messaging systems to accept insecure messages by default.

> How exactly does that work with end-to-end encryption?

One way would be for Apple to offer a web API endpoint for companies that have signed an agreement with them (covering rate limits, server identification certificates, liability, etc.).

In fact, the API could be implemented in iOS itself, so you could have something like "Signal support for iMessage" as an app in the App Store, which would basically be a headless version of the Signal app which delegates all the UI tasks (mainly message display and input) to the iMessage app.

If the app doesn’t support encryption, then they don’t see the message.

Client side lock downs aren’t security. They’re security theater.

> As one example, making "core messaging functionality interoperable". How exactly does that work with end-to-end encryption?

Quite simply: it doesn't. It can only work the same way as iMessage interoperates with SMS, by throwing away security.

That's plainly not true. There are hundreds of open protocols able to establish encrypted connection, including some dedicated to instant messaging.

There's literally zero benefit that Apple, Google, FB or whoever is able to offer with their in-house implementation.

For two messengers operating on two different encryption protocols the only way to talk to each other is to introduce an intermediary, which will decrypt and then re-encrypt messages, thus throwing p2p model out of the window.

Some optimists here telling that all messenger might follow a certain "standard" for transmitting encrypted messages. And in fact some messengers might, but this standard will be the lowest common denominator, i.e. the weakest security protocol all know.

For p2p model generating secure private key is paramount. Can this be guaranteed by every peer operating in a chat? Not unless they all made by the same team with high security standard.

>For two messengers operating on two different encryption protocols the only way to talk to each other is to introduce an intermediary.

Or they simply could agree on solid common exchange protocol. There's no requirement to support crappy encryption. Just to open communication with your service.

We've dozens of functionality identical, incompatible proprietary protocols, because each corporate schmuck wants their own walled garden, to squeeze a few more cents.

Why should we agree to that?

it says core messaging, maybe only unencrypted chats can be interoperable.

TBH , unlike GDPR, this seems a lot more pragmatic and feasible