Re: Opting in to cookies - proposal

Maciej Stachowiak wrote:
> 
> 
> On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote:
>>
>>
>>> I must say though, this is starting to sound complex and I am not 
>>> totally convinced of the need to make servers opt in to getting 
>>> cookies. Is it really a likely mistake that someone would take 
>>> affirmative steps to enable cross-site access to a per-user resource, 
>>> but then neglect to check whether requests are cross-site and act 
>>> appropriately?
>>
>> I do think there is a big risk of that yes. I do think that many sites 
>> that today serve public data do have a few pages in there which 
>> contain forms or other pages that serve user specific data.
>>
>> Even something as simple as a news site that largely serves public 
>> news articles might have a cookie where the user has chosen a home 
>> location for local news. This is the case on the news site I use for 
>> example, it usually just serves a standard list of news, but if I give 
>> it my home zip code, it will additionally serve a section of local news.
> 
> I guess I don't see that as a huge risk. In the case of the hypothetical 
> news site, if it is handing out news in some kind of data feed format, 
> wouldn't the point of access-control be to give the personalized feed? 

If the site gives out a personalized feed it has to be *a lot* more 
careful who it gives it out to. It must first ask the user for every 
site it gives the feed to.

If it just gives out non-personalized feeds it can safely share the feed 
with any site.

> After all, you could otherwise use server-to-server communication to get 
> the public data.

Yes, but server-to-server communication has a lot of downsides. First of 
all it greatly increases the latency since the information is 
transferred over two connections rather than one. Second, it means that 
you have to have a server that has enough capacity to tunnel all the 
mashup data for all the users of your site. This can be a significant 
hurdle.

>> This is something that could very easily be overlooked by an 
>> administrator that just configures his server to add a 
>> "Access-Control: allow<*>" header using a site-wide configuration 
>> file, without going through all CGI scripts on the server and teaching 
>> the ones that honor cookies to ignore the cookies for cross-site 
>> requests.
> 
> No site should add "Access-Control: allow<*>" site-wide!

Experiences with Adobes crossdomain.xml show that they do.

> I mean, I guess 
> it's possible people will do this, but people could add 
> "Access-Control-Allow-Credentials" site-wide too. And if we add 
> "Access-Control-Allow-Credentials-I-Really-Mean-It", they'll add even more.

Yes, this is certainly a possibility. But my hope is that this will 
happen to a smaller extent.

> Basically the part of this that worries me is that it requires agreement 
> between the client and the server, but those are expected to be 
> controlled by different parties in many cases. If our favorite news site 
> starts out only offering unpersonalized news feeds to other sites, but 
> then wants to use cookies to personalize, then all existing clients of 
> its cross-site data must change. That seems like a huge burden. Worse 
> yet, if the site changes its mind in the other direction, existing 
> clients break completely.

If you start sharing a new set of data it makes a lot of sense to me 
that people reading that data need to change. This seems no different 
than if you change from sharing an address book to sharing emails. 
Usually someone reading the data would need to both change the URI they 
are reading, as well as how they display the data.

>>> And if the administrator of such a server thoughtlessly enabled 
>>> cross-site access without thinking about the consequences, would they 
>>> not be equally likely to enable cross-site cookies without thinking 
>>> about the consequences?
>>
>> Not more likely than someone adding any other header without knowing 
>> what it does. This is why I designed my proposal such that opting in 
>> to cookies is a separate "step".
> 
> But you are expecting people to add Access-Control without knowing what 
> it does.

It's not a matter of knowing what the spec says, its a matter of knowing 
with 100% certainty that you are not sending any private data on any of 
the URIs you are sharing.

>>> It seems like we are adding a lot of complexity (and therefore more 
>>> opportunity for implementation mistakes) for a marginal reduction in 
>>> the likelihood of server configuration errors.
>>
>> I think the ability to separate sharing of private data from sharing 
>> of public data is a huge help for server operators. So I think this is 
>> much more than a marginal reduction of configuration errors.
> 
> The possibility of making this separation is there - simply ignore 
> Cookie and/or Authorization headers when Access-Control-Origin is 
> present. So this opt-in doesn't offer a new capability, just changes the 
> defaults.

In many server technologies it's not trivial to ignore cookies and/or 
auth headers. Session handling tends to be handled before the "CGI" 
script starts which means that you have to weed though the whole code to 
ensure that no code uses the stored session state.

> 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.

The cost and risk of adding an extra boolean to XMLHttpRequest seems 
much lower.

/ Jonas

Received on Thursday, 19 June 2008 20:48:30 UTC