- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 07 May 2012 11:32:50 -0400
On 5/7/12 3:53 AM, Tab Atkins Jr. wrote: > A page can set up an unloadHandler immediately on loading, and just > keep its .data property updated over time. The author is then secure > in the knowledge that, barring complete computer destruction, if the > user shuts down their browser the server will receive a message with > whatever .data held at the time. Where "complete computer destruction" includes "browser crash" and several similar things? I don't think that it's reasonable to require the browser to send the request after the browser process has exited: for one thing the browser may not have access to non-volatile storage at all. Presumably the request involved would never do any prompting for credentials; if they're needed it would fail? Also presumably the browser would be allowed to kill the connection once it receives the first response packet, instead of having to download all the response data? That would be a win from the browser's point of view. > 1. The author doesn't have to use fiddly hacks to avoid their request > getting killed as the page unloads. Yes. > 2. The browser can go ahead and kill the page immediately, and send > the request at its leisure. I guess that's true if "bar" is converted to a string at foo.data set time. A bigger question is whether browsers really want to make it easier to do this or work on getting rid of the ability to phone home at/after unload altogether. My gut reaction every time I see pages doing it is that they're up to no good, and code inspection usually indicates that I'm right: the #1 use of this is for persistent user tracking. -Boris
Received on Monday, 7 May 2012 08:32:50 UTC