Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I created scrt.link

blog.stophe.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: Why I created scrt.link

#11

Post by ALittleLight »

cunthorpe wrote: post #4

I’m always wary of consumer services that specifically target secrecy and encryption. How many of those “lockbox” photo apps are just syphons into the developer’s server? “We’ll encrypt the file, trust us.” This message can only come from an already-trusted party. Mozilla had an identical service to this except it was for files (Firefox Send) and that one I could trust.

I wonder if you could do the encryption entirely in the client so it was verifiably secure.

Front end JavaScript generates a symmetric encryption key that is never shared to the server. User enters message. Message is encrypted with the generated key. You create the scrt sending only the ciphertext to the server which doesn't have the key and so couldn't read the message. You click a button to copy both the link to the scrt and the encryption key. You then share both to your recipient. The recipient visits the link and gets the ciphertext and then copies and pastes in the key to see the message.

If it's all done frontend like this then it should be demonstrably secure and only slightly more complicated for the users.

Re: Why I created scrt.link

#12

Post by MrGilbert »

ohazi wrote: post #6
ALittleLight wrote: post #5

Earlier quoted context omitted.

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)

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.

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

Re: Why I created scrt.link

#13

Post by stophecom »

ALittleLight wrote: post #2

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 u…

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

Re: Why I created scrt.link

#14

Post by stophecom »

cunthorpe wrote: post #4

I’m always wary of consumer services that specifically target secrecy and encryption. How many of those “lockbox” photo apps are just syphons into the developer’s server? “We’ll encrypt the file, trust us.” This message can only come from an already-trusted party. Mozilla had an identical service to this except it was for files (Firefox Send) and that one I could trust.

Thanks for the feedback. Appreciate it.

I believe you can earn the necessary trust by being transparent. For this kind of service two things are essential:

- Open source software: Let everyone review your code

- Encryption in the browser. Sensitive information should never leave the browser in plaintext.

I'm considering file transfer - but there are some challenges to meet :)

C.

Re: Why I created scrt.link

#15

Post by stophecom »

ALittleLight wrote: post #11
cunthorpe wrote: post #4

I’m always wary of consumer services that specifically target secrecy and encryption. How many of those “lockbox” photo apps are just syphons into the developer’s server? “We’ll encrypt the file, trust us.” This message can only come from an already-trusted party. Mozilla had an identical service to this except it was for files (Firefox Send) and that one I could trust.

I wonder if you could do the encryption entirely in the client so it was verifiably secure. Front end JavaScript generates a symmetric encryption key that is never shared to the server. User enters message. Message is encrypted with the generated key. You create the scrt sending only the ciphertext to the server which doesn't have the key and so couldn't read the message. You click a button to copy both the link to t…

It is done entirely on the client. You can check the source code. Read more on scrt.link/security.

Re: Why I created scrt.link

#16

Post by weird-eye-issue »

ALittleLight wrote: post #2

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 u…

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.

Re: Why I created scrt.link

#17

Post by weird-eye-issue »

stophecom wrote: post #9
mattowen_uk wrote: post #7

If I pasted a scrt.link to a friend over WhatsApp or Messenger, and the little link preview pops up, does that trigger a visit count, resulting in the message already being destroyed before the friend gets to click on it?

Good question! Bot traffic from common apps/services is beeing blocked. But let me know if you run into a problem. C.

On a related note, I see that getting the secret is a GET request. However, since that request also deletes the secret I think it would be best if it was a POST request. This would probably also automatically fix any issue of a link preview triggering the secret deletion because I think they are designed to not execute POST requests generally speaking (but I could be wrong here).

Re: Why I created scrt.link

#18

Post by stophecom »

weird-eye-issue wrote: post #17
stophecom wrote: post #9

Earlier quoted context omitted.

Good question! Bot traffic from common apps/services is beeing blocked. But let me know if you run into a problem. C.

On a related note, I see that getting the secret is a GET request. However, since that request also deletes the secret I think it would be best if it was a POST request. This would probably also automatically fix any issue of a link preview triggering the secret deletion because I think they are designed to not execute POST requests generally speaking (but I could be wrong here).

Very good point! Thank you. I'll look into this.

Re: Why I created scrt.link

#19

Post by AndrewDucker »

weird-eye-issue wrote: post #16
ALittleLight wrote: post #2

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 u…

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 s…

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

Re: Why I created scrt.link

#20

Post by stophecom »

AndrewDucker wrote: post #19
weird-eye-issue wrote: post #16

Earlier quoted context omitted.

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 s…

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

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).

Post reply on HN