[ALittleLight]

I just created and consumed a secret message. It seemed to work. Plus, I didn't have to create an account. Easy to use. I also love the name.

I noticed in the FAQ you refer to your three secret types as text, redirect, and neogram. In other places you seem to call redirect "link". Could be a naming consistency fix.

Features like delete after N visits or by X date might be useful too.

I'm a little confused about the use case. Maybe I'm boring, but who would I need to send a scrt.link to? I can think of bad use cases, for example maybe a botnet could propagate messages through this, or share credentials that would change after using or something. I can't really think of other use cases though without going a bit unrealistic.

I read the FAQ about why I should use it. I'm not sure it's great for credentials because if they aren't continually going to be available through the link, the other party will need to copy them.

If I'm doing something with minor security concerns, e.g. sharing the Netflix password, I'm just going to send it over text or whatever. If it gets compromised I'll just reset and change it. If I'm doing something with significant security concerns, e.g. sharing credential to access a production database at work, then I'm obviously not going to use this due to trustworthiness concerns.

[weird-eye-issue]

I use a similar service for when I need to share passwords in between the importance of a Netflix account and a production database.

For example, if I need to give access to an assistant to access my ShutterStock account to avoid paying ShutterStock an additional $350/month. I don't want that password sitting in email because that just isn't good practice. But I also don't need a full blown team password management system right now.

[AndrewDucker]

If the link is sitting in their email then surely that's just as unsafe as having the password there?

[stophecom]

Not exactly. Sure, if your email is compromised someone could access the secret link, and ultimately your password. But now, you will know that someone else had access to your password, since the link won't work for you anymore. This is crucial information.

Btw. You can encrypt your secret with an optional password (which may be shared via a different channel).

[weird-eye-issue]

No, it expires after they view it.

[jgalt212]

Yes, this is a nice solution, but email security services do click on links before delivering to the client's email inbox. As such, you may need to set the link expiry click number to greater than 1. And then you lose the security due to being ephemeral. Of course, you can log the IP addresses of the clickers, but still you have the leak.

[stophecom]

> email security services do click on links before delivering to the client's email inbox

True. This may be a problem. Like mentioned, common bots are being blocked currently, plus, I will be testing POST instead of GET requests (Since bots apparently don't do POST). An another obvious solution is to include some kind of user interaction before the secret is fetched. Although I don't like that solution so much. C.

[weird-eye-issue]

In practice this has not been a problem. It's like saying you can't put unsubscribe links in emails because a bot will click on it... You just simply design the software so that doesn't happen.

Like I said, I've used a similar service that only allows you to view the secret once and I've used it dozens of times with no problems.

[jgalt212]

> you just simply design the software so that doesn't happen.

How do you go about doing that? disregard security service clicks based on IP address blacklists, user agent sniffing, etc?

[stophecom]

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" :)

[senectus1]

someone in an abusive relationship?

whistleblower?

plenty of scenarios

[ALittleLight]

I don't understand. If I'm in an abusive relationship or am a whistleblower why would I want to send a read-once message? Why is this better than pastebin? (Which, incidentally has this as an optional feature)

[ohazi]

If you trust the recipient, but there's a chance that they will be threatened and asked/forced to reveal the message that you sent them, they may appreciate a mechanism that gives them plausible deniability.

Obviously a recipient could make a copy of any disappearing message that they receive if they really wanted to, so you do need to actually trust them. It's less for your security, and more for theirs.

[senectus1]

yup, also you can trust the person but maybe not trust their long term security. the short the lifespan the small surface of attack.

[MrGilbert]

Depends on "they", I guess. Plausible deniability goes south, once you are greeted with a wrench. Reminds me of https://xkcd.com/538/