On 11/29/12 5:09 PM, Ian Hickson wrote:
Well, yeah, but the sheet knows which mode it's in, so I don't think that
part of it is a big deal.
Maybe. Problems can arise with a sheet that itself sends CORS headers
but links to sheets that don't and that's tested in a UA that doesn't do
<link crossorigin>. But OK. I'll see about inheriting the CORS mode.
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".
Yep. See https://bugzilla.mozilla.org/show_bug.cgi?id=732209#c1 for a
(probably non-exhaustive) list of possible meanings for CORS here. I
implemented option 5 in Gecko.
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.
Heh. Does it affect things like CSP in any way?
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.
Oh, ok. Sorry. Reading diffs of HTML is a pain. :(
Well presumably you don't block all cross-origin loads of CSS when there's
no crossorigin="" attribute. :-)
Sure. We don't do any sort of "tainting" either, though; we simply
remember the origin of the CSS (where it was actually loaded from,
post-redirect, not the original URI) and do a same-origin check when you
try to use the CSSOM on it. Note that this check is done against the
effective script origin of the script doing the CSSOM access, which may
not actually match the origin of the page the CSS is loaded for, etc.
Not sure whether the tainting setup you describe is equivalent to that,
though I doubt it is.
-Boris
