5 ms·

I'm sort of surprised at the positive tone here. Sure, it's nice for non-technical people to enumerate a lot of nice to haves, but just asserting something does

I'm sort of surprised at the positive tone here. Sure, it's nice for non-technical people to enumerate a lot of nice to haves, but just asserting something doesn't make it true or possible. As one example, making "core messaging functionality interoperable". How exactly does that work with end-to-end encryption? I suppose we'd need some sort of open system and protocol for all the tricky key sharing stuff? That would be nice but doesn't seem feasible in 6 months. And how do you know what they're using on the other end? If someone is using an app that doesn't support encryption, and they try to send a message to, say, you on WhatsApp, where you have e2e enabled by default, what happens? Another one is they can't "limit payment possibilities to their own method". Presumably this means like iPay and Google Pay. Isn't there, again, some hardware security issues in play with that? I don't understand those systems well enough to know for sure, but I thought they were locked down and proprietary in part to protect your financial data.

aaomidi 4y ago
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.
capableweb 4y ago
> 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?
- dodobirdlord 4y ago
  Ah, so now nobody can ever launch any new messaging features without reaching a consensus in a standardization body. Progress!
  - capableweb 4y ago
    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
    - d12bb 4y ago
      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
      - capableweb 4y ago
        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?
    - dodobirdlord 4y ago
      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.
iasay 4y ago
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.
zaarn 4y ago
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).
seydor 4y ago
it says core messaging, maybe only unencrypted chats can be interoperable. TBH , unlike GDPR, this seems a lot more pragmatic and feasible
yohannparis 4y ago
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.
- dodobirdlord 4y ago
  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.
  - dx034 4y ago
    Signal can give you the option to disable that. They just cannot force that decision on users.
    - dodobirdlord 4y ago
      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.
kmeisthax 4y ago
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
- dane-pgp 4y ago
  > 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.
dane-pgp 4y ago
> 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.
ThatPlayer 4y ago
I like Matrix's write-up on it: https://matrix.org/blog/2022/03/25/interoperability-without-sacrificing-privacy-matrix-and-the-dma/ 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
viktorcode 4y ago
> 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.
- dzikimarian 4y ago
  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.
  - viktorcode 4y ago
    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.
    - dzikimarian 4y ago
      >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?

aaomidi 4y ago

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.

capableweb 4y ago

> 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?

dodobirdlord 4y ago
Ah, so now nobody can ever launch any new messaging features without reaching a consensus in a standardization body. Progress!
- capableweb 4y ago
  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
  - d12bb 4y ago
    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
    - capableweb 4y ago
      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?
  - dodobirdlord 4y ago
    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.

iasay 4y ago

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.

zaarn 4y ago

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

seydor 4y ago

it says core messaging, maybe only unencrypted chats can be interoperable. TBH , unlike GDPR, this seems a lot more pragmatic and feasible

yohannparis 4y ago

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.

dodobirdlord 4y ago
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.
- dx034 4y ago
  Signal can give you the option to disable that. They just cannot force that decision on users.
  - dodobirdlord 4y ago
    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.

kmeisthax 4y ago

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

dane-pgp 4y ago
> 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.

dane-pgp 4y ago

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

ThatPlayer 4y ago

I like Matrix's write-up on it: https://matrix.org/blog/2022/03/25/interoperability-without-sacrificing-privacy-matrix-and-the-dma/ 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

viktorcode 4y ago

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

dzikimarian 4y ago
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.
- viktorcode 4y ago
  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.
  - dzikimarian 4y ago
    >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?