I want to make it dead-easy for others to chat with me. I want a browser-based, FLOSSS, E2EE chat solution that doesn't require the other party to log in. Does that exist?
-
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.
-
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.
Idk how to help you, snek boi.
-
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.
e2ee is not really compatible with what you want due to necessary key management, and once you drop that there are so many possible options for what you want that I don't want to list them all here.
-
e2ee is not really compatible with what you want due to necessary key management, and once you drop that there are so many possible options for what you want that I don't want to list them all here.
Can you expand more on the key management? I thought https://chat-e2ee-2.azurewebsites.net/ passes a PSK Through the header and sets that as a cookie in the browser to sign further comms. I could be mistaken of course.
-
it's so easy to chat with you!
hi
I'm nicole, but you can call me the fediverse chick
Oh no. What have I done?
-
This ticks all the boxes! Thanks! I suppose something I didn't contemplate is that I would like to close the chat and still be able to get notifications on my phone. I don't want to always have a dozen chats open, ready for the other party to send me a message. Regardless, I'm glad this project exists!
-
The Graphene OS homepage has a Matrix chat page configured like this that automatically generates a guest user
This sounds amazing. It's unfortunate that Graphene OS has so much toxicity around it, but this design decision is amazing. Love it.
I tried quickly looking for the feature, but I couldn't find it. I searched for "Graphene OS Matrix chat homepage guest user", "Graphene OS chat homepage guest user", "Graphene OS chat homepage", and "Graphene OS homepage QR" but didn't find what you mentioned.
-
it's so easy to chat with you!
hi
I'm nicole, but you can call me the fediverse chick
Even better that only the first line was visible until I scrolled
-
This sounds amazing. It's unfortunate that Graphene OS has so much toxicity around it, but this design decision is amazing. Love it.
I tried quickly looking for the feature, but I couldn't find it. I searched for "Graphene OS Matrix chat homepage guest user", "Graphene OS chat homepage guest user", "Graphene OS chat homepage", and "Graphene OS homepage QR" but didn't find what you mentioned.
Toxicity? How so?
-
Can you expand more on the key management? I thought https://chat-e2ee-2.azurewebsites.net/ passes a PSK Through the header and sets that as a cookie in the browser to sign further comms. I could be mistaken of course.
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.
-
Toxicity? How so?
https://www.reddit.com/r/degoogle/comments/v5n1yv/whats_your_opinion_on_graphene_os_community/
https://news.ycombinator.com/item?id=30929526
A quick search lead to these links. They're 3 years old. Maybe the community has changed since then.
-
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.
Fragility is by design as it's ephemeral comms. Swapping the js decryption doesn't make sense as wouldn't the client just fail or refuse the message stream as the decrypt/encrypt changed? It's an interesting problem. Thanks for giving me something to noodle on.
-
https://www.reddit.com/r/degoogle/comments/v5n1yv/whats_your_opinion_on_graphene_os_community/
https://news.ycombinator.com/item?id=30929526
A quick search lead to these links. They're 3 years old. Maybe the community has changed since then.
It has. Strangely enough they posted a code of conduct after that feedback and started weilding the ban hammer. However I cannot speak to outside forums like XDA or Reddit or even comms here. I tend to stick to their forums or github
-
Fragility is by design as it's ephemeral comms. Swapping the js decryption doesn't make sense as wouldn't the client just fail or refuse the message stream as the decrypt/encrypt changed? It's an interesting problem. Thanks for giving me something to noodle on.
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.
-
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.
I still don't see how
swap to a modified JS that exfiltrates the e2ee key
or
add additional keys
Wouldn't significantly change the recieved hash and break the stream thus ending comms. Also unless you're hosting and building it yourself you have to trust the recipient and the cloud host.
I agree if an attacker owns the server comms can be compromised. I thought that was the benefit of the ephemeral nature. It's for quick relay of information. Best practices would probably include another cypher within the messages themselves like a one time pad or some such.
https://www.itstactical.com/intellicom/tradecraft/uncrackable-diy-pencil-and-paper-encryption/
-
This sounds amazing. It's unfortunate that Graphene OS has so much toxicity around it, but this design decision is amazing. Love it.
I tried quickly looking for the feature, but I couldn't find it. I searched for "Graphene OS Matrix chat homepage guest user", "Graphene OS chat homepage guest user", "Graphene OS chat homepage", and "Graphene OS homepage QR" but didn't find what you mentioned.
That matters? Why does developer behavior influence your judgement over whether you will use certain pieces of software? Just curious
-
I still don't see how
swap to a modified JS that exfiltrates the e2ee key
or
add additional keys
Wouldn't significantly change the recieved hash and break the stream thus ending comms. Also unless you're hosting and building it yourself you have to trust the recipient and the cloud host.
I agree if an attacker owns the server comms can be compromised. I thought that was the benefit of the ephemeral nature. It's for quick relay of information. Best practices would probably include another cypher within the messages themselves like a one time pad or some such.
https://www.itstactical.com/intellicom/tradecraft/uncrackable-diy-pencil-and-paper-encryption/
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) so your byo code payload could be alot smaller these days.
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).
-
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) so your byo code payload could be alot smaller these days.
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).
I don't know yet. It's more a thought experiment than anything else.
https://github.com/muke1908/chat-e2ee
Looks like the URL is part of the seed and salt which is cool.
Proving who you are is done in another stream. Like MFA.
You do a one time pad, generate the URL with that. Communicate what's needed, then the URL dies.
I'm still noodling with it.
-
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.
out of interest, do you actually mean no login, or do you mean no email-verified login?
-
I don't know yet. It's more a thought experiment than anything else.
https://github.com/muke1908/chat-e2ee
Looks like the URL is part of the seed and salt which is cool.
Proving who you are is done in another stream. Like MFA.
You do a one time pad, generate the URL with that. Communicate what's needed, then the URL dies.
I'm still noodling with it.
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'.
