[whatwg] Adding crossorigin="" to more elements

[Simon Pieters]

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