This is an ingenious idea, one that becomes obvious only in retrospect. To me this feels like a merger of the ideas in projects like magic-wormhole, Wormhole.a

This is an ingenious idea, one that becomes obvious only in retrospect. To me this feels like a merger of the ideas in projects like magic-wormhole, Wormhole.app, and the (defunct) Mozilla Send. But then it adds a kind of sharchive twist using the browser as a runtime. The original paper I saw called it Password Authenticated Key Exchange. https://www.cs.columbia.edu/~smb/papers/neke.pdf https://www.cs.columbia.edu/~smb/papers/neke.pdf But I think the general form is now called something like this: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement?wprov=sfti1 https://en.wikipedia.org/wiki/Password-authenticated_key_agr... Anyway I’m posting all this not to show my erudition (I’m really stupid about cryptography) but that there’s lots of precedent for this kind of tool and maybe with a few tweaks can even be made standards-compliant. (RFC 8188 seems to contemplate some ideas like this, but the file isn’t “self-expanding”.) Some obvious issues: sitting on a thumb drive, the file is vulnerable to unlimited attacks. And since the decryptor is in “plaintext” it could be MITMed in a way, since the decryption code can be tampered with, and a browser environment with localhost access can be tricked into doing lots of things, including sending decrypted contents to the attacker. In a SaaS there’s no MITM given transport security, and you can notice you’re getting attacked, or expire links after a number of tries / some amount of time. But so what; the whole point here is to provide really good security with a different channel.