[whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

>> Thank you Anne, but I think this has to be dealt with primarily inside
>> the HTML5 spec.
>
> Yes, hence me using the word "aside"...

Sorry, I didn't mean to make it sound like an attack, I really just
meant to say that this (for me) belongs more into HTML5, which deals
primarily with the user agent, than into the CORS spec, which more or
less focuses on the server side and the communication between server
and client.

> No, currently you actually have to state which algorithm you use in CORS and
> how. Otherwise CORS does not apply (at least not from a specification
> standpoint).
Yes, we pretty much assumed that HTML5 had already adapted to CORS. It
was an assumption, but it's an assumption many people are bound to
make as other HTML5 features depend on CORS.


>> It's an
>> issue that applies to pretty much anything that allows access to the
>> raw data (which is just canvas now, but nobody knows what the future
>> will bring) and to make matters worse its nature not only requires
>> changes to canvas itself, but also to the elements that are drawable,
>> like img or video. So to me it would make the most sense to put this
>> as far away as possible from Canvas and make it more into a generic
>> item how DOM elements are supposed to hold data about cross origin
>> headers. Then the canvas description would need virtually no changed
>> beyond "obeys cross-origin rules for pixel access".
>
> That does sound nice yes.

So, where would you put it? The problem for me is that there's no
logical grouping of elements that load offsite resources (like img,
script, link, video, ...) where one could add the necessary
attributes. All off them descend directly from HTMLElement. So there
would be two routes: Either making all elements that load offsite data
descend from a common HTMLRemotelyFedElement interface (which seems
like the right way to do things, but it's also IMHO completely
unrealistic as it would either require reworking the DOM top to bottom
or including ugly hacks) or adding the necessary attributes to
HTMLElement itself... which seems like asking for trouble.

Then there's the (IMHO) despicable way of just writing a random
chapter about it and referencing that chapter in the spec wherever
appropriate. Feels very, very wrong, but I don't think we have much
choice here.

Received on Sunday, 15 March 2009 14:09:16 UTC