Thanks HN: we just launched the One-Time Secret beta based on your feedback | Hacker News Reader

Thanks HN: we just launched the One-Time Secret beta based on your feedback

30 pointsdelano19 comments

We got a lot of feedback last month on our post about the alpha launch of onetimesecret.com ( https://news.ycombinator.com/item?id=3207489 ). We were blown away by the amount of interest so we spent more time working on it and talking to more people. We just upgraded the site to beta which includes new features and a lot of improvements.

It would be awesome to get more feedback but more importantly I wanted to mention that we've included a free plan for HNers. (You might notice that we're A/B testing another free plan -- the key difference is that this one will be free forever.)

So thank you and let me know what we can do better!

View on HN

What do you do about database back ups? Do you not back up those tables or do you wipe out the backups after a couple of days?

Ya, that's a great question. We've thought a lot about backups. We delete secrets immediately after they're viewed which presents an interesting problem with regards to keeping backups.

We're probably going to take a route similar to Wikipedia, where we don't intend to be the primary repository of information. During the beta, we'll keep backups for a limited time (the past few hours) but that's it. In other words, we'd rather lose an hour of two of data than expose secrets to 3rd parties. We'll consider other options when we fully launch.

Note: this only applies to secrets data. Customer and related data is backed up as you'd expect.

Depending on what database you use you can do partial replication (only tables that aren't secrets) to a slave and then backup the slave. We use MySQL and that is possible. Also if you combine that with a high rotation rate on your binlogs (again mysql) and wipe out the older logs you can effectively have a slave with all of the "permanent" data and then only two hours of binlogs of everything. So in case of disaster you copy the slave back and then replay the binlogs you kept (a couple hours) for secrets and you are back where you started. But since you never replicated the secrets or kept more than 2 hours of binlogs you have no way of recovering the secrets outside of that window.

Ive used these type of encrypted messages before but with little success or the glitches are many. Ive begun using One-Time secret and it works first try with no issues. Glad to see someone doing it right.

I actually used this other other day to transmit a root password for a server. Not sure how often this happens but contrary to my own belief there appears to be a market for this sort of thing.

We totally thought the usecases were going to be pretty limited but as it's turned out we've been getting a lot of great feedback from outside of the tech community too.

Drew Carey of all people retweeted it:

https://twitter.com/DrewFromTV/status/142730130689761280

I would hope you wouldn't know this from the service itself, but do you know what use cases people are using it for based on feedback? I suspect there may be something its being used for I had not considered and might actually use.

For tech people, we've had the most questions regarding our API (password resets, one-time pads, custom encryption) and also the ability to have custom installs that are separate from the multi-tenant instance (e.g. we now have a paid plan for agencies that does this).

For non-tech people, we've got a lot of feedback along the lines of whistle-blowing, "if only Anthony Weiner had known about this", etc.

Edit: and yes, just to be clear, we do not look at the secrets that we keep. We encrypt all secrets before they're stored. If you include a passphrase, we use that as part of the encryption key and we since don't store that passphrase we have no way to decrypt the secret. It's technically possible for us to decrypt passphrase-lee secrets but we'd have to go out of our way to do it.

Clickable link: https://onetimesecret.com/

(The previous post for our alpha: https://news.ycombinator.com/item?id=3207489)

Didn't Peter F Hamilton write about a future with "one time email addresses"? I like the idea of this, but I want to see it able to handle photos, video, and audio.

i was thinking along the same lines with the picture, audio etc. the only downside is if you send a picture to someone and want it destroyed right after there is nothing stopping the other end to save the picture locally on their computer.

it'd be nice where you could send a picture to someone and then it would be destroyed without allowing them to download it. (eg. anthony weiner would have loved that one!!)

How does one sign up for the HN plan? I simply see the option to sign up for a personal plan; will this expire?

We're only displaying it for people coming from HN. This should work:

https://onetimesecret.com/pricing

(If not, delete the sessid cookie for onetimesecret.com.)

I had already created a free beta account, any way to switch it over? There doesn't appear to be any way to delete my account and create a new one.

Sent you an email. Let me know if you need anything else.

I don't see much use for this outside the send-a-password use-case. For that it seems like one of those things that might be convenient if I need to send a password/username to a buddy but for anything at all official I don't think you will get users. Most places don't want people going out to 3rd party sites for sensitive data.

I agree that 3rd party services can be less than ideal, and sometimes really undesirable for some contexts. The reality though, is that people need to communicate these things, whether they be passwords, or tidbits of info that they don't really want to persists. The current way that they do it is via IM or email, which now get logged, stored, indexed, etc. by the client software or middle-man service providers. While we don't expect or recommend that companies put ultra sensitive data into our system (at least, not without strong encryption), we feel it does fill the more common need. We're pleasantly surprised at how many other people agree too.

it should reply to json requests with immediate secrete 'release' w/o the extra button clicking and in a simple json format. This will allow usage from bots etc.

Our API for authenticated users will support this.

Reply on news.ycombinator.com