This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There appears to be a gap in the security model specification between the 'canvas' and 'script' elements. The canvas security model http://www.w3.org/TR/html5/the-canvas-element.html#security-with-canvas-elements offers no way to relax the security check from "same origin" to "effective script origin", as defined here http://www.w3.org/TR/html5/origin-0.html#relaxing-the-same-origin-restriction More accurately, there appears to be no way for the canvas context to use an effective script origin other than the actual origin of the resource. This prevents any use of the canvas interface by scripts sourced from a Document with a relaxed domain. The HTML5 specification has been carefully implemented in the Mozilla project, and it is clear to see the effect: scripts that use the canvas API to filter images from host.domain.com fail on Firefox 3.x, where they operate successfully using Chrome, IE, etc. Goal of this request is to introduce an effective-script-origin analogue for the canvas element, perhaps by introducing a method to set the effective script of the canvas object similar to document.domain for the Document.
The origin of the canvas in Mozilla is just the origin of the document it's in; this is affected by setting document.domain. Your real issue is that you can't change the origin of the _images_ involved, no?
(In reply to comment #1) > The origin of the canvas in Mozilla is just the origin of the document it's in; > this is affected by setting document.domain. > > Your real issue is that you can't change the origin of the _images_ involved, > no? Yes; that's more accurately phrased.
(To be explicit, the HTMLImageElement or HTMLVideoElement or whatever other resource is planted in the canvas.)
It seems to me like CORS is the right way to go here, for what it's worth. Because at the end, the server serving up the images needs to be the entity which controls whether their origin can be changed.... at which point using CORS seems like a simpler solution.
I'm not sure that I agree with that. In the general case of cross-domain sharing, absolutely - that's the problem statement CORS is intended to address. Given the constrained flexibility offered through the same-origin restriction relaxation, though, offering the ability to share resources across different subdomains within the same domain feels like the right "80%" solution. Put differently: why would it make sense to offer relaxed restrictions for scripts while denying it for the improved interface to static resources that HTML5's canvas offers?
The thing with scripts is that the relaxation can be done completely on the client side: two scripts _both_ indicate that they want to relax the restrictions, and they can talk to each other. Here, we'd need the canvas and the image/video being drawn into it to _both_ indicate that they want to relax the restriction. For the canvas, this can be done client-side in script by setting document.domain. But for the others, there is no client-side anything happening; the relaxation needs to be either in image metadata chunks or in the HTTP response from the server, right? If you're not proposing the image itself be changed, then you're proposing some configuration change to the HTTP response. And if we're already doing that, then that change might as well be to send the proper CORS headers instead of inventing a new wheel that's attached the same way. Or am I missing something?
I see what you're saying - static resources don't have anyway to handshake their participation in the sharing. I understand the reasoning, but it still seems a little strange. Since at least the Mozilla UA distinguishes between specified and inferred domains, this effectively means that document.domain and canvas are mutually incompatible until full CORS support is implemented. It feels like there might be room for a pragmatic solution that allowed client-side script-based "promotion" of static resources to ancestral domains of the resource's own origin... but, yeah, I can see that that's a can of worms maybe best left unopened. Maybe it makes sense to at least update the HTML5 spec to make the implicit dependency on CORS explicit? It looks like there was some early discussion of the same already... http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018863.html
That would be fine yes. I don't think we want a way for site A to say that content from some other site B should be treated as same-origin with site A without site B having opted into it. That way lie bad things....
Normally I'd slightly disagree with you there, so long as A and B are part of the same parent domain. Definitely haven't thought through the repercussions in an EC2 age, though, so I'll defer to those that have :) The biggest concern that I have with the CORS approach is that it seems like it depends on the UAs to properly set up the Origin header on the request, which I don't believe is generally the case today. (We're really not looking to "*" out the credentialing, though I guess that could be a workaround). Am I reading the CORS spec right in that cookies can be passed with the request, just that UAs are expected to disregard any modifications that come by way of Set-Cookie in the response?
> so long as A and B are part of the same parent domain. Unfortunately, no. It's common to use separate subdomains for security isolation; changing that would lead to security holes in all sorts of existing sites. > depends on the UAs to properly set up the Origin header on the request, I believe Webkit and Gecko have both been working on doing this for all requests. I don't know the answer to your cookies question off the top of my head.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: none yet Rationale: If the request here is just to allow a site A to opt-in to allowing another site B to read image data from images on site A, then the intent is to do this using CORS in due course, but for now we're waiting for more implementation experience with CORS.
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: <img crossorigin> Rationale: Concurred with reporter's comments.