[whatwg] Adding crossorigin="" to more elements
Boris Zbarsky
bzbarsky at MIT.EDU
Wed Nov 28 20:03:04 PST 2012
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
More information about the whatwg
mailing list