Repository: whatwg/html

Issue #2813: Replace canvas' "origin-clean" concept with something less origin specific
Created: 2017-07-05T12:15:48Z
https://html.spec.whatwg.org/multipage/canvas.html#the-image-argument-is-not-origin-clean
The spec currently uses the origin of the image resource to determine if the resource taints the canvas or not.
It kinda hand-waves that the image has an origin, which isn't accurate enough, especially considering redirects and service workers.
This should be replaced by flags on images & videos to indicate they hold opaque content, which is judged by the current resource using CORS-cross-origin responses (the naming of this is misleading, but we can rename that some other time).
This means that <img crossorigin> resources can be drawn to the canvas without tainting despite being from another origin. This appears to be how browsers behave anyway.
I'm going to spec this flag for media elements as I need it for something else.

Duplicate issue #4490: drawImage() tainting may not be interoperable
Created: 2019-03-29T22:04:39Z
Porting from https://www.w3.org/Bugs/Public/show_bug.cgi?id=28374, where @bzbarsky says:

A page at origin X loads an image from origin Y using CORS.  The page has also set document.domain so that its effective script origin is Z.  It has a subframe from origin W, which has also sets document.domain to Z.  The parent page then does a drawImage call on a canvas in the subframe, with the image in question.
Per current spec what happens is that the image is CORS-same-origin so its origin is X.  When the drawImage call happens, whether the canvas is tainted or not depends on the origin of the entry settings object.
In other words, if a user clicks on a button in the subframe which has an event listener which makes a call to the parent which does the drawImage call, the canvas is tainted (because the entry settings origin is W, but the image origin is X).
But if the user clicks a button in the parent which has an event listener which does the drawImage call, the canvas is NOT tainted (because the entry settings origin is X, which matches the image origin).
This difference in behavior is a bit surprising.
I haven't been able to find a place to put a testcase to see what various UAs do here, but what Gecko does internally is that images actually have a "don't taint for this image" flag that's set if CORS is used during the fetch and the image is CORS-same-origin.  This means that in the above situation the canvas is not tainted no matter which button is clicked.
One other note: If the image is loaded from origin X without CORS, then per spec the behavior should be the same as if it were loaded from W with CORS.  At least in Gecko's implementation in this situation the canvas would get tainted no matter which of the two buttons is clicked, because we compare the image origin to the origin of the canvas node's ownerDocument, not to the entry settings origin.  Again, it would be interesting to see what other UAs do.

I'll also note the connection to #1431. Maybe if we stopped using entry settings this issue would be less bad, I dunno.
We need tests to figure out how tainting is done in these situations across browsers. And maybe we could change the spec to get rid of this use of entry settings object.

Closing comment (2019-04-05T11:38:31Z): This might be a duplicate of #2813 at this point?