- From: Tyler Close <tyler.close@gmail.com>
- Date: Thu, 17 Dec 2009 14:13:09 -0800
- 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>. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Thursday, 17 December 2009 22:14:42 UTC