audio/video loads should set the "same-origin data-URL" flag

[bzbarsky]

For the same reason that images set it: so you can then work with the resulting thing.

[domenic]

This (and #1778 and #1243) is largely the same discussion as whatwg/fetch#381, I think. We really should figure out the story there sooner rather than later.

[bzbarsky]

From my point of view the basic story is that some of the Chrome developers hate data: URLs and want to kill them off on the web. With that goal in mind, they are trying to make them as useless as they possibly can within web compat constraints, and possibly a bit over that line. Some of that that hatred is motivated by what they perceive as security issues (and I will grant those); some is just motivated by Chrome's implementation details.

An alternate approach to data: URLs, and one that I think is more developer-friendly, is to make them as useful as we possibly can, while keeping in mind potential security/XSS issues. I don't see any XSS issues with audio/video, just like I don't see any with images.

[foolip]

Does this amount to whether loading a data: URL in a media element then allows you to access any in-band text tracks and painting video frames to a canvas? I take it that right now some implementations (Chrome?) treat it as cross-origin and some (Gecko?) as same-origin?

[annevk]

Yeah, basically that. This might not require changes here if we go with the solution put forward here: whatwg/fetch#381 (comment).