- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 18 Dec 2009 00:41:03 +0000 (UTC)
- To: Tyler Close <tyler.close@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>
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? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 18 December 2009 00:41:54 UTC