Performing a cryptographic penetration test every time you (or, behind your back, your browser) loads a page is a problematic strategy for deploying cryptography on the Internet.

I think the previous comment came across as snark, but it's not snarking; it's a genuine suggestion. The thing they're trying to build can work, and find users, without the performative cryptography.

Agreed on continuous code audit issue! This is the non-resolvable problem with browser-based services.

But I think the cryptography is not entirely performative, and your suggestion of a UUID KVS is not the same model.

In Retriever's model, as I understand it, Alice generates the keypair which Bob will use to send data to Alice. Alice sends the pubkey to Bob (via URL) and Bob encrypts and submits. Bob then sends a new URL to Alice to decrypt and read. (Not sure why this second URL exchange is necessary, unless it contains the encrypted data?).

Only the original receiver (and Retriever/page host) can decrypt the data. Neither of the URLs are secrets, although possession of the first URL would allow an attacker to encrypt arbitrary messages for Bob, and maybe that's why Bob waits for Alice to send the second URL.

That said, it's a fun experiment but too awkward for anything but ad hoc secret sharing between strangers with no better comms channels. Which is not something I do.

I'm not sure I follow. What is the degree of assurance the cryptographic version of this web page can provide that a UUID and a database can't? Remember, the web page can itself surreptitiously decrypt anything Alice or Bob encrypt or decrypt.

Zero, unless you host it yourself.

Agreed, not practical but a bit more involved (both simpler and more complicated) than a UUID KVS.

Right but that works just as well to determine that some js that just uses ordinary network-layer security to send some data doesn't steal anything.