| Thanks for the feedback. Much appreciated - I'll look into the consistence naming issue. > Features like delete after N visits or by X date might be useful too. Indeed this is an often seen feature. I'll consider it. About the use cases. Not sure I agree - I believe sharing credentials is one of the main purposes of the service. But like you said, it's limited to "transmitting" the secret in a secure way and not meant to act as a "storage". In other words, yes, a recipient should copy the password and store it in a password manager. About the trustworthiness. Yes, trust has to be earned. Without affiliation to Mozilla, Google or other trusted brands it's not an easy task. That said, I think what makes the service trustworthy is the fact that: - It's open source, which means full disclosure - all code and all dependencies can be accessed and reviewed. - The encryption is happening on the client (browser). All code that is executed within the browser can be viewed. You'll notice in devtools that your secret never leaves the browser unencrypted (and the key doesn't get stored). Which means, even if the server infrastructure got compromised, or seized by the government, there is no way of decrypting the messages. tl;dr: It's safe to share "credential to access a production database" :) |