Include details of SVG-as-Image and Canvas origin-clean

[schenney-chromium]

The canvas cross-origin tainting behavior of SVG-as-image content varies across browsers, and is not specified in any way. The incompatibility arises from the treatment of SVG foreignObject elements in SVG content used as a source for HTML or SVG objects.

• All browsers consider SVG-as-image to be not origin-clean when the image source is a regular url pointed to SVG with a foreignObject tag, such as src="svg-with-foreign-object.svg".
• All browsers consider SVG-as-image to be origin-clean when given by a data URI, such as src="data:image/svg+xml;base64,...".
• Currently, Chromium and WebKit consider an SVG src given as a blob in Javascript, such as blob = await fetch("svg-with-foreign-object.svg").then(img.src = URL.createObjectURL(resp.blob())); to be not origin-clean if it contains a foreignObject tag or has not origin-clean images. Gecko only checks the images. Chromium has in intent to match the Gecko behavior.

The canvas spec currently does not specifically address SVG content as an image source, it just says a HTMLOrSVGImageElement is not origin-clean when the "image's current request's image data is CORS-cross-origin"

Going over to the images portion of the spec we have the statement about CORS cross-origin being important to canvas, and we also have "The src attribute must be present, and must contain a valid non-empty URL ... referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted." and note that explicitly calls out SVG and restricts HTML.

Finally we have the SVG spec saying

image references:
    An SVG embedded within an image element must be  processed in *secure animated mode* if the
    embedding document supports declarative animation or in *secure static mode* otherwise.

    The same processing modes are expected to be used for other cases where SVG is used in place of a raster image,
    such as an HTML ‘img’ element or in any CSS property that takes an <image> data type. This is consistent with
    HTML's requirement that image sources must reference "a non-interactive, optionally animated, image resource
    that is neither paged nor scripted"

Browser behavior is in conformance with all this spec text thanks to limitations on scripting and external links in SVG foreignObject sub-trees and when SVG is used as an image source.

I would like to put up a PR to explicitly discuss the SVG-as-image case in the canvas image sources section on setting the cross-origin status of image content. Any objections?

Secondly, do we want to specify the origin-clean behavior as implemented by browsers for SVG with foreignObject content? That is, the dependency on how the image src is provided.

Finally, do we want to specify a common behavior for the blob case, or leave that up to browsers?

@domenic

Related issue for VideoSource: #10489