User receives password URL on an iPad, opens it, loads the destination login page, switches back to password tab, but it's gone forever because the iPad closed it to harvest memory.
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.
Data shouldn't change on a GET for these very reasons.
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.
An interesting approach would be to delete the original data, but issue an ETag to leverage browser caching. If the original user rerequests the page while it's still in the browser's persistent cache, the server can simply return a 304 Not Modified, and the user still sees their data. Anyone else, though, is SOL.
You raise some great usecases. We have an option to require a password to view the secret but that doesn't directly solve the cases you bring up.
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.
Then the receiver reports to the sender that the link didn't work. The sender, not knowing if the password was compromised or if it was a situation you mentioned above, changes the password/revokes the key and generates a new one. This time, the receiver doesn't access it at closing time in Starbucks/doesn't switch tabs, and gets the new password correctly.
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.
Chrome beta does prefetch URLs: download the latest version, go to a Wikipedia page, wait a few seconds then click the first link – it should appear (almost) instantly.
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.
GDH: your reply to this comment is not visible: you've been hellbanned. It appears to have been for a comment you made 312 days ago.
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.
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.
Etc. etc.
Unexpected behavior is unexpected.