On 11/30/12 3:13 AM, Boris Zbarsky wrote:
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.
What's in CSSOM now is "tainting".
It seems like the wrong model to use the effective script origin for
stylesheets, since you can't set "document.domain" for a stylesheet.
Consider this test case:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2324
Firefox throws here, but Chrome allows cssRules to be read. Same result
if the document.domain script is moved above the <link>.
Now, the spec could either use tainting or it could compare the origin
of the style sheet with the origin of the script that tries to access
it. This would only be different in a case like this:
http://foo.example.org/parent.html
<link rel=stylesheet href=http://bar.example.org/style.css>
<script> document.domain = 'example.org'; </script>
<iframe src=http://bar.example.org/child.html></iframe>
http://bar.example.org/child.html
<script>
document.domain = 'example.org';
alert(parent.document.styleSheets[0].cssRules)
</script>
Since this currently throws in Firefox, it's likely that there isn't a
big Web compat problem to not support this. I think <canvas> doesn't
support the equivalent thing, either, per spec (although a <canvas> is a
bit different in that it can have lots of images drawn on it from
different origins).
--
Simon Pieters
Opera Software
