Replace canvas' "origin-clean" concept with something less origin specific

[jakearchibald]

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.

[jakearchibald]

Fixing this would also help with #1431.

[annevk]

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=28374 for some related feedback on this.

[jakearchibald]

Cheers! I figured someone must have already picked up on this.

https://html.spec.whatwg.org/multipage/media.html#loading-the-media-resource contradicts the canvas spec on this:

It can be CORS-same-origin or CORS-cross-origin; this affects whether subtitles referenced in the media data are exposed in the API and, for video elements, whether a canvas gets tainted when the video is drawn on it.

[junov]

+1
The concept represented by the origin-clean flag is not origin cleanliness. What the flag really means is: "is script allowed to access the content". The reasons for blocking access (e.g. cross-origin) are not really important to the semantics of the flag. Not sure how to express that precisely in a concise flag name.
Perhaps: content-access-allowed

[jakearchibald]

FWIW I'm going for "uses opaque data flag" for media elements. I'm using it to ensure opaque responses aren't mixed with content from other sources, so it isn't strictly about content-access.

[junov]

The term opaque is ambiguous when talking about pixel data (could mean "no alpha channel").

[jakearchibald]

Oh bollocks yeah. Hmm. That's what the fetch spec calls it though. Maybe "uses opaque response flag" to make the link to fetch clear.

[junov]

Naming things is hard... :-(