Here’s my problem: every F(L)OSS and E2EE solution that I know of requires other people to download an app or log in.

I want to reduce the friction for others to communicate for me. I want to give a business card with a URL where people can go and immediately send messages to my Matrix or my email or something, and they don’t need to log in at all.

They just open their browser, go to snek_boi.io or whatever and a chat appears.

A couple of years ago, I was suggested Cactus Comments. I suppose that works, but I was wondering if there are other solutions. I was wondering if now there was an even easier solution for my purposes.

  • poVoq
    link
    fedilink
    32 months ago

    Yes you can juryrig something like that with cookies, but it is highly fragile and browser based e2ee is basically a scam anyways as the server serving the website can always swap out the javascript that decrypts the messages.

      • poVoq
        link
        fedilink
        12 months ago

        The server can swap to a modified JS that exfiltrates the e2ee key and thus allows the server owner to decrypt the messages, or in more advanced encryption schemes add additional keys without you knowing and achieve the same thing.

          • @ganymede@lemmy.ml
            link
            fedilink
            2
            edit-2
            2 months ago

            i’m trying to understand your exact scenario.

            but in general, the problem is where do you get your original key, or original hash to verify from? if they are both coming from the server, along with the code which processes them, then if the server is compromised, so are you.

            thankfully browsers give alot of crypto API lately (as discussed in your link)

            but you still need at minimum a secure key, a hash and trusted code to verify the code the server serves you. there are ofc solutions to this problem, but if the server is unstrusted, you absolutely can’t get it from them, which means you have to get it from somewhere else (that you trust).

              • @ganymede@lemmy.ml
                link
                fedilink
                22 months ago

                cool, sounds like you have most of the principles down.

                what i didn’t yet see articulated with chat-e2ee is how the actual code itself verifies itself to the user in the browser? it sounds to me like it assumes the server which serves the code is ‘trusted’, while the theoretically different server(s) which transmits the messages can be ‘untrusted’.

                  • @ganymede@lemmy.ml
                    link
                    fedilink
                    22 months ago

                    ah fair enough. i think that was the initial confusion from myself and perhaps the other user in this discussion. i didn’t realise your use cases.

                    it’s always a fun topic to discuss and got me thinking about some new ideas :)