Before I say anything else, I should mention that this is nothing ground-breaking, neither is it terribly difficult to implement. This is simply how I envision a simple solution.

Basically, the EU and the UK want the secret keys to your encrypted media/messages. Which essentially breaks encryption completely, ending E2EE usage.

The alternative is, then, for the user to utilise their own form of E2EE. How though? The answer, in my opinion, is personal exchange of keys utilising asymmetrical encryption. Exchanging public keys in plaintext is fine as long as they don’t have your private key. Which means unencrypted services like SMS could also be secured using this method (for example, have the public key of a user in their profile). I believe QKSMS employed encryption for SMSes for as long as it lasted, but no idea about the kind of encryption).

Technically, if everyone started to use p2p messengers with asymmetrical encryption, the EU would have very little they could do without compromising every mobile in the region and preventing people from downloading APKs somehow (sorry iOS users but you’re never going to have privacy anyway).

However, this is only possible with a FOSS project, because a company would have to fork over the keys anyway to stay alive. A FOSS project can simply be forked once the OG maintainer stops working on it due to government pressure. That is where the problem comes, since FOSS projects can’t really run their own servers to store media, making p2p the only viable option. But with some people behind CG-NAT, that becomes harder for non-technical users.

I don’t have a way to solve this other than the general population becoming tech-savvy enough to give a damn.

Tl:dr; FOSS projects are best suited for implementing personal E2EE between users, but that makes p2p the only viable option without a back-end, which makes it difficult for people behind CG-NAT.

Cheers

  • MigratingtoLemmy@lemmy.worldOP
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Well, yes, GnuPG is certainly an option. I don’t care how it’s implemented though, but I do care about the fact that clients/client apps take encryption into their own hands instead of relying on middleware.

    • virtualbriefcase@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Clients taking it into their own hands reminds me of delta chat. Basically the same thing but the client handles encryption and uses a generic email server as the chat server.

      But any good client will handle encryption themselves (heck even “bad” clients will do that). As long as they’re not UK based and don’t neuter the clients for their UK users they’ll still retain proper encryption completely client side (outside of public key infrastructure which is a whole different topic).

      • MigratingtoLemmy@lemmy.worldOP
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        From what I understand of PKI and the way the Internet is right now, trust in identity would be very hard to build if clients engage in PKI.

        But taking encryption into one’s hands basically brings back control into one’s hands. You do not specifically need an encrypted connection in such a case, just a tamper-proof connection.