[cap-talk] Open Review of the CORS Specification

[Doug Schepers]

Hi, David-Sarah-

(Original post reordered for response.)

David-Sarah Hopwood wrote (on 10/13/09 12:41 AM):
>
>>  On Mon, Oct 12, 2009 at 6:12 PM, Doug Schepers<schepers at w3.org>  wrote:
>
> The response always seems to be something equally as vague as:
>
>>>  There were concerns that the CORS spec might not satisfy all the related
>>>  security issues; this is true, but we do believe that it solves a useful
>>>  set of cases, and doesn't introduce additional risk.
>
> which, without actually enumerating the kind of cases that are supposed to
> be "solved", does not seem to me to be a substantive technical argument
> in favour of CORS at all.

Nor is it meant to be a technical argument.  I hope I made it clear that 
I'm here to solicit technical review on the WebApps WG list, not to 
argue the technical details myself.


>In the few cases where anything more specific
> has been said about use cases, they appear to be just about creating
> another hoop for attackers to jump through, rather than actually
> preventing them from doing anything.
>
> It is *not* harmless to add complexity to an already complicated and
> poorly understood access control policy and mechanism ("Same Origin") in
> a way that does not actually address the deficiencies of that policy and
> mechanism.

That's true, if it doesn't solve a real use case, then the added 
complexity is not worth it.  The bone of contention is whether it solves 
a real use case.  I don't have a prejudice either way here... at some 
point, both the proponents and opponents seem to step into hand-wavey 
mode and real discussion falls down.  Frankly, there are simply too many 
jargon terms, metaphors, references and allusions, and problem-set 
shorthands being tossed around to ensure that everyone is on the same page.

Maybe I think more visually, which is why I'd like a diagram (or 
several) of the problem space.  Nobody has followed up on my offer to 
help with that, so either it's a bad idea, or people don't have time to 
help, or it's a good idea that doesn't meet someone's agenda, or 
something.  I think it would be a good thing to add to the spec, or at 
least to a primer, to help newbies (like me) understand the real risks. 
  Is there some reason that a set of diagrams would not be a good idea?


> If I thought that my participation would do much good, then it would be
> worth subscribing to public-webapps and putting up with the bandwidth
> overload. However, as far as I can see from reading the archives, the
> valid objections to CORS (summarized in Tyler's 2009-06-10 post at
> <http://waterken.sourceforge.net/recent.html>) have already been put
> repeatedly and have never been substantively addressed by its supporters.

I suspect that people are talking around each other, and not really 
understanding the problems (or solutions) that the others are putting 
forth.  What you see as an intractable and obvious problem may not 
appear that way to the proponents of CORS.  And it's possible that the 
problem may not be strictly applicable to the use cases CORS is meant to 
solve, though Tyler seems to think it is.

With no offense intended, I don't really care for the argument that 
because past attempts at reaching a solution have failed, we should 
simply stop trying to find a common ground.  If security experts don't 
successfully articulate why this is a problem, browser vendors will 
deploy it; if the CORS folks don't address the concerns of security 
experts, and get their buy-in, we will have an insecure and socially 
unstable technology deployed.  Neither situation is good.

So, I encourage feedback on the public-webapps list, rather than this 
one... I'm just the messenger here.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs