Except this site is worse, because they also let their third party user tracking provider run arbitrary script on every page too.
Nice as a demo of technology though.
The best way to do encrypted WebRTC transfers is to have the whole app in a single page, using as little code as possible (so it is easily auditable). NoScript/etc won't do much when you have to trust the author and can't audit it. People should be able to download the page from the GitHub repo (or wherever) and store it wherever they want. The page will generate a random URL that also contains a secret key (e.g. http://www.myservice.com/somerandomid/#98h9g78g2188t7231gy34...), which you can share with the receipient.
Since the URL fragment is never transmitted to the server, it is private. The WebRTC service can encrypt the content appropriately and send it to the recipient, where it will be decrypted. Voila, encrypted p2p file transfers without having to download anything.
In defense of this implementation -
- The only external JS loaded on this site is google analytics. Feel free to block this using something like noscript :)
- WebRTC datachannel connections on this site don't use just (optionally) OTR. They have DTLS enabled within the browser. OTR just adds an authentication layer that DLTS currently lacks. So that even if the OTR implementation here was completely compromised, the only possible attack would still be a MiTM on the DTLS channel.
- It's open source (https://github.com/erbbysam/webRTCCopy), so it's available to be hosted elsewhere and all of the libraries used could be re-downloaded.
-Sam
And if somebody else had visited that same room, would they have a log of that too?
The day-to-day UX experience of browsing the web is only minimally affected and significantly safer.
Better than adblock.
If your concern is the host operator, well obv can't circumvent that. Unless you use OSS chrome plugins and client code verifications (ala CryptoCat). But that's also an imperfect solution (cue tptacek).
[1] https://chrome.google.com/webstore/detail/scriptsafe/oiigbmn...
My concern was that he made the security/privacy worse than it needed to be, for other people, by including Google Analytics on the page.
He has now stated that he's seen that the room name is in fact being leaked to Google Analytics, and so has removed it. But even if he hadn't seen this, you still shouldn't include any third party hosted scripts on pages like these because you've no idea if/when they'll change in a manner which compromises security/privacy in future. No malicious intent required.
Of course we can circumvent that. Make a plugin to alert the user whenever the JS changes.
I wont be interested in running web based mail/chat clients until we get to a point where browsers have built in APIs that allow people to write trustable apps.
I wonder: when using WebRTC between two devices on a single LAN, is my ISP involved (possibly: beyond bootstrapping the process)?
2. WebRTC tries to create a P2P connection between the devices. The ISP is only involved in the initial bootstrapping of the P2P connection - the actual data packets travel over the LAN and not through your ISP. In the rare case a P2P connection can't be established, a relay might be used (though this is optional).
I did have unreliable datachannel support initially, but as both Firefox & Chrome now support reliable, I see no reason to keep that overhead/extra code around. Hopefully working reliable datachannels in Chrome will reach the primary version soon!
