Show HN: Peer-to-peer secure file transfer using WebRTC
bitf.ly
bitf.ly
github: https://github.com/kern/filepizza show hn: https://news.ycombinator.com/item?id=9535332
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."
ps: although it says the HTTPS connection is not safe.. weird. pps: lazy me would love a multiple file options ..
cat $FILE | nc -l -p 80For the explicit example above, your guest's firewall would have to be pretty brutal to not allow port 80 through.
The OS may also balk at opening such a low port as a user, now that i think about it.
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.
That said, this is kind of neat.
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.
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.
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.
- 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.
Mega[1] users JS based crypto and it's been fine
[1]: http://mega.co.nz
There are no "good parts" to js browser crypto.
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.
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.
https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey
That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.
Therefore, can't they download the sample just like the connected client?
Source: https://github.com/cowbell/sharedrop Discussion: https://news.ycombinator.com/item?id=7468328
So is it secure or isn't it?
https://github.com/warner/magic-wormhole
It gives you a few words for you to give the recipient, they type them in, and boom, transfer starts.
For regular Internet to Internet media calls I can use XMPP/Jingle client.
...but would probably need WebRTC functionality in Safari to work on iOS devices
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/
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.
If you are worried about security, encrypt before sending.