5 ms·
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
by mapgrep 15y ago
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.
Etc. etc.
Unexpected behavior is unexpected.
- delano 15y agoYou 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.
- mapgrep 15y agoUsing a POST seems like a solid workaround. It might even be possible to include a POST form from your default email notification.
- joeyespo 15y agoData 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. I like this idea though.
- true_religion 15y agoChrome prefetches DNS, not URLs.
- drzaiusapelord 15y agoChrome is testing pre-fetching in beta builds and its expected to become part of the mainline product soon. I'm sure there are other issues. GETs are kind of unreliable. Better to do this stuff via POST.
- alastairpat 15y agoChrome 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 15y agoI've been using prefetching on chrome for a few days now on a heavily trafficked image site, it appears to the user that clicking next is instant as the next image is already rendered. Example of code is here. http://grahamholborn.com/prerender.js http://grahamholborn.com/prerender.js example in action(chrome only, open chromes task manager, once you hover over image it will run prerender. http://www.diftl.com/random http://www.diftl.com/random
- sbierwagen 15y agoGDH: 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.
- mivok 15y agoThen 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.
- stouset 15y agoAn 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.
- gojomo 15y agoSome interesting variants are thusly suggested: • 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.