Re: Opting in to cookies - proposal

Maciej Stachowiak wrote:
> 
> On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote:
> 
>> Maciej Stachowiak wrote:
>>>
>>> After reviewing your comments, I am much more inclined to favor 
>>> Microsoft's proposal on this: rename the relevant headers. I think 
>>> you argued that this "doesn't scale", but I think only two headers 
>>> have to be renamed, "Cookie" and "Authorization". Note that other 
>>> authentication-related headers, if any, do not need to be renamed, 
>>> because without the "Authorization" header being present, no other 
>>> authentication processing will take place. If the headers have 
>>> different names, it's very hard to reveal private data accidentally. 
>>> No site-wide blanket addition with headers will cause it, you have to 
>>> go out of your way to process an extra header and treat it the same 
>>> as "Cookie". It would allow allow servers to choose whether to offer 
>>> personalized or public data and change their mind at any time, 
>>> without having to change clients of the data. It would also work for 
>>> inclusion of cross-site data via mechanisms that don't have a 
>>> convenient way to add an out of band flag.
>>> The only downside I can think of to this approach is that it may 
>>> break load balancers that look at cookies, unless they are changed to 
>>> also consider the new header ("Cross-Site-Cookie"?).
>>
>> Using different header names would certainly address the concern I 
>> have regarding reducing the risk that private data is inadvertently 
>> leaked.
>>
>> However I think the downsides are pretty big. The load balancer issue 
>> you bring up is just one example. Another is that I think caching 
>> proxies today avoid caching data that is requested using 
>> Authentication headers. Probably the same is true for the cookie 
>> header in some configurations.
>>
>> I think going against the HTTP spec carries big unknown risks. I'm 
>> sure others with more HTTP experience than me can chime in here better.
> 
> I don't see how this would go against HTTP. It's perfectly valid HTTP to 
> not send "Cookie" or "Authorization" headers, and also valid to send 
> whatever custom headers you want if agreed upon with the server.

You are sending data that the HTTP spec specifies should be sent over an 
Authorization header over another header instead.

In any case, if you are breaking the letter and/or spirit of the spec is 
of little matter. What matters is the actual effects are of sending this 
information over new header names are.

>> The cost and risk of adding an extra boolean to XMLHttpRequest seems 
>> much lower.
> 
> The cost of tying server-side changes to client-side changes for a 
> cross-site communication technology seems like a very high cost to me. I 
> don't buy the argument that it's normal to change when you change what 
> data you are reading - the data being personalized (or not) is a 
> different kind of change from changing the type of data you read. To 
> compare to the user-level example, GMail and GCal are different URLs, 
> but nytimes.com is the same URL whether I'm logged in or not.

First of all I'm unconvinced that this will happen in reality. Can you 
explain a usecase when a site would want to go from changing from public 
data to private data, without changing anything else? And is this common 
enough that we need to cater to it?

When you are sending personalized data you pretty much have to have a 
pretty different API anyway. At the very least the mashup sites will 
have to deal with access being denied and display some UI to the user, 
or redirect the user to the content site to log in and/or authorize the 
mashup site to read the data.

I would think that in most cases you would keep the old URI serving the 
public data, and set up a new URI where you can fetch the private data.

It might be a small change implementation wise, but semantically and 
security wise it's a big difference between serving public and private data.

/ Jonas

Received on Thursday, 19 June 2008 23:17:14 UTC