Re: [cors] Review

Thanks - a few replies below.

On 14/06/2009, at 10:24 PM, Anne van Kesteren wrote:

> On Sun, 14 Jun 2009 03:58:31 +0200, Mark Nottingham <mnot@mnot.net>  
> wrote:
>> As I said, I raised have raised substantive issues before:
>>   http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html
>> and don't believe they were formally addressed (note that I'm using
>> Process terminology here). That experience didn't lead me to believe
>> that it was worth spending the time to track the specification  
>> closely.
>
> What do you mean? We replied in a timely manner and attempted to  
> address all of your issues until you were either satisfied with the  
> response or stopped replying.

Your perception of what happened then is different than mine. At any  
rate, there's not much point in arguing about it now. I think it's  
unfortunate that CORS is designed how it is, but here we are...


>>> 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?


> Implementors did not want a blacklist. The attack vector is the server
>>> inadvertently exposing headers it did not want to.
>>
>> Has this been discussed in depth before? If so, do you have a ref? I
>> think it deserves some serious discussion if not.
>
> It has not been exhaustively discussed, I think, although it  
> certainly has been discussed. There have been plans for allowing the  
> list to be extended if the server explicitly opts in to more 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:

Age, Allow, Alternates, Content-Disposition, Content-Encoding, Content- 
ID, Content-Length, Content-Location, Content-MD5, Content-Range,  
Content-Script-Type, Content-Style-Type, Date, Link, Location, P3P,  
PICS-Label, Retry-After, Server, Vary, Warning

Note that many of these are critical to understanding the message, and  
disallowing many others will disallow many applications.

For example, Content-Length will tell the application whether or not  
the response is complete; Content-MD5 is another integrity check; as  
noted by others, both Content-Location and Location carry useful  
information; Age and Date allow an application to determine how long  
something has been cached; P3P and PICS-Label carry metadata that some  
applications may have need for; Vary tells applications what  
dimensions the response varies across; Warning carries information  
about how the response has been cached, and Link looks to have a  
number of use cases queued up.

This is not a complete list; adding these headers to your whitelist  
will not resolve this issue.


> 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.


> * Chattiness - The protocol set out here requires a pre-flight request
>>>> every time a new URL is used; this will force Web sites to tunnel
>>>> requests for different resources over the same URL for performance/
>>>> efficiency reasons, and as such is not in tune with the Web
>>>> architecture. A much more scalable approach would be to define a  
>>>> "map"
>>>> of the Web site/origin to define what cross-site requests are  
>>>> allowed
>>>> where (in the style of robots.txt et al; see also the work being  
>>>> done
>>>> on
>>>> host-meta, XRDS and similar). I made this comment on an older  
>>>> draft a
>>>> long time ago, and have still not received a satisfactory response.
>>>
>>> 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?

>  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.

>  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?


>>> Added servers. It's not clear to me how to rewrite the  
>>> specification in
>>> a way that does not leave gaps. If you can find another editor who  
>>> can
>>> do that for us that'd be ok I suppose.
>>
>> I don't think saying (roughly) "that's the best we can do with  
>> limited
>> resources" is a substantial response either, but I have a feeling  
>> it'll
>> be accepted nevertheless :-/
>
> 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.


>>>> * Conformance Criteria - "A conformant server is one that..." -->  
>>>> "A
>>>> conformant resource is one that..."
>>>
>>> I haven't done this yet. Does it still make sense to talk about a
>>> server processing model if we do this?
>>
>> 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.


> * Generic Cross-Origin Request Algorithms - for clarity, can this be
>>>> split up into separate subsections?
>>>
>>> I added spacing instead. Does this work?
>>
>> My personal preference would be subsections, to make sure they're
>> distinct.
>
> I left it as is for now. If more people want this I'll make the  
> change.


Ack.

--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 15 June 2009 02:37:06 UTC