[prev in list] [next in list] [prev in thread] [next in thread] 

List:       whatwg
Subject:    Re: [whatwg] Proposal: HTTP Headers + sessionStorage stored session-ID
From:       Kyle Simpson <getify () gmail ! com>
Date:       2013-10-31 14:22:51
Message-ID: 2ED06819-EA55-49CF-8818-59FC0B236A0E () gmail ! com
[Download RAW message or body]

> 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






[prev in list] [next in list] [prev in thread] [next in thread]