4 ms·
(author of magic-wormhole here) aww, thanks :) BTW for anyone reading, https://wormhole.app/ https://wormhole.app/ is awesome and serves a very similar purpos
by lotharrr 5y ago
(author of magic-wormhole here)
aww, thanks :)
BTW for anyone reading, https://wormhole.app/ 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 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.
- ccmcarey 5y agoFYI looks like magic-wormhole.io doesn't listen on 443, only on port 80 (which redicts to github).
- tptacek 5y agoFor what it's worth, and I know you're not looking for this fight, but I think it's important: 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 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!
- mynameisash 5y agoI _really_ want to see the Rust version get more mature and see this made into a browser plugin. I keep mulling over trying to help out with the project, at least on the Rust side (since I know nothing about WASM).
- psanford 5y agoThere are some folks who have a fork of Wormhole William that runs in the browser (via wasm) and uses a websocket based relay (keeping the rest of the Magic Wormhole protocol the same): https://github.com/psanford/wormhole-william/pull/49 https://github.com/psanford/wormhole-william/pull/49
- throwaway67114 5y agoEdit: sorry made some blunder. You are Brian, just saw on your profile.
- lotharrr 5y agoEdit: no worries, I just added it there a minute ago, didn't realize I'd left that box blank. I'm Brian Warner.
- dane-pgp 5y agoIf you're looking at trusted-application security models, you've probably considered TOFU and what I call BEEF (Beware Each and Every Fetch). 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 https://news.ycombinator.com/item?id=17776456 [1] https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-07 https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-...