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

Hi Kyle,

Le 30/10/2013 22:54, Kyle Simpson a écrit :
> Thoughts?

Kyle wrote:
> BUT we cannot, currently, have that sessionStorage-stored session-ID 
> automatically transmitted with each normal page request.
>
> This means that the initial page-response from the server, even in the 
> case where someone has a valid session, must be session-unaware, and 
> the SPA code on the client side must update the page with 
> session-aware info "later", since the session-ID on the client wasn't 
> provided with the initial HTTP request like a session-cookie would 
> have been.
>
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?

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.). On cookies, I recommand 
reading the 6.3.4.2 section of 
https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm 
(notice it's been written a bit before 2000 so with an understanding of 
the web back then).
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).

Cookies were a mistake. They've made web dev (marginally?) easier, but 
I'm not sure their cost in terms of security and privacy (after a year 
of trying hard, Mozilla still fails at getting rid of 3rd party cookies) 
was worth it. If we applied the principle of constituency on cookies 
today, they'd probably be refused right away... but we can't go back of 
course. Yet another web regret.

David

Received on Thursday, 31 October 2013 11:02:23 UTC