Re: [whatwg] Proposal: HTTP Headers + sessionStorage stored session-ID

> Why not just use cookies ? I feel they're sufficient to do what you need.
> Asked differently: in what way are cookies insufficient so that we need a new different API/feature?

There are substantive differences between the behavior of session cookies vs. sessionStorage. Without re-arguing the whole case for why sessionStorage was a useful addition to the platform, a few observations:

1. Session cookies are preserved at the browser-level, which means they are kept around for the lifetime of the browser instance. sessionStorage, OTOH, is kept only for the lifetime of the tab. In many respects, this makes sessionStorage more desirable for session-based tracking. IOW, several use-cases I'm familiar with would prefer the semantics of sessionStorage expiration when they say "session" as opposed to the old way of session cookies.

2. As a consequence of #1, the most pertinent difference is sessionStorage based session-IDs being attached to an individual tab rather than the browser. This means if I open up two tabs to the same site, and I use session cookies, then both tabs share the same session (can be useful or can be very annoying).

But with a sessionStorage based approach, the two tabs have two entirely separate sessions and operate independently. They can share storage through localStorage, if so desired, and even communicate with StorageEvents. But they can be separate if they want by relying on sessionStorage.

In particular, #2 is a big win (IMO) for session-based architecture (as well as UX) and I often now design my systems with this particular behavior intentionally relied upon.


> I'm worried about your proposal as it reinvents a new sort of cookies with the same issues of current cookies (consequences of ID theft, ability of third-party tracking, XSRF, etc.).

I believe with a proper CSP all of those issues are mitigated. AFAICT there's no additional leakage vectors with sessionStorage (otherwise we'd have major complaints about that system). If you let code run via your trusted CSP, it can gather any info (cookies or not), but if you disallow something (JS from some untrusted location) via CSP, then it does not have any access to your sessionStorage.

Also, it's a "new sort of cookie" that has a very conservative expiration, which further mitigates downsides. As opposed to both cookies and localStorage (which can have nearly "infinite" expiration), a user doesn't have to do anything else to clear out sessionStorage than close a tab. They don't have to "clear cookies" nor do they have to restart their whole browser experience.

So any kind of undesired tracking that may occur with sessionStorage approaches only stays around as long as the tab. To mitigate tracking of real cookies (and/or localStorage), users have to actually use wholly separate "Private Browsing" type windows.


> On designing "sessions" without cookies, I recommand reading http://waterken.sourceforge.net/web-key/ (where everything uses URLs without the need of HTTP headers at all).

I've read that article before. I'm well aware that you *can* design around headers with the URL.

But that's an orthagonal point. If you have decided to design your system with some sort of headers based transmission of data, for any of the variety of reasons people do that (not going to argue that point as it's not relevant here), we're comparing the behavior of session cookies to this sessionStorage "cookie" I've proposed.

------

Importantly, it's the user-experience that I'm getting at with my proposal. With session cookies, a user gets a response from the server directly which is "session aware".

With sessionStorage session IDs, currently, the response from the server on first request (that is, a navigation event in the browser -- bookmark, address bar, foreign link click, etc) is always "session unaware", and then JS on the page/app has to kick in once the page is received and pull out the ID and then perform some other actions to make the page "session aware".

Often times, in SPA architecture, this means that the initial page request isn't terribly useful from the "session aware" perspective, and instead requires not just code to run, but likely subsequent in-page requests to the server, including the session ID, to retrieve the session-aware data and display it on the page.

The UX can be harmed in this case because of the additional delay before a user has a complete page.

If SPAs dislike this, they have very little choice but to fallback to old-school session cookies so session-aware information is available on initial page request. But then they lose the benefits of sessionStorage listed above.




--Kyle

Received on Thursday, 31 October 2013 14:23:23 UTC