You can definitely do that. This is just a different mechanism to do so. Your statement could be applied on any secret sharing system that 1password, Bitwarden, Lastpass have. They have a place in the world, and I'm not sure everyone is comfortable with E2E encrypted comms as a way to share secrets.

The whole idea around this was an open-source research project that people can use day-to-day or enhance to share secrets with a zero-knowledge system. What makes this unique is that it's minimal work to do this with a big level of security that you can run on your own.

No, I think the question is: if you're passing the URLs via email, WhatsApp, or anything else, then if that system is compromised then you've revealed the secret.

If you trust that system not to be compromised, then you may as well have just sent the secret plain-text.

In what way or in what scenario does this ever grant you MORE secrecy?

As per the documentation the secret is never shared unencrypted an the private key to decypher it is never ever in the url. It stay in the receiver local storage.

This only means the browser, and the javascript code, are part of the chain. Both of them can also be compromised, have bugs, and leak the secret.

Password managers serve another purpose, which is remembering, filling and storing passwords, possibly in a collaborative way. Exchanging secrets are, to me, secondary in functionality.

> and I'm not sure everyone is comfortable with E2E encrypted comms as a way to share secrets.

I'd live to know what would make people uncomfortable with this, because your system is, in practice, exactly that :)

> What makes this unique is that it's minimal work to do this with a big level of security that you can run on your own.

I love that this can be used over any channel, secure or not, but I would prefer if we all just switched to proper secure communications everywhere. In 2024 there is no good reason not to anymore.

And if I take your point and consider self hosting this, then it's much easier and better to install proper secure communication with my peers.

Again, I'm not against the idea of allowing secure exchange of secrets in an insecure environment, but as engineers if we really want to solve problems we should look at the real one: why are communications not secure, and how to fix this. This is not a technical problem, it's a societal one, and the solution might be societal. Unfortunately as engineers we tend to suck on the social level so we don't want to see it, but it's height time we take the plunge.

People claim E2E yet unless the code is actually open source your believing in faith.

Call me cynical, paranoid but I do not believe the E2E with WhatsApp truly is. It claims to be, yet now owned by the biggest data mining company in existence. How can I trust that?

And don't give me any "three ticks" bullshit. Show me source.

The source for bash was open for years (maybe even 40) before shellshock.

Remember: no matter how big the improvement, it’s not worthwhile unless it achieves absolute perfection.

I never talked about WhatsApp. There are other, working solutions that don't have the problem WhatsApp has.

I suppose generic communication channels have a lot of noise for Big Brother monitors. When someone exchanges Retriever links though, monitors will know that some "secret" is being shared and can focus on potential targets more easily, with a noise filter.

My point was assuming proper e2e encryption, so Big Brother can't know it's a retriever link. It also can't know it's an actual secret

I want an ephemeral channel, with an audit trail of accesses. My regular communications channels provide very nearly the opposite -- they're long-lived, and I can't tell how often folk access them. They might also show history on-screen at times that are inconvenient for security, and I don't know what kind of notifications the recipient has set up.

A tool like Bitwarden Send lets me share a link that references a secret, limit the number of times it may be accessed, and validate out of band (using the secure channel you mention) that the single access I saw was indeed the intended recipient. I can -- and do -- confirm receipt and clear the shared value before putting the secret into whatever system it's intended for.

This seems to have similar properties. I still want an E2E channel for passing the links around, but once the exchange has been verified there's no permanent record of the actual value being exchanged in our chat history.