W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Tyler Close <tyler.close@gmail.com>
Date: Mon, 21 Dec 2009 14:54:10 -0800
Message-ID: <5691356f0912211454q294ce944ldf63896e2b1f8d22@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps <public-webapps@w3.org>
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?

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

>> 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. The access control
model you propose doesn't actually work.

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

>> 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. Anyone can just direct their browser to example.org and
save the data. In your scenario, we were just trying to discourage
bandwidth stealing.

>> The one header design makes an empty promise to protect read access to
>> the XBL file.
>
> How is it an empty promise?

See above.

We don't seem to be making any progress at understanding each other,
so I'm going to give up on this thread until I see some signs of
progress. Thanks for your time.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Monday, 21 December 2009 22:54:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT