Re: [cors] Review

On Mon, 15 Jun 2009 04:36:28 +0200, Mark Nottingham <mnot@mnot.net> wrote:
>>>> Content providers wanted the flexbility of not having to list every
>>>> header in advance. Both so debugging headers and such would not have  
>>>> to be exposed and to reduce the payload.
>>>
>>> Which content providers? How much extra payload do you really expect
>>> this to be?
>>
>> I believe Google, Microsoft, Mozilla, and SitePen.
>>
>> I don't know how much payload would be saved, but that was not the only  
>> reason.
>
> The others being?

Not exposing debugging headers. 


>> Some prior discussion on response headers:
>>
>>  http://lists.w3.org/Archives/Public/public-webapi/2008Apr/thread.html#msg58
>
> So, the crux of the motivation seems to be Ian's:
>> I don't think we should change this without a better reason. There's no  
>> reason to believe that some servers don't have information in the  
>> headers that shouldn't be seen by third-parties, and it's the kind of  
>> thing that would be really easy to miss when securing a page for  
>> third-party access.
>
> It seems odd to me that you're willing to expose all of the data in the  
> response, but almost none of the metadata (headers). Taking a quick look  
> through the message header registry, a number of candidates that would  
> be useful -- if you allowed them -- come up, including: [...]
>
> Note that many of these are critical to understanding the message, and  
> disallowing many others will disallow many applications.
>
> For example, [...]
>
> This is not a complete list; adding these headers to your whitelist will  
> not resolve this issue.

If this proofs to be a big problem in practice we can let the list be extended using a response header that lists all headers the server is willing to share. This could be a CORS2 feature.


>> Here's a thread on request headers:
>>
>>  http://lists.w3.org/Archives/Public/public-appformats/2008Feb/thread.html#msg168
>
> Similar concerns seem to apply here. You mention theoretical attacks/ 
> risks a lot, and people who disagree are asked to prove a negative -- an  
> unrealistically high bar.

It does not follow that we then have to simply allow it.

Also note that _with_ a preflight request which will be necessary for many requests anyway you _can_ include almost any header you want apart from the ones that are on the XMLHttpRequest blacklist.


>>>> See crossdomain.xml. It is a security nightmare. Especially when a
>>>> single origin is being used for several APIs.
>>>
>>> Waving your hands and saying "security" is not a substantial response.
>>
>> Ok,
>>
>>  http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0050.html
>>  http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0052.html
>
> It's interesting that you point that out. Reading the entire thread, it  
> seemed like there was consensus on a requirement there, but it wasn't  
> added to the document. Why not?

Maybe it was added and later removed. Maybe it was never added. I'm honestly not sure.


>>  http://lists.w3.org/Archives/Public/public-appformats/2008Jan/thread.html#msg248
>
> Ah, yes the infamous "I disagree with much of the Web arch" thread.  
> Enough said, I think.

It should be noted that Ian did change his mind and that he and others from Google argued for improving this situation through Access-Control-Policy-Path.


>>  http://www.w3.org/2005/06/tracker/waf/issues/22
>>  http://lists.w3.org/Archives/Public/public-appformats/2008Jan/thread.html#msg303
>
> Where is the sentence that the resolution of that issue refers to?

Access-Control-Policy-Path was not found to be workable solution in the end

  http://www.w3.org/2008/webapps/track/issues/12

unfortunately.


>> By and large it seems like an editorial request and as editor I do not  
>> see how to address it.
>
> Understood. It's up to the Director to decide if the document meets the  
> minimum requirements for Recommendation.

Actually, as I understand things it is a W3C decision.


>>> Probably "resource processing model..."
>>
>> I started making changes in that direction and it did not make a whole  
>> lot of sense. E.g. how would you rephrase "In response to a simple  
>> cross-origin request or actual request the server indicates whether or  
>> not to share the resource."?
>
> "In response to either an actual request or a simple cross-origin  
> request, the resource indicates whether or not to share the response."
>
> although in this particular case, "... the server indicates whether or  
> not to share the response" would work as well (since it's unambiguous).
>
> The distinction is more important when talking about scoping -- e.g.,  
> does a decision apply to a single response, all responses from a  
> resource (as identified by a URI), or all responses from a server.

I made the changes here now. I'd appreciate if you could go over it to see it is ok.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Monday, 15 June 2009 14:17:14 UTC