[lotharrr]

One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.

I think it's a 2-out-of-3 trilemma: end-to-end encryption, short codes/URLs, offline/non-interactive workflow: choose two. Or framed differently, if you require proper encryption, then either the code/URL must be long enough to hold the full key, or you must use an interactive (PAKE) protocol which means both agents must be running at the same time (babysitting).

Your last point is an interesting one: we could build a form of magic-wormhole where the sender's CLI waits, the recipient gets a URL, the URL points to a web page which performs the client side of the protocol. The server wouldn't host the file, just the decryption agent. Basically wormhole receive in a browser. That would match many of your goals.

However I'd be hesitant to do this with magic-wormhole because it opens up a vulnerability we don't currently have: the web server hosting that page could silently swap out the JS with a version that retained a copy of the plaintext, perhaps only when the browser is coming from a specific IP. You can't audit a webserver for consistent+correct behavior the way you could with e.g. the contents of a Debian distribution.

That said, the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.

(I'm the author of magic-wormhole)

[latexr]

> a "simple URL" isn't big enough to hold a full-entropy encryption key.

I don’t care about that most of the time. When I do I’m unlikely to trust some random web service anyway (how do I know the author didn’t turn rogue the day before and decided to send a copy of every file to their own server?).

The service could offer a choice, where picking the short link comes with a big red warning. That could even be hidden under some setting on the page, since it’s the sender who needs to understand the implications.

> the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.

That’s exactly what I’m looking for. Whenever I need one of these services, there is 0% chance the person on the other side would know how (or have the patience) to install a command-line tool.

> I'm the author of magic-wormhole

Thank you for taking the time to expand so thoroughly from experience.

[rahimnathwani]

Just use a link shortener?

[latexr]

The goal is to reduce complexity, not tack on more crap on top. The solution I have now with PairDrop is already more convenient than that.

[jech]

> One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key.

If you trust the server not to MITM you, then you don't need the encryption key in the URL. The URL only needs to be long enough so it cannot be guessed by an attacker, 64 bits should be plenty. Once the peers connect to the common URL, they can generate an arbitrarily large key by performing ECDH through the server. (This is where you assume that the server is not doing MITM.)

[m463]

I wonder if you can use something simple like numbers to get it started, then use something in the poster's phone conversation can authenticate it.

Basically type in encoded/crc'd ip address then some code over phone to start session

(none of this requiring someone else's servers/etc)