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

  • GravitySpoiled@lemmy.ml
    link
    fedilink
    arrow-up
    15
    ·
    1 year ago

    I highly doubt that it’ll ever happen, but if, I’ll just host my own matrix server and I’m good to go.

  • FIST_FILLET@lemmy.ml
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    sorry iOS users

    EU is forcing apple to allow sideloading. not sure when the deadline was, i think next year?

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

    Sounds like what you’re looking for is PGP/GPG. Been around for a while, but does the job well.

    Also, I doubt most projects built outside of the UK (or Europe as the EU seems to be moving in a similar direction) will actually comply and backdoor their own software. As long as you have internet they’ll always be actually secure software to download.

    • MigratingtoLemmy@lemmy.worldOP
      link
      fedilink
      arrow-up
      3
      ·
      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.

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

      We need to use some tool. If the government doesn’t have your private key, they can’t decrypt your messages. I don’t care how that is implemented, but companies like Signal will either fight to the death or bow out

  • Wothe@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    if everyone started to use p2p messengers with asymmetrical encryption, the EU would have very little they could do

    Totally agree with you; a p2p network is resilient and unstoppable. Every user acts as a node within the p2p network, and as long as people are actively online, it can survive. This means it cannot be banned by any country or government.

    Plus, since a P2P network is a decentralized network, there is no central server to store user data such as chat histories or contact lists**. From a data privacy perspective, nothing can compare with a p2p network.

    I know people are quite familiar with Signal and Whatsapp due to their E2EE services. However, they are managed by tech companies and utilize a centralized network (central server = another computer). All your chat histories and data are kept in their giant computer/server. Even though it is encrypted, who in the world knows if they have memorized your private key (I think they do, by the way, because governments need these things to monitor suspicious activities or potential criminal incidents).

    So, start using applications that operate on a decentralized P2P network; it is the safest way to safeguard your privacy rights.

    • t4k3@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 year ago

      start using applications that operate on a decentralized P2P network;

      Have you heard of this one? They said it’s a secure messenger based on P2P network, also with end-to-end encryption technology.