https://github.com/positive-intentions/chat
probably not… Because I’m comparing it to everything… but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like “most secure chat app in the world”… i probably cant do that because it doesnt qualify… but i want to understand why?
im not an expert on cyber security. im sure there are many gaps in my knowlege in this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels)
-
i sometimes recieve feedback like “javascript is inherently insecure”. i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
-
another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free (instructions are provided in the readme). im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
-
to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
-
i received feedback the Signal/Simplex protocol is great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add a few extra endpoints for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it’s simplicity could be a security feature.
-
the key detail that makes this approach unique, is because as a webapp, unlike other solutions, users have a choice of using any device/os/browser.
i think if i stick to the principle of avoiding using any kind of “required” service provider (myself included) and allowing the frontend and the peerjs-server to be hosted independently, im on track for creating a chat system with the “fewest moving parts”. im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work.
while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
(note: this app is an unstable, experiment, proof of concept and not ready to replace any other app or service. It’s far from finished and provided for testing and demo purposes only. This post is to get feedback on the app to determine if i’m going in the right direction for a secure chat app)
My bad. I noticed the ego sometimes inflates which seems to stem for naive confidence.
I have observed pitfalls of other apps like mine. In particular one called crypto cat. I’m sure I can’t ever be exhaustive enough in learning from other examples.
Reducing metadata is indeed the goal of security and I think I have it reduced to a level where I can exchange webrtc connection data over QR codes or plain text. The IP is exposed at this point but I think this can be further scrubbed with a VPN. Perhaps this is interesting for you. It the minimum example of establishing a webrtc connection with plain text. Not user friendly, but it work without a peer-broker service. In the app I’d like to frame this around exchanging data over QR code.
As for the bitcoin wallet thing, I would think so if it’s well tested and ironed out well. As long as I can facilitate the downloading of the data (for backup) and the data syncing between devices then it would be doing that without registering to any backend. There are countless examples of bitcoin exchanges collapsing and taking people’s assets. The same could be said with the quality of security provided by chat app providers.
If it’s peer to peer text over webrtc, you might write it so that each client sends a fixed number of bytes per second nonstop (some of the bytes are padding and discarded at the other end). That is supposed to stop eavesdroppers from observing when somebody is typing. It’s just the exact same rate of encrypted traffic all the time, 24/7 if you have always-connected computers at home.
I don’t think VPN helps much, and if it’s real time chat you have to make some concessions to keep latency under control. If you can stand a day or two of latency like old-school email remailers, you can do more reordering and so on.
Cryptographer saying: A good disguise does not reveal the person’s height!
All nice ideas! I’ll take a note. I’d like to make time to make it so on each initial connection it generates new keys too. This should be what I think is forward-secrecy. (Let me know if I’m wrong.)
I don’t know the specifics of VPN and it’s implication with webrtc, I tried testing and sharing my observations here. I’m open to advice here.
You asked about native builds… Tbh I don’t know much about it. I did a short search-engine search and these seem to be well regarded. (Currently?) As a pwa I have a lot of flexibility in the apps form-factor. I was thinking about how easy it would be to make it into a browser extension. (It’s not about it being useful, but just providing that extra option.)
Yes you should probably use tls 1.3 in an ECDH mode for your crypto layer, for forward secrecy. I do believe iti s (or was) a known issue that webrtc exposes your ip address to the other client but I’m not well versed on this. If the other client is someone you trust, it might be ok to expose your ip address to them, as long as you don’t also expose it to eavesdroppers.
Oh when you mentioned a native build I thought you meant a real one, not an embedded browser. I guess the embedded browser is still better than using a full blown browser that includes whatever buggy extensions that the user happens to have installed, and preferably doesn’t take browser updates automatically.
Someone in this group (unfortunately I didn’t save the link since I wanted to think about it more) said that for a really secure application, it should be impossible to update the software. Real world systems aren’t that extreme, but there is something to the thought. Of course it means that the very first version has to be free of vulnerabilities, but that’s part of why everyone knows security is hard.
thanks! i’ll make a note of that to add. it looks reletively simple to implement in JS, i’ll need to check more about browser compatability. tls 1.3 is already in use. i otherwise have wording throughout that users must trust who they connect to.
as for browser extensions, there are CSP headers set to prevent them from accessing personal details.
considering the app amounts to a bunch of statics. they wint update themselves if you dont want it to. the app works in many different forms because all form factors can have nuanced security details. its better for security that if people have the ability to selfhost, then they also have the option to choose the form-factor they use based on their preferences.
It’s difficult, all that software and its constant CVE’s. I’m reminded of what Joe Armstrong (inventor of Erlang) said about OOP. “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” Anyway good luck, post an update when you have one.