Re: To cookie or not to cookie

On Tue, 26 Feb 2008, Jonas Sicking wrote:
> 
> So at this point there are a few ways forward:
> 
> 1. We can leave the spec as is and say that mozilla is intentionally
>    only implementing a subset of the spec at this point.

This would effectively change the spec, since no other browser could ever 
go ahead and send cookies with the same semantics, since servers deployed 
for mozilla would liekly be immediately vulnerable.


> 2. We can change the spec to say that cookies should never be sent.

I think that would so significantly reduce the usefulness of the spec as 
to make it largely pointless.


> 3. We can change the spec to allow for requests both that include
>    cookies, and requests that don't include them. We'd further say
>    that before the UA makes a request that do include cookies it
>    should get the users permission to do so first.

I think any required UI interaction here would be a horrible idea, since 
there's no way users will understand what we're asking them.


> That wouldn't actually change anything at all. The major concern is 
> sites sending replies that contain the users private data to GET 
> requests that include cookies. This will happen even if the reply can't 
> set additional cookies.

Why would such sites ever send back data with an Access-Control header? 
The whole point here is that the server will only allow the client to see 
the data if the server is ok with it. The server knows if there were 
cookies, and can control which sites see the data. What's the problem?


I personally would recommend that Mozilla simply not implement cross-site 
XHR if it can't be done with cookies, and instead allow another browser to 
forge the new ground and set the precedent.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 26 February 2008 21:00:35 UTC