Re: Opting in to cookies - proposal

Bjoern Hoehrmann wrote:
> * Jonas Sicking wrote:
>> I'm not quite following what you are asking here. My proposal is about 
>> giving a site the ability to enable two "modes" of Access-Control:
>>
>> 1. Allow a third-party site to read the data on this resource, and/or
>>    perform unsafe methods in HTTP requests to this resource. When
>>    these requests are sent any cookie and/or auth headers (for the
>>    resource) are included in the request, just as if had been a
>>    same-site XHR request.
>> 2. Same as above, but requests never include cookies or auth headers
>>    are never included.
>>
>> In the spec currently only mode 1 is possible. I suggest that we make 
>> mode 2 possible as well. I guess you can call it "opting out of cookies" 
>> as well...
> 
> I am proposing that there be only a single mode unless it can clearly
> be demonstrated that having two modes would be a substantial net gain.
> As far as I am aware, this has not been established for a with-cookie
> mode if the no-cookie mode is the default, and my questions focus on
> learning more about the with-cookie mode.

Not sure if there is much of a 'default' mode no matter what, since it's 
the website that chooses if it wants to receive cookies or not.

But anyway...

Allowing with cookies has obvious benefits. It allows the target size to 
know which user data is requested for. So if the requesting site is 
trusted by the target site, the target site can send user-private data 
(note, this trust has to be established out-of-band from the spec, 
usually by the target site asking the user) and know which users data to 
send. Additionally, this is done without needing to entrust the 
requesting site with any user credentials. It also neatly integrates 
with security solutions inside ASP, PHP, etc without having to deploy a 
new infrastructure to handle these things.

Allowing without cookies gives websites that want to publish public data 
a tool to significantly safer opt in to Access-Control without having to 
worry about accidentally leaking users private data. Accidentally 
leaking private data can happen in two instances that I can think of:
   * The operator opts in to AC on a subsection of the site forgetting
     that somewhere deeply nested is a form with CRSF protection
     which isn't supposed to be readable cross-site. Or there is a
     resource that serves user-private data which isn't supposed
     to be readable cross-site.
   * The operator opts in to AC on a URI that mostly serves public
     data, but forgets that if the user is logged in the URI also
     serves some user-private data.


I do admit that I do not yet know how likely it is that operators will 
make any of the mistakes listed above, so I can't give an exact 
cost/benefit analysis.

/ Jonas

Received on Monday, 23 June 2008 23:52:15 UTC