Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, 21 Dec 2009, Tyler Close wrote:
> On Mon, Dec 21, 2009 at 2:39 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 21 Dec 2009, Tyler Close wrote:
> >>
> >> No, there is a difference in access-control between the two designs.
> >>
> >> In the two header design:
> >> 1) An XHR GET of the XBL file data by example.org *is* allowed.
> >> 2) An <xbl> import of the XBL data by example.org triggers a rendering error.
> >
> > That's a bad design. It would make people think they had secured the file
> > when they had not.
> 
> The headers explicitly say that a read request from any Origin is allowed:
> 
> Access-Control-Allow-Origin: *
> 
> The above syntax is the one CORS came up with. How could it be made clearer?

By not having two headers, but just having one.


> > Security should be consistent across everything.
> 
> It is. All Origins have read access. The data just renders in a
> different way depending on if/how it is embedded.

I am not interested in this kind of distinction. I think we should only 
have one distinction -- either an origin can use the data, or it can't.


> >> In the one header design:
> >> 1) An XHR GET of the XBL file data by example.org is *not* allowed.
> >> 2) An <xbl> import of the XBL data by example.org triggers a rendering error.
> >
> > That's what I want.
> 
> What you want, and the mechanism you propose to get it, are at odds.
> I've described the CSRF-like attack multiple times.

Sure, you can misuse Origin in complicated scenarios to introduce CSRF 
attacks. But XBL2 doesn't have those scenarios, and nor do <video>, 
<img>+<canvas>, and any number of other options. Most XHR2 uses don't 
involve the multiple sites either. We shouldn't make _everything_ far more 
complicated just because there is a way to misuse the feature in a case 
that is itself already complicated.


> The access control model you propose doesn't actually work.

It works fine for XBL2, Web Sockets, <video>, <img>+<canvas>, sharing 
data across multiple servers in one environment, etc.


> To actually control access to the XBL file data you need to use 
> something like the secret token designs we've discussed.

I'm sorry but it's simply a non-starter to have to use secret tokens for 
embedding XBL resources. That's orders of magnitude more complexity than 
most authors will be able to deal with.

There are no scripts involved in these scenarios. It would simply lead to 
the "secret" tokens being baked into public resources, which would make it 
trivial for them to be forged, which defeats the entire purpose.


> >> Under the two header design, everyone has read access to the raw bits 
> >> of the XBL file.
> >
> > That's a bad thing.
> 
> In the scenario you described, everyone *does* have read access to the 
> raw bits.

Only people behind the intranet, or with the right cookies, or with the 
right HTTP authentication, or with the right IP addresses. That's not 
everyone.


> In your scenario, we were just trying to discourage bandwidth stealing.

I am trying to do many things. Bandwidth stealing is one. Securing 
semi-public resources is another. Securing resources behind intranets is 
yet another. These are all use cases that CORS makes trivial and which UM 
makes incredibly complicated.


Personally the more I discuss this the more convinced I am becoming that 
CORS is the way to go.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 22 December 2009 00:17:52 UTC