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

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