Messages are not end to end encrypted and can thus be read from service provider.
Additionally Google is integrated into website.
Messages are not end to end encrypted and can thus be read from service provider.
Additionally Google is integrated into website.
That's true. It's due to lack of implementation.
Getting e2ee right is tricky business. Any help or insight would be appreciated.
Look into libaxolotl
(AKA "OMEMO"), it is the same system Signal uses and is highly standardized.
I know Matrix has E2EE with some public documentation on its implementation. Maybe it could help you? Idk how familiar you're with E2EE or what kind of implementation you'd want, anything will have drawbacks :/
Thanks for the tip!
I have somewhat of a grasp on how Signal does it, but that's very client oriented. How to go about it a web app is a mystery to me.
Yeah, I'm not used to E2EE in the browser either and StackExchange seems to agree that there's no nice solution :/
The sanest option in terms of user practicality to me appears to be storing the private key on the server, maybe encrypted with the user's password, and sending it to the user on successful login where it would be decrypted client side. It seems like it's more or less what MEGA is doing since they have a similar issue
If the server having temporary access to the user's password is an issue maybe the password could be partially pre-hashed before being sent?
It's be interesting to talk about it with someone with more experience, especially since implementing all of that will be a pain so it can't be redone every Thursday
The sanest option in terms of user practicality to me appears to be storing the private key on the server, maybe encrypted with the user's password, and sending it to the user on successful login where it would be decrypted client side.
That does seem reasonable, but it doesn't solve the trust issue. The server might always send a modified script that just uploads the plaintext private key.
That said it would still be useful in other ways. Like in a breach the data would be secure.
The server might always send a modified script that just uploads the plaintext private key.
Yeah, you'd need a way to validate the client code before it's executed to solve that issue
Section "2. Client application security" of MEGA's Security Whitepaper discusses this exact problem. Their best solution to that issue is to just cram the whole frontend in a signed web extension and not serve any code to the user when the extension is active, which is not very user friendly but works for those who want an extra layer of protection
I just can't find a good user-friendly implementation, sorry for not being of more help. The web just isn't E2EE-friendly ig :/
You've helped enough :)
Hmmm I see.
We have an app in the making, so I guess we will eventually implement proper e2ee there and then just try our best in the browser.
Damn already working on an app? That's so cool! Starting E2EE there is definitely a good idea then!
MeroChat is such a nice project, thank you for working on it <3
yey, more friends to chat with.
At the bottom of the page, "Privacy Policy" is misspelled "Privacy Police". I don't know if you have any power to change that, but I thought I should point it out.
Noted, thanks!
Why upload duck-face pictures when you can talk about dancing plagues of the 16th century?
Hilarious ๐ looks like you (and others?) have put some effort into this.
I can't take too much credit myself, but yes, effort has been put. ๐๐
An interesting solution to increase TTD* in random webchat.
*TTD: time-to-dick
these are not real people, just bots
I'm not saying that a single bot hasn't gotten through, but probably you're referring to the auto filled profiles? It's just a way for them to be non-empty.
Cool ๐ But it feels more like a dating app than an Omegle alternative. But I like the concept.
Written in PureScript
Using a purely functional niche language like that will really prevent good developers from contributing IMO.
Or it might encourage someone to learn a new paradigm :)
You could have a multi-paradigm programming language and use FP techniques in the code. And at least in my university there was an introduction to FP and i assume that is true for most CS degree programs.
Anyway no offence but i wonder how many of the people who upvoted you actually programmed in a purely functional programming language . i read and did the exercises for real world haskell and i don't think purely functional programming language can create the clearest code. i can see the advantages but a language with a strong support for FP and OOP would be better IMO (Ruby?). I also can't think of a popular FOSS project that uses a purely functional language (pandoc is an exception, but that seems like a sweet spot for FP).
But it is a cool project and i like the endeavor.
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Community icon from opensource.org, but we are not affiliated with them.