This is neat, but it seems like unlike with "real" Magic Wormhole, the server here can capture files by surreptitiously manipulating JS.
Although of course the people supplying your "real" Magic Wormhole might have surreptitiously altered that software to capture the file too... I think these are similarly likely and have similar (but not identical) mitigations if you're worried you would really be a target for such shenanigans.
WebWormHole: Send files quickly using WebRTC
111–120 of 161 posts
Re: WebWormHole: Send files quickly using WebRTC
#112Very nice! I'm assuming this is based on the wonderful "Magic Wormhole"? Is it actually using that program under the hood?
Re: WebWormHole: Send files quickly using WebRTC
#113i like the approach of encrypting locally, uploading to the cloud and sending the decryption key via a link. that's the way firefox send does it https://send.firefox.com it's open source so you could run an instance of it if you wanted to.
Wormhole-style systems don't need to store the data because it's flowing from the sender to the recipient live.
Re: WebWormHole: Send files quickly using WebRTC
#114> IP address detection using JavaScript. Starting work on WebRTC API, the web browser communicates with the STUN server and shares information about local and public IP addresses even if you are behind NAT and use a VPN or Proxy. This tool will show if your real public IP is leaking out.
However, if you run the VPN client on the router, there's no problem, because the local machine has no public IP address, just LAN and VPN interface addresses.
Re: WebWormHole: Send files quickly using WebRTC
#115I'm not as familiar with WebRTCPeerConnection as I'd like to be. Does it use the STUN server to get it's real IP and after that we can establish a completely peer to peer connection and now the webserver has no interaction with WebRTCPeer stream? If any of that is wrong, please enlighten me, I didn't realize peer to peer connections could be as simple as this.
Re: WebWormHole: Send files quickly using WebRTC
#116Earlier quoted context omitted.
Things have changed (alot!) the last two years have seen a couple implementations come around. * https://github.com/pion/webrtc * https://github.com/aiortc/aiortc * https://gstreamer.freedesktop.org/documentation/webrtc/index... * https://github.com/rawrtc/rawrtc
Ooh, these are very cool. Do you know what sorts of things people are building with them?
- I wanted to setup ssh access to some machines in a complicated network in a shared office, over which I had no control. After trying various NAT traversal hacks, I realized the potential of WebRTC to do all that for me, and setup ssh over webrtc. I made it from a bunch of hacks, but some people seem to have built that properly now, ex: https://github.com/mxseba/rtc-ssh
- I built some tech demos that needed to run on multiple OS and use the webcam. Initially I relied on opencv, but I needed to dockerize things and outside of Linux the webcam device passthrough is a pain. Instead I made a simple webpage fetching the video feed and talking to a python backend (using this great library: https://github.com/aiortc/aiortc), and it worked nicely. It also has been surprisingly easy to setup.
Re: WebWormHole: Send files quickly using WebRTC
#117Re: WebWormHole: Send files quickly using WebRTC
#118I want to host it on my router.
Re: WebWormHole: Send files quickly using WebRTC
#119Earlier quoted context omitted.
Although of course the people supplying your "real" Magic Wormhole might have surreptitiously altered that software to capture the file too... I think these are similarly likely and have similar (but not identical) mitigations if you're worried you would really be a target for such shenanigans.
How exactly would they alter the desktop client I installed from a git clone?
If you're running code from a clone of somebody's git repo you're vulnerable to anything they did to that code, just as if you're running code from a web site you're vulnerable to anything they did in that site.
There are marginal differences, and I'm guessing the one you're really excited about is maybe the web site changes moment-by-moment to introduce and remove betrayal mechanics whereas your git clone doesn't change moment-by-moment. Of course that cuts both ways - bugs can be fixed in the site immediately and your clone doesn't magically get bugfixed.
But mostly I'm arguing these are the same problem: Do you trust some well-wisher who has seemingly no reason to betray you? You probably should, life is too short.
Re: WebWormHole: Send files quickly using WebRTC
#120Earlier quoted context omitted.
I blame NAT. Treating end-users like second-class netizen consumers trained people to "need" the cloud to do perfectly normal peer-to-peer things.
I'm not sure I would blame NAT. You can easily disable that. What you can't disable is the asymmetry of consumer internet connections (upload << download) and the fact that most consumer devices are not running (or connected to the internet) 24/7.