Re: Opting in to cookies - proposal version 3

Ian Hickson wrote:
> On Thu, 19 Jun 2008, Jonas Sicking wrote:
>>> So I guess I don't really understand what your proposal solves, then. 
>>> It seems like a lot of complexity for only a very minimal gain in only 
>>> one very specific scenario (the site doesn't ever return cookie-based 
>>> data cross-site). We're still relying on the author not making 
>>> mistakes, despite "the author will make a mistake" being our 
>>> underlying assumption. If the site has to know to not include the 
>>> cookie opt-in header, why not just have the site ignore the cookies? 
>>> (It also introduces the problems that Maciej mentioned, which I think 
>>> are valid problems.)
>> Well, we are talking about two very different types of misstakes, which 
>> I think have very different likelyhoods of happening. If I understand 
>> you correctly.
>>
>> One misstake is having URIs in the URI space where you opt in to 
>> Access-Control which serve private data without you realizing it.
>>
>> The other mistake is intentionally publishing private data but 
>> forgetting to ask your users first before doing so.
>>
>> Seems to me that the former is a lot more likely than the latter.
> 
> Right but the mistake that we're not doing anything about and which seems 
> likely to be far more common than either of those is:
> 
> Having URIs in the URI space where you opt in to Access-Control _and_ opt 
> in to cookies which serve or affect private data without you realizing it.

Yes, the best way I can think of to reduce this risk is to reduce the
number of URIs where you opt in to cookies. That is what my proposal
tries to accomplish.

> That is, your solution only works so long as the site doesn't ever opt in 
> to cookies. Which seems uncommon.

This is not true. You can opt in to cookies on just a subset of the
URIs where you opt in to Access-Control with my proposal.

Additionally, this way you can make sure to ask the user always before 
sending the Access-Control-With-Credentials header. This way the risk of 
leaking private data without the user realizing is further reduced.

If cookies are always turned on for Access-Control there will be many 
situations where you will want to enable Access-Control without asking a 
user since you are not sending the users private data.

> (I'm assuming that the case of providing data cross-domain for simple GET 
> requests is most easily handled just by having that script send back the 
> right magic, in which case none of this applies as the URI space is one 
> URI and there are no preflights at all. For this use case we don't have 
> to worry about cookies at all as the server just wouldn't look at them.)

I'm not following what you are saying here. What script is "that 
script"? And what is the "right magic"?

I am just as concerned about GET requests as any other. In fact, all the 
private data leaks I've heard about with crossdomain.xml has been 
related to GET requests.

/ Jonas

Received on Friday, 20 June 2008 02:33:16 UTC