These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?
- Build a DHT style overlay network of "meet in the middle" servers
- Have a standalone html file, that uses websockets to connect to the network of servers.
- Have both clients generate keys, exchange them via other channels.
- Both users have a shared key, they both lookup the server that hosts the shared key on the DHT network (that actually can be done without leaking the key to every server) then they use that server to exchange NAT-busting messages
Ideally, you would have a lot of different use cases using the same network in such a way that it is hard for a server to figure out what you are using it for, and it is essentially impossible for a server to target MITM a specific pair. What this does leave open is sybil attacking and MITM-ing everything opportunistically. At this point we essentially start to build TOR via websockets and WebRTC and it all breaks down.
This sounds incredibly complicated :) I would definitely use TOR if I believe I'm facing a dedicated and sophisticated threat. For now I have tried to clarify the issues in the FAQ and can only hope that people read it and don't get screwed over by wrong expectations.
I'm a little worried, that because the browser get it's own address from the server there might be a way to build a lie that looks plausible to both users, but I can't think of a way to do that off the top of my head.
Hating on js and acknowledging that it is currently technically impossible to do any real, secure in-browser crypto engineering with it are two different things.
