Re: [whatwg] Adding crossorigin="" to more elements

On Wed, 28 Nov 2012, Boris Zbarsky wrote:
> On 11/28/12 7:42 PM, Ian Hickson wrote:
> > Done, at least on the HTML side. For now it just makes .sheet return 
> > null for cross-origin resources.
> 
> Pretty sure that's not web-compatible...

Yeah, I don't expect it is. This stuff is going to change as part of the 
bug below though so I'm not too worried for now.

> > If that's not quite right, please update this bug with the details:
> > 
> >     https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703
> 
> Done.

Thanks.


> > > An open issue: what to do about @import?  I haven't done anything 
> > > magic here yet.  Inheriting the CORS mode from the importing sheet 
> > > is a bit weird, and I wasn't quite sure I wanted to make CSS syntax 
> > > changes at this time.
> > 
> > Inheriting the mode isn't so bad, all it really does is decide whether 
> > or not to send an Origin header.
> 
> Not quite.  It also affects what happens when the server doesn't respond 
> with an appropriate Allow-Origin.  A CORS-enabled load from a server 
> that knows nothing about CORS will throw away the sheet, while a no-CORS 
> load will happily apply the sheet to the page (but not give access to 
> its data).  So inheriting the mode can cause drastic changes in behavior 
> compared to not inheriting it...

Well, yeah, but the sheet knows which mode it's in, so I don't think that 
part of it is a big deal.


> > > If the CORS mode is inherited from the importing sheet, then I think 
> > > the "origin" for the fetch should be the page, not the importing 
> > > sheet, since the page is what would get access to the stylesheet 
> > > data.
> > 
> > Right, the origin of the importing sheet in this situation is the 
> > origin of the page that imported it, not the origin of its URL. That's 
> > what CORS does, it changes the effective origin of a resource from 
> > being the origin its URL would suggest it had, to being the origin of 
> > its caller.
> 
> That's not quite correct.  It changes the _object_ origin to that of the 
> caller.  It doesn't change the _subject_ origin.

True (assuming we define those terms somewhere).

The real issue here is that CSS is different than other things we've 
applied CORS to before, in that it is, to some level, "alive". Before 
we've applied it to bitmaps (that can't do anything), scripts (that aren't 
in any way limited in the first place), and media (that can't do 
anything). This is the first time, I think, that we've used CORS with 
something that can do something with its privileges.

Anyway, this is somewhat moot to me because it'll all have to be defined 
by whatever spec it is that currently says that a CSS sheet on http: 
can't import an image on file:, etc.


On Wed, 28 Nov 2012, Boris Zbarsky wrote:
> 
> Oh, I see.  You've added this "taint" thing, which you're using for the 
> CSS bit.

That only applies when there's no crossorigin="" attribute, unless I made 
a mistake in the speccing.


> I don't believe Gecko has any such concept.

Well presumably you don't block all cross-origin loads of CSS when there's 
no crossorigin="" attribute. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 30 November 2012 00:37:19 UTC