Re: Opting in to cookies - proposal version 3

Ian Hickson wrote:
> On Thu, 19 Jun 2008, Jonas Sicking wrote:
>>> 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.
> 
> But the _entire assumption_ here is that the author is unable to correctly 
> apply these features to the right subset of his site. If the author was 
> able to correctly apply these features to the appropriate subset, then we 
> wouldn't need your feature in the first place.

No, that is not the assumption. I'll try to rephrase. In the example
below i'll use PHP as the server side technology for:

My concern is for a site operator which understands the spec and wants 
to share public data being offered from all or part of the URI space for 
the site.

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.

>> 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.
> 
> But we both know browsers aren't going to do this, or will offer a "never 
> ask me again" checkbox. 

I'm talking about the site asking the user this question. The site
should always check with the user before sharing any of the users
private data with any third party.

If we separate out opting in to cookies from opting in to Access-Control 
then sites can easier ensure that any time they opt in to cookies, they 
only do so after having asked the user.

>>> (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"?
> 
> The script that provides the data, and the right magic is the 
> Access-Control header.

I'm sorry, i'm totally at a loss about what you are saying here, I 
suspect I'm missing some context. Could explain from the beginning?

/ Jonas

Received on Friday, 20 June 2008 18:46:17 UTC