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: Thu, 17 Dec 2009 16:59:33 -0800
Message-ID: <5691356f0912171659j1a7e2cf6g8475dd5586a707cb@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps <public-webapps@w3.org>
On Thu, Dec 17, 2009 at 4:41 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 17 Dec 2009, Tyler Close wrote:
>> On Thu, Dec 17, 2009 at 3:46 PM, Ian Hickson <ian@hixie.ch> wrote:
>> > On Thu, 17 Dec 2009, Tyler Close wrote:
>> >> On Thu, Dec 17, 2009 at 9:38 AM, Ian Hickson <ian@hixie.ch> wrote:
>> >> > One of the big reasons to restrict which origin can use a
>> >> > particular resource is bandwidth management. For example,
>> >> > resources.example.com might want to allow *.example.com to use its
>> >> > XBL files, but not allow anyone else to directly use the XBL files
>> >> > straight from resources.example.com.
>> >>
>> >> An XBL file could include some JavaScript code that blows up the page
>> >> if the manipulated DOM has an unexpected document.domain.
>> >
>> > This again requires script. I don't deny there are plenty of solutions
>> > you could use to do this with script. The point is that CORS allows
>> > one line in an .htaccess file to solve this for all XBL files, all XML
>> > files, all videos, everything on a site, all at once.
>>
>> I'm not trying to deny you your one line fix. I'm just saying it should
>> be a different one line than the one used for access control. Conflating
>> the two issues, the way CORS does, creates CSRF-like problems. Address
>> bandwidth management, along with other embedding issues, while
>> standardizing an <iframe> busting technique.
>
> What one liner are your proposing that would solve the problem for XBL,
> XML data, videos, etc, all at once?

Well, I wasn't intending to make a frame busting proposal, but it
seems something like to following could work...

Starting from the X-FRAME-OPTIONS proposal, say the response header
also applies to all embedding that the page renderer does. So it also
covers <img>, <video>, etc. In addition to the current values, the
header can also list hostname patterns that may embed the content. So,
in your case:

X-FRAME-OPTIONS: *.example.com
Access-Control-Allow-Origin: *

Which means anyone can access this content, but sites outside
*.example.com should host their own copy, rather than framing or
otherwise directly embedding my copy.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Friday, 18 December 2009 01:01:07 GMT

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