Live data from Hacker News

WebWormHole: Send files quickly using WebRTC

webwormhole.io

111–120 of 161 posts

Re: WebWormHole: Send files quickly using WebRTC

#111
post #39

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.

How exactly would they alter the desktop client I installed from a git clone?

Re: WebWormHole: Send files quickly using WebRTC

#113

i 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.

This is a very different (and equally valid) use case. It does mean somebody (in this case Mozilla) has to spend money on storage to deliver the service.

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
WebRTC is problematic if you're using a VPN service, with the VPN client running on the local machine. Quoting BrowserLeaks:[0]

> 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.

0) https://browserleaks.com/

Re: WebWormHole: Send files quickly using WebRTC

#115
post #33

I'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.

Last I checked (long ago) there is the option for a TURN fallback as well.

Re: WebWormHole: Send files quickly using WebRTC

#116
post #44

Earlier 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?

This is only a personal anecdote, I had two occasions to use it at work:

- 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

#119

Earlier 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 wrote the client then they couldn't alter it, but then if you wrote the WWH site then they couldn't alter that either, so there's no difference.

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

#120
post #14

Earlier 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.

A huge part of the internet cannot just disable NAT. I experience carrier grade NAT from my LTE connection. I only get a single public IPv4 assigned from the two ISPs available at my apartment. How to I "disable" NAT when I only get a single IP but have many devices to connect?
Post reply on HN