42
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Mar 2025
42 points (97.7% liked)
Privacy
38571 readers
207 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
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'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).
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'.
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 :)