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 14:13:09 -0800
Message-ID: <5691356f0912171413m5aa4e998kdfb1847c45e25141@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Kenton Varda <kenton@google.com>, Maciej Stachowiak <mjs@apple.com>, Adam Barth <w3c@adambarth.com>, Jonathan Rees <jar@creativecommons.org>, "Mark S. Miller" <erights@google.com>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
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.

I think this solution more precisely implements the control you want.
You're not trying to prevent other sites from downloading your XBL
file. You're only trying to encourage them to host their own version
of your XBL file.

In general, the control you want is most similar to <iframe> busting.
A separate standard that covers these rendering instructions would be
better than conflating them with an access-control standard. For
example, a new HTTP response header could provide instructions on what
embedding configurations are supported. The instructions may be
independent of how the embedding is created, such as by: <iframe>,
<img>, <script> or <xbl>.


"Waterken News: Capability security on the Web"
Received on Thursday, 17 December 2009 22:14:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC