Comment on Sweeping EU rules for tech giants take effect today. Here’s what’s changing | CNN Business

• fluxx@lemmy.world ⁨8⁩ ⁨months⁩ ago

  Because you can’t end to end encrypt if you don’t have control over both ends. You’d need to trust the other end. Signal doesn’t and their user base especially doesn’t.

  source

  • DandomRude@lemmy.world ⁨8⁩ ⁨months⁩ ago

    Yes, sure, but why not simply point out that the communication between Signal and Whatsapp, for example, is not sufficiently encrypted? If someone doesn’t use Signal or Theema, you can only communicate with this person anyway if you use the corresponding app. That’s not any more secure. I just think that Signal & Co. could gain a lot of users if they also allowed (insecure) communication with other messengers. Encryption between users who both use Signal, for example, is not affected by this.

    source

    • Redex68@lemmy.world ⁨8⁩ ⁨months⁩ ago

      Yeah I really don’t get it. Signal even had something similar. They made it so you could use the app as an SMS client as well. All your contacts would show up and if they didn’t have a Signal account, you could just send them SMS’s. They removed the feature, but they can obviously do it.

      source
  • panicnow@lemmy.world ⁨8⁩ ⁨months⁩ ago

    Why do you need to control both ends for E2EE? Both ends need a public and private key to encrypt and decrypt messages. You need a method of key exchange. I would prefer to have an offline method (phone call, in-person) of validating a key (like iMessage and Signal have). But I don’t see a reason to need to control both ends.

    source

    • lolcatnip@reddthat.com ⁨8⁩ ⁨months⁩ ago

      Probably because different messaging platforms have different opinions on how to implement encryption, and those opinions are baked into their infrastructure at a pretty low level. If two platforms don’t support a common encryption system, the only way to move traffic between them is to decrypt and re-encrypt the data at the boundary between platforms, giving both platforms access to the unencrypted messages.

      Mandating a common system for E2EE seems like a good step 2, but just getting them to exchange messages at all is a good first step that doesn’t require anyone to change their backend to support a different encryption mechanism.

      source

      • rottingleaf@lemmy.zip ⁨8⁩ ⁨months⁩ ago

        If there’d be a way to use FBM with alternative client - one could use OTR.

        source
      • panicnow@lemmy.world ⁨8⁩ ⁨months⁩ ago

        I agree that decrypt/encrypt is bad—it is simply not E2EE. The solution would have to be a better method of public key distribution for ‘federated’ systems.

        While I don’t know anything specific about facebook messenger, E2EE doesn’t necessarily preclude what you suggest. A messaging service could store the entire chat history encrypted without decryption keys. When you get a new client you could restore the entire history in encrypted form onto your device. You would then use a recovery key you would possess to decrypt the message history on your end. At no time would the messaging service have the keys to decrypt. I’m not saying that is what facebook does.

        source
  • Mkengine@feddit.de ⁨8⁩ ⁨months⁩ ago

    Would it be technically impossible to implement such a feature if both companies would work together or is it just too much hassle?

    source
  • rottingleaf@lemmy.zip ⁨8⁩ ⁨months⁩ ago

    OTR?

    source