Reminds me that i ran into a blog after the referenced comic was publish, that mused about how the trouble of easily sending files between PC online was a conspiracy between the ISPs and the *AAs.
The limitation of this method is that you do need your own port exposed to the internet. The advantage of this method is that you don't have to trust a third party.
For the explicit example above, your guest's firewall would have to be pretty brutal to not allow port 80 through.
WebTorrent actually implements the bittorrent protocol, and can be used as a nodejs bittorent client. It extends the bittorent protocol to do p2p sharing inside the browser (but you only can connect to other people using the webtorrent nodejs app or in-browser app, and not all the bittorent network)
FilePizza and Bitfly are much simpler implementations, doing 1-to-1 file transfers in the browser using the basic WebRTC Datachannel API.
Looks like FilePizza is now using WebTorrent too now, as it's mentionned in their FAQ:
"Where are my files sent? Your files never touch our server. Instead, they are sent directly from the uploader's browser to the downloader's browser using WebTorrent and WebRTC. This requires that the uploader leave their browser window open until the transfer is complete."
I have a question: Secure against what thread model?
The FAQ has an entry for "How do I know you're not sending all my data to the NSA?" but that's the wrong question to ask (i.e. Even if you're not behaving maliciously, that doesn't mean our data is safe against highly sophisticated threats).
It would really be great if you could demonstrate what makes this more secure than alternative solutions.
Webrtc itself requires perfect forward secrecy. While you cannot do authentication with it - you need to provide that yourself - you can be certain besides yourself and whomever your signaling server told you is your peer are the only two able to decrypt the packets going between you two.
Thank you for the feedback! I will change the wording of that FAQ question (+ answer) and make it more detailed.
I'm not sure about how I should go about demonstrating what makes this model more secure, except making it more obvious that it doesn't involve storing your data on servers not under your control which is the case with solutions like email and skype.
A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking.
You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels.
But all-in-all this does not offer ANY security over a server because there is no way to show it is not just being stored on a server.
Not knowing enough about this, I am genuinely curious if something like zerodb solves this. It was posted yesterday, but it was started by 2 guys, i think one was from morgan stanely, that allow you to securely send and receive data from the db while it is portected in flight. Would this be helpful in the scenario?
This will betray my lack of domain knowledge but it sort of opperates like a double encryption, so basically the data is encrypted maybe then sent, then it is encrypted by a forwarding proxy which also has a priv./pub key. You query for the hash, get the hash, decrypt it, and send it back.
Could you use this as the broker for webrtc? I know that wasn't exactly Nakomoto's BitcoinD paper, but their model seems to make sense, and a lot in this context.
"A STUN server is still used to find out your external IP for NAT-busting."
essentially, now the STUN is the MITM. STUN server lies to both parties about what their IP addresses are and responds with IPs that it controls. Both parties connect to those IPs and the messages are relayed between them.
This is incorrect. Once data starts to flow, DTLS is used to encrypt the connection and verify each peer's identity. If the STUN server attempts to MITM, it will be detected.
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.
We do this on securesha.re. Yes, you can't be sure the client hasn't changed the JS - I'm going to start putting md5s in the script tags but it's up to the client to check they haven't changed. However, the client is open source [1], so you could always run your own client.
that only works if you have a way to assure the JS has not being modified every time the page is ever loaded everywhere.
That only works on a content addressed protocol like IPFS
Might be just me, but "look I made something similar here is the link" without any more info or mention of how it's relevant sounds a lot like piggybacking off of the success of this thread to promote your own project.
I trust my browser's developers with my most sensitive data (online banking password, government id etc.) but that does not mean I believe I am fully secure in doing so. There could always be a bug in the WebRTC implementation or the SSL library or the hardware. Maybe I should rephrase the FAQ to read "Don't put your highly sensitive data on the Internet at all".
The warning is posted under the headline "How do I know you're not sending my data to the NSA" and in that context, it is a good warning. Don't trust random software with highly sensitive data.
Sorry for off-topic, does anyone know why Google phone calling (Voice / Hangouts) still doesn't work with WebRTC and requires native plugin? And are there any other services for making phone calls which actually work with WebRTC?
They use nonstandard APIs, and send data over the network in a way incompatible with WebRTC. This post is a bit old at this point but afaik the situation hasn't changed: https://webrtchacks.com/hangout-analysis-philipp-hancke/
Can it make calls to real phone numbers, especially between countries? That's essentially what I need. Google provides that, but it works very poorly and requires a native plugin.
For regular Internet to Internet media calls I can use XMPP/Jingle client.
I was thinking this exact use case last in year in some experiments but just got to busy to finish it. I had auto discovery of local computers and a nice name: browserdrop.it.
I had it working too casting a chromecast with a system for displaying various file formats and basically file sharing your phone.
Not enough time in the world to finish every side project. Also once I found out about AirDroid I kind of felt they had my main use case pretty covered. Not quite but close. https://www.airdroid.com/
Very cool! We built something similar using flash and RTMFP back in 2010 and actually got into YC W11 with the project (with dreams of building something like airdrop until Apple went and actually built airdrop causing us to pivot into high speed data transport instead).
It's great to see this being implemented using WebRTC now, which was just popping onto the radar back then. I envy you building this without having to write any action script or flex code! Best of luck with the project.
Slightly off topic, but can anyone recommend a webrtc tutorial for data channels or any projects which can be used for player v player over the browser (chrome) . I guess like one player has to be the master and the other players join his/her webrtc connection ?
I was wondering if it is possible to transfer streaming video data over WebRTC already, for example to implement a video chat service, without wasting too much CPU power and/or bandwidth?
github: https://github.com/kern/filepizza show hn: https://news.ycombinator.com/item?id=9535332