Do they do a secure delete of the contents of the webpages? Who knows.
Do they have strong physical protection around the server? Who knows.
Do they run up to date software so the machine can't get taken over? Who knows.
Can you even trust them not to log all your passwords? Who knows.
This is an interesting service for some things, but I would never use it for sending passwords (or anything equally sensitive) back and forth.
I wonder objections there are to running your own service of this type? This way you could guarantee the physical security, keep up with regular patches, manage your own logging, and securely delete the secrets to your satisfaction.
The only real objection I can think of is that writing software without security holes is hard. This applies to any security related software however, and the solution is to use 'proven' apps that have survived scrutiny. This type of app is pretty simple, which would ideally be relatively easy to audit.
In principle, a read-once URL that you can safely send via email seems to be a pretty efficient way of dealing with sending passwords or other keys without having to deal with GPG or similar. Just tell the client 'Click on this link, that's your password. This message will self destruct'. If it's intercepted, you can detect this, and change the password/revoke the key. I'm sure I'm missing something, but if not, it would be nice to have this become the standard way of distributing new passwords or keys for services rather than sending by email (for those services where you have an initial password generated for you).
I don't think this is likely to happen.
Is your delete permanent, if not secure?
"I'm sorry, but we recently reviewed our security practices, and we've found this method of communicating passwords to be incompatible with our dedication to protecting the confidentiality and integrity of your business data. Please use the the password reset form at .. "
User gets URL via webmail on Chrome, Chrome pre-fetches the URL. User closes Chrome because Starbucks is closing. When she finally visits the URL for the "first time" it's nuked.
Unexpected behavior is unexpected.
Therefore, the secret shouldn't be obtained from a GET, but rather a POST. A button or jQuery.post on the 'shared' page, for example, that fetches and causes the deletion.
I like this idea though.
We're considering changing the basic UX to require a click to display the secret (the click will send a POST to retreive the contents). That will include a much more visible disclaimer that it's only available one time.
• loading starts a countdown timer, visible on screen: after that long, the message is destroyed. (In the meantime, an iPad re-download succeeds.)
• the reader sees a big button on the page which must be pressed to complete deletion (or to speed deletion, if the above timer is counting down).
* on initial load, the browser is given a unique cookie (or even decryption key); from then on, even if the message has an additional countdown 'grace period' (of seconds, days, or longer), only that one browser can reload (or decrypt) it.
(That 'problem' wasn't even mentioned in the parent to which I was responding.)
Unexpected behavior doesn't happen every time.
As an optimization, if you have a self hosted service of this sort that gives proper logs, you can probably verify that the link wasn't intercepted by looking at the source IP and comparing to what the user reports (if they're able to do that, if not, you fall back to assuming it was compromised), and if so, skip the revocation/regeneration procedure.
I don't know if it prefetches links in webmail, however, and that would be about the only situation I can think of where this might happen.
Edit: of course, now that I posted this, I can't seem to make it work. I promise it does happen.
Your demo link seems broken, it prefetches a new page every time you mouseover, not just once. Also, there's autoplaying audio ads, something that I can only regard as a bug.
I'm sure there are other issues. GETs are kind of unreliable. Better to do this stuff via POST.
Also, unfortunate for anyone trying to share the secret over the internet: if a repressive regime is sniffing traffic and looking for these URIs and grabs the contents first they can still discover the messages of dissidents before they get passed on.
While I think that this is a good idea, I hink that this would unfortunately result in URLs that would be much too long to be user-friendly - especially if we are talking about sending information to non-technical people.
This doesn't help if the server is malicious, but it does help if the server is honest but is later hacked/subpoenad/whatever. Generating a key entirely in RAM/encrypted swap is reasonable, and securely erasing RAM is easy (securely erasing individual files is nontrivial to say the least.)
I do like the idea though of keeping the secrets safe with a client-side (or non-stored) key. So long as it's known that it isn't about keeping the server honest, since you have to implicitly trust that they won't be storing the key.
Also, pretty cool, if you refresh the private page, it'll tell you whether or not someone has picked up the shared secret. Nice.
It's built with Ruby and Redis behind thin and nginx.
Maybe you could also incorporate the second part. It's obviously not a guarantee the information won't be copied, but if you know you're sending it to someone non-technical, it can be made extremely difficult.
Congrats on the product though.
I'm interested to know what data store you are using (just curious)?
On the other hand the amount of positive comments simply shows how bad user experience do the current solutions like GPG/PGP have and how easy it is for people to choose convenience over security, even on this forum.
That's tongue and cheek obviously b/c you do raise a good point. Do you have any examples we could base one on?
https://off-the-record.appspot.com/ or http://otr.dy.fi/
There is also FAQ: https://off-the-record.appspot.com/faq Any feedback is welcome. There is also secure pickup option on front page. Using it server logs won't show up even retrieved keys. Those could be potentially abused to fetch data from Google's backups.
Thanks for making it.
The reason we use it for passwords is because there's no way to know the application or the user account associated to it.
Do you send confirmation mails, etc after the password is seen so that the sender knows the password got there?
No need for them to have an API.
Can't wait to start using this sucker.
Of course I know what Stella is...now. I clicked on it pretty damn fast as soon as I saw it, because I wanted to know who Stella was and why she was privy to my secret. Do you really not understand why causing the users that moment of doubt is non-optimal?