W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 28 Nov 2012 23:03:04 -0500
Message-ID: <50B6DE78.5040500@mit.edu>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@whatwg.org>, Pablo Flouret <pablof@motorola.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Robert Kieffer <broofa@fb.com>
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...

> 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.

>> 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...

>> 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.  Otherwise loading 
something via CORS would allow it to act on behalf of the loading page, 
whereas usually pages assume that using CORS just gives them expanded 
access to something.

Or put another way, if I have a file:// page that loads a sheet from 
http:// with CORS, that shouldn't imply that the sheet can then link to 
file:// URIs the page can link to.

This is very important; oversimplifying the security model to the point 
where it becomes insecure is bad.  ;)

>> Maybe this is OK, but it's non-obvious; usually for security purposes
>> the importing sheet is what affects things like can-load checks, Referer
>> headers, etc.
>
> Presumably a CORS-same-origin sheet would use the security characteristics
> of the page, since the page can make the style sheet dance as if it was
> its puppet.

No, see above.  The page can make the sheet do whatever, agreed.  But 
this is about the _sheet_ taking on the permissions of the _page_ in 
some sense, which may not be desirable.

> Anyway, that part of it belongs in CSS/CSSOM.

That's fine by me.  Assuming we ever end up with a CSSOM spec.... not 
holding my breath.  ;)

-Boris
Received on Thursday, 29 November 2012 04:10:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT