W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] When closing the browser

From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
Date: Fri, 12 Dec 2008 17:53:14 +0100
Message-ID: <494296FA.7040801@email.it>
Bil Corry ha scritto:
> Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site.  E.g.:
>
> 	leaves site:
> 		closes browser
> 		closes tab
> 		closes window
> 		back/forward to different site
> 		GET/POST to another site
> 		navigates away using address bar
>
> 	returns to site:
> 		reloads page
> 		back/forward to same site
> 		GET/POST to same site
>
>
> For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security.
>
>
> - Bil 
>
>   

That's a nice idea; the before unload event, for instance, might hold a 
boolean attribute telling whether the user is navigating to the same 
domain or not. Anyway, such might fail somehow (or sometimes) if (a 
relevant part of) the webapp were contained in a frame/iframe inside a 
document coming from a different domain.

Actually, I think your proposed behaviour might be worked around with 
short-living persistent cookies (when enabled, of course). For a login 
mechanism fully based on (non-http-only) cookies, setting a short-timed 
expire date (a matter of few seconds) should do the trick: if the user 
action is directed to the same site, the server would recieve the cookie 
before its expiration; when loading a page within the login cookie 
lifetime, the page would change the expiration time accordingly. For a 
more complex (and secure) login mechanism, a short-living persistent 
cookie might hold a 'secondary' session-id with an expiration date set, 
before unloading, so to match a predefined delay: the webapp would issue 
a delayed logout, so that after the choosen delay every session data 
would be invalidated, and the user logged-out; if an attacker grabbed 
such a secondary cookie, he wouldn't get any relevant login information, 
and its suitability for a cross-site attack (e.g. by loading a page from 
the target site before the cookie expiration) would be restricted to an 
arbitrarily short time (such would be a similar strategy to bank token 
generators: imperfect but working).

Otherwise, the user might be prompted for an explicit logout request 
before unloading (as suggested for volatile data). Perhaps a combination 
of three methods (the boolean attribute telling about same-domain 
navigation, a short-living cookie and an explicit choice by the user) 
might improve the overall security.

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CheBanca! La prima banca che ti d? gli interessi in anticipo.
* Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8435&d=12-12
Received on Friday, 12 December 2008 08:53:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC