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

Hans Schmucker hansschmucker at gmail.com
Sun Mar 15 12:45:17 PDT 2009


On Sat, Mar 14, 2009 at 3:11 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 13 Mar 2009 23:53:36 -0000, Hans Schmucker <hansschmucker at gmail.com>
> wrote:
>>
>> Question is: what would be the best way to fix it? Of course the spec
>> could be changed for video and image, but wouldn't it be simpler to
>> update the defintion of origins to include patterns that can represent
>> allow rules?
>
> Aside: You might want to take a look at a later version of the specification
> (the one that is being implemented):
>
>  http://dev.w3.org/2006/waf/access-control/

Thank you Anne, but I think this has to be dealt with primarily inside
the HTML5 spec. The Access Control spec is already pretty clear on how
things are supposed to work on the server and from the server to the
client and it's probably mostly enough to say that "Image and Video
elements in addition to cross-origin linking also allow for
cross-origin use as described in Cross-Origin Resource Sharing". Me
and Chris actually assumed it would work that way until we tried it.
The main question for me (aside from the question if
image/video/canvas elements should retain all necessary information to
check for valid origins that are allowed access again or just be
marked "standard"/"public") is where to put it in the spec. 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".



More information about the whatwg mailing list