Read more on why we built it here: https://retriever.corgea.io/why.html
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 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.
> 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.
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?
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.
However, see further discussion in this article about the difficulties of Web / JavaScript security in this context (i.e. you're depending on the people operating the Web server to not serve different JS on each and every visit).
An even better way to do this would be to use a data: URL instead. That avoids risks associated with a compromised web server.
data:,Put your secret message here.
Am I missing something?
This is what you're missing. Obfuscation is not encryption, and anyone with access to the encrypted data in the URL would not be able to crack it in a reasonable amount of time unless they know something we don't know about public key encryption and SubtleCrypto's implementation of it.
edit: and the problem it's trying to solve are to reach people that you can't just hand a slip of paper of what you want to tell them.
Now if you intercept and replace the URL, they may be in trouble.
[0] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
If the answer is "email, chat, text, Whatsapp" or whatever, them why not just send the secret plaintext?
If anyone can get into any of those systems, then they can easily get your secret from the two urls, so why bother with the encryption?
https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...
How do you prevent the URL from becoming something which needs to be kept secret?
On the one hand, that is down to how you send and receive the URLs. On the other hand, it doesn't make it clear that you should pay attention to that and that it provides no identity authentication.
I guess my only point is that it should be clear that's how it works so people can take appropriate precautions in either case.
1. I share my public key (if not done previously).
2. They encrypt the secret and send the result back, all using whichever tools they'd like.
3. Only I (and any additional recipients specified during encryption) can view the secret data.
See: https://github.com/Corgea/retriever/blob/main/js/crypto.js
Unfortunately this is an anti-feature for almost all large corporations. There is inevitably a security scanner somewhere that consumes the link before the user can.
It’s supposed to be a secure place where secrets are shared, but it comes with Remote Code Executions that are out of the users control. Multiple JavaScript files are loaded from third party hosts to display the page, that would offer a significant attack vectors to your users secrets.
You should both reduce the code dependency on large, external frameworks, as well as verify the necessary files and deliver them from the same host, that already serves the rest of the page (because you‘re going to have to trust that host anyway).
That being said, I agree it’s still a cheap security improvement for OP to control the hosting themselves. (Plus to integrity-check the Vue dependency.)
If we pretend that there are no vulnerabilities today, then the mind turns to what will change in the future.
I tolerate js in the Bitwarden extension because it's necessary, funded, supported and necessary. But Retriever sounds to me like a project that would do better to minimise surface area.
> Retreiver lets you request secrets from anyone without any of the data going to a server.
the sender themself cant even read the returned message from a private window. its just another webapp that invades and disrespects privacy.