Punting this to Blink>Canvas, because in this case the origin check is replaced/bypassed by a check of the scheme ("data").

Flagging as a security issue. 

I tried hacking around this to see whether it is an exploitable vulnerability.  It seem that SVG files loaded into image elements do not load dependent resources (i.e. the svg needs to be completely self-contained).  Therefore, if the svg contains a <foreignObject> that contains HTML markup that depends on loadable resources (e.g. img, iframe, etc.), said resources are never loaded for the purpose of rasterizing the <img> that contains the SVG.

@fs, @pdr: Is it by design that <img>s that load SVGs ignore the SVG's dependent resources?

If this is the case, then I am tempted to say that all this time we've been tainting canvases for nothing when drawing svg images with <foreignObject> tags because any cross-origin content referenced within the foreignObject will not have been rendered.

Is this correct?

Yes, that's the intended behavior ATM. (SVGs in an image context can only load additional resources from data URLs.)

Okay, so this issue is not as severe as I thought.  It cannot be exploited to access cross-origin content.  It can however be used in an attack to sniff the user's browsing history by inspecting the colors of hyperlinks to determine whether they've been visited... which is bad, but not as bad.

Hmmm... Actually we can't even do that (sniff history). It seems Hyperlinks are not colored based on being visited when inside a <foreignObject>.  So it is not clear to me whether there is an exploitable vulnerability here.

@Junov, can you change this? I outlined the threats I'm aware of in https://bugs.chromium.org/p/chromium/issues/detail?id=294129#c21. I think we should remove this restriction.

I am not exactly sure either what are the vulnerabilities, but if you are concerned about locale detection, then the input type file is worse than the spellcheck dictionary. But Firefox, which doesn't taint the canvas because "they have enough background security measures (.acc Robert Longson one of the svg implementers @Mozilla) doesn't prevent this either (the "no file selected" is in user's locale).

But they do remove all user agent and OS specific styles on all inputs, and probably some other elements. So the exported image is the same for osX or win, thing that you don't do in chrome. 

Safari does taint the canvas too when a foreignObject has been painted on it, whether it comes from a Blob URI or a data one.

@pdr: I agree to lift the restrictions in the interest of inter-operability, but I'll circulate the idea as an "intent to ship" on blink-dev to see if there are any objections.

Removing security labels given the assessment that the security risks are benign.

Marking as WontFix because we got the required approvals for lifting the content security restriction on foreignObjects drawn into canvases.

\o/