Intent to Implement and Ship: Stop tainting canvases when drawing SVG with <foreignObject>

[Justin Novosad]

Contact emails

ju...@chromium.org, p...@chromium.org, f...@opera.com

Spec

https://html.spec.whatwg.org/multipage/scripting.html#the-image-argument-is-not-origin-clean

Summary

The implementation in Chrome was deliberately not spec compliant: we tainted the canvas out of concerns for user privacy. With the current implementation of foreignObject, the OS theme could be partially leaked and used as a fingerprinting.  For example, by drawing HTML form controls into a canvas, and reading back the pixels.

However, <foreignObject> *is* secure when it comes to not leaking cross-origin content and not leaking browsing history (via visited link color).

Reasons for lifting the restriction on <foreignObject> readbacks:

• Spec compliance and browser interoperability.
• Would allow HTML-rendered text (among other things) to be uploaded to WebGL textures. Current workaround is to render text in a 2D canvas, which requires apps to do their own error-prone layout calculations, and is limited in terms of style support.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Interoperability and Compatibility Risk

This actually fixes a long-standing interoperability bug.

OWP launch tracking bug

crbug.com/294129

Entry on the feature dashboard

None, since this is a very small change.

[Rick Byers]

Sounds reasonable to me (especially given our policy on fingerprinting).  What other browsers already have this behavior?  Are there any interop tests testing this?

[Justin Novosad]

Firefox already has this behavior, Safari and Edge do not.

I did not find anything in web-platform-tests that covers this.

[Rick Byers]

LGTM1 to match the spec and Firefox.

If it's easy it would be great to get a WPT test in place that tracks the deviation between Chrome/Firefox and Edge/Safari.

[Justin Novosad]

On Tue, Dec 20, 2016 at 4:06 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM1 to match the spec and Firefox.

If it's easy it would be great to get a WPT test in place that tracks the deviation between Chrome/Firefox and Edge/Safari.

Sure thing. It's super easy.

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[TAMURA, Kent]

LGTM3

--

TAMURA Kent
Software Engineer, Google

[Emily Stark]

On the bug, the last comment about leaking visited links sounds somewhat inconclusive (https://bugs.chromium.org/p/chromium/issues/detail?id=294129#c24). "The real danger is leaking visited link information which is managed in the browser process. In my tests, this doesn't leak, but I don't think we can say that confidently yet."

Is there any more information available about the risk of leaking visited links?

[Justin Novosad]

On Thu, Dec 22, 2016 at 1:54 PM, Emily Stark <est...@chromium.org> wrote:

On the bug, the last comment about leaking visited links sounds somewhat inconclusive (https://bugs.chromium.org/p/chromium/issues/detail?id=294129#c24). "The real danger is leaking visited link information which is managed in the browser process. In my tests, this doesn't leak, but I don't think we can say that confidently yet."

Is there any more information available about the risk of leaking visited links?

pdr@ or fs@, do you know the answer?

Assuming there is no risk, We also have to make sure there is adequate testing around this.

[Rick Byers]

+esprehn@ who (IIRC) has also done some digging into how exactly visited link information can leak.

[Fredrik Söderquist]

On Thu, Dec 22, 2016 at 8:39 PM, Justin Novosad <ju...@chromium.org> wrote:

On Thu, Dec 22, 2016 at 1:54 PM, Emily Stark <est...@chromium.org> wrote:

On the bug, the last comment about leaking visited links sounds somewhat inconclusive (https://bugs.chromium.org/p/chromium/issues/detail?id=294129#c24). "The real danger is leaking visited link information which is managed in the browser process. In my tests, this doesn't leak, but I don't think we can say that confidently yet."

Is there any more information available about the risk of leaking visited links?

pdr@ or fs@, do you know the answer?

IIRC this is handled by making sure Element within SVGs in "image contexts" are never marked as being links, hence preventing link-state resolution (=> always unvisited.) A quick look in Node::setLink seems to confirm that.

/fs

[Fredrik Söderquist]

On Thu, Dec 22, 2016 at 8:39 PM, Justin Novosad <ju...@chromium.org> wrote:

On Thu, Dec 22, 2016 at 1:54 PM, Emily Stark <est...@chromium.org> wrote:

On the bug, the last comment about leaking visited links sounds somewhat inconclusive (https://bugs.chromium.org/p/chromium/issues/detail?id=294129#c24). "The real danger is leaking visited link information which is managed in the browser process. In my tests, this doesn't leak, but I don't think we can say that confidently yet."

Is there any more information available about the risk of leaking visited links?

pdr@ or fs@, do you know the answer?

Assuming there is no risk, We also have to make sure there is adequate testing around this.

I did a quick scan for existing test coverage and found:

svg/as-image/svg-canvas-link-not-colored.html

/fs

[Fredrik Söderquist]

On Thu, Dec 22, 2016 at 9:06 PM, Fredrik Söderquist <f...@opera.com> wrote:

On Thu, Dec 22, 2016 at 8:39 PM, Justin Novosad <ju...@chromium.org> wrote:

On Thu, Dec 22, 2016 at 1:54 PM, Emily Stark <est...@chromium.org> wrote:

On the bug, the last comment about leaking visited links sounds somewhat inconclusive (https://bugs.chromium.org/p/chromium/issues/detail?id=294129#c24). "The real danger is leaking visited link information which is managed in the browser process. In my tests, this doesn't leak, but I don't think we can say that confidently yet."

Is there any more information available about the risk of leaking visited links?

pdr@ or fs@, do you know the answer?

Assuming there is no risk, We also have to make sure there is adequate testing around this.

I did a quick scan for existing test coverage and found:

svg/as-image/svg-canvas-link-not-colored.html

At closer inspection it doesn't look like the link-hashing has an implementation that allows for testing of though. Unless I've missed a turn somewhere...

[PhistucK]

Will this effectively let you capture a web page screenshot?

(And sort of one step closer to the CSS element() function - put elements in <svg>...<foreignObject>..., put that SVG image into a <canvas>, get image as data URL, set as <img src> or CSS background-image every 1000 / 60 seconds?)

☆PhistucK

[Philip Rogers]

Yeah, it will enable that usecase as long as there are no subresources.

[PhistucK]

Oh, so not really.

(I was thinking about the Google Feedback feature that currently captures the page by probably re-rendering using JavaScript)

☆PhistucK