drawImage() tainting may not be interoperable

[domenic]

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.

[annevk]

This might be a duplicate of #2813 at this point?

[domenic]

Yes, good catch, I knew I saw something similar to this but hadn't found it. Let's merge there.