Re: Opting in to cookies - proposal version 3

Ian Hickson wrote:
> On Fri, 20 Jun 2008, Jonas Sicking wrote:
>> Under the current spec the operator must check each individual PHP
>> script in the part of the site that is shared to make sure that none of
>> them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'],
>> HttpRequest::getCookies(), any of the session_* functions,
>> $_ENV['REMOTE_USER'], $_ENV['REMOTE_IDENT'], $_ENV['HTTP_AUTHORIZATION'] any
>> of the kadm5_* functions, any of the radius_* functions or anything else that
>> I'm missing that does session management based on user credentials.
>>
>> If any of these things are used then the PHP script is likely mixing private
>> data into the public data and so the script needs to be modified to not use
>> any of the above features when the 'Origin' header is present and has a value
>> different from the current domain.
>>
>> While this is certainly doable, I feel that there is a risk that the site
>> administrator will make a mistake and miss some of the above listed features
>> and cause private data to be leaked.
>>
>> So again, the issue isn't in understanding the spec. The issue is securing
>> your site for the security model that the spec requires.
> 
> That's all well and good, but what if the site author wants to send back 
> some data that _is_ cookie aware? Now he has to go through and do the 
> check anyway. So what's the win?
> 
> I think it's safe to assume that if the site uses cookies at all, that 
> it'll eventually want to provide cross-site access to user data in some 
> way.

When do you want to use cookie data, but not serve private data? That 
seems really rare to me.

> So it now seems like you are saying that this feature is only intended to 
> delay the time before which someone has to audit their site. That doesn't 
> seem like a great win to me.

No, when you are serving public data not based on cookies you will never 
have to audit the code with my proposal. I think this will be common 
enough of a usecase to cater to.

Note that opting in to cookies on a per URI basis. So you only have to 
audit the parts of the sites where you do opt in to cookies, if there 
are any such URIs at all.

As I said in my initial mail about why I think we need a cookie opt-in 
mechanism, I want this for the sites (or subsections of sites) that 
serve purely public data.

I agree it is of no help at all for sites (or subsections thereof) that 
serve private data.

Or to put it another way:
Sites that serve private data will hopefully take precaution before 
sharing their users private data. Just like they take precaution not to 
leak this data through any other means.

Sites that only want to publish public data are unlikely to take the 
same precautions since they intend to only publish public data.

>>>> 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.
>> I'm talking about the site asking the user this question.
> 
> The site doesn't know if it's asked the user this question if it doesn't 
> have the cookies to know who the user is.

So we are talking about transfers of private data here, right? In that 
case the requesting site simply sets the 'with credentials' flag and 
then everything works just as described by what the spec says today.

/ Jonas

Received on Friday, 20 June 2008 23:28:04 UTC