Magic Wormhole is one of my absolute favourite tools.
see also https://wormhole.app/
see also https://wormhole.app/
aww, thanks :)
BTW for anyone reading, https://wormhole.app/ is awesome and serves a very similar purpose, but uses entirely different technology (no PAKE) and has a different security model.
In my (https://magic-wormhole.io) world, we've kicked around ways to make a good browser-based client (and I've tried to prepare the protocols to work well there), but I haven't had time to pursue any of them. The tasks include 1: port everything to JS (or take the core of the Rust port and compile it to WASM, then write an IO layer in JS), 2: glue it to the browser's file/blob upload/download APIs, 3: settle on a trusted-application security model.
To make it work in a vanilla browser with no setup phase, you're pretty much limited to relying upon the webserver from which you get the page, which is the model wormhole.app provides. Other options include using an addon (which shifts the reliance set slightly), or running some sort of Electron thing (making it not really a browser app) that you get from some distribution channel (debian, homebrew, etc) which shifts the reliance set in a better direction.. at least you're probably getting the same application as everybody else using that distribution, vs a webserver that could conceivably serve up a different version each time.
There is a world of difference between what Magic Wormhole can promise and what Wormhole.app can promise. Magic Wormhole relies entirely on clientside cryptography; once you have it installed, you can trust that it's doing what it says on the tin. Which means you can reasonably use it operationally.
"Wormhole.app" --- which has a frustrating name, given the distinction --- demands that you trust the server, since the server can on every transaction defeat the cryptography you're using.
If someone owns up a Magic Wormhole relay server, there's not much they can plausibly do to intercept the files you send. But if someone owns up Wormhole.app, they can, I believe, quietly pick up and store people's files.
Incidentally, apropos none of this: I've been using the Golang https://github.com/psanford/wormhole-william port on some of my machines for a year now, interoperating with the standard Python Magic Wormhole, and it works great.
Magic Wormhole is an achievement. I wrote a blog post about modern cryptographic tools, and what I have to say about Magic Wormhole is that everyone I've introduced to it immediately starts wormholing all sorts of stuff; it's kind of addictive. Thanks for designing it!
I'm Brian Warner.
The standard criticism of web-based apps is that you have no guarantee that the code you receive will be the same as that which you received on your previous visit. (This ignores problems with self-updating desktop apps, but let's pretend users make informed decisions about every new version published).
Fortunately there is, at least in principal, a way of achieving TOFU for web apps. It relies on the bookmarklet/SRI trick[0], which lets the user store the hash of a script which bootloads the rest of the application. The major downside with this is that the browser's address bar shows a Data URI rather than the domain of your app. That limitation wouldn't exist, though, if browsers supported Hashlinks[1].
[0] https://news.ycombinator.com/item?id=17776456
[1] https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-...
It uses a pair of helper servers (that I run), for which the source is also on github. But the protocol (implemented in the client, not the server) is carefully designed to be resistant against server misbehavior.
So you can either study the client and convince yourself the protocol is indeed secure, or rely upon my claims that my code is working as advertised. But you don't need to rely upon my claims that my servers are not snooping or interfering: that's protected by the protocol.
This is what I could find for wormhole.app source: https://github.com/SocketDev/wormhole-crypto