safe <img src=data:...> should not mark <canvas> unsafe

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Anne van Kesteren]

There are two types of <img> elements that represent a data: URI. Those that are safe, and those that are unsafe. Safe <img> elements loading a data: URI are all images represented by a data: URI that did not have their redirection chain go cross-site first.

The HTML5 origin policy is currently unclear on this matter as it does not distinguish these image types.

This bug is important to fix as it will allow sites to export the <canvas> using toDataURL(), safe it somewhere, and then later import it again, and export it, et cetera (round tripping).

[Oliver Hunt]

Anne, the issue is how you identify a safe vs. unsafe data uri when all you have is a string "data:...." which is the case when the src is set on an image.  How is it possible to work around this?

You can achieve the goal of storage relatively simply through the use of ImageData, although you would unfortunately need to do your own serialisation :-/

[Anne van Kesteren]

The string "data:..." is always safe. (Consider that the author can do anything with it.)

(ImageData doesn't really work well, as it varies based on device resolution, etc. It's not really fit for storage.)

[Oliver Hunt]

But what happens if i have a data uri that is the result of a redirect?  eg. img src="example.com/redirectToDataURI" ?

I'll admit i really don't know how this should effect the model, as this is much more towards Sam's area of expertise.

[Sam Weinig]

I agree with Anne on this.  data: urls are safe and should not taint the canvas.  The redirection should not be an issue as we will not be basing our tainting policy on the resolved url, but rather the provided one.

[Adam Barth]

> The redirection should not be an issue as we will not be basing our
> tainting policy on the resolved url, but rather the provided one.

It seems like both URLs are important to consider.  Maybe I'm misunderstanding, but suppose site A includes an image from itself, but the URL actually redirects to site B.  Shouldn't that taint the canvas as cross-origin even though the provided URL matched the original site?

[Sam Weinig]

I was only referring to the data: url case.  In general, I believe we need to base our tainting policy on the resolved URL.

[Collin Jackson]

(In reply to comment #6)
> I was only referring to the data: url case.  In general, I believe we need to
> base our tainting policy on the resolved URL.

For data: URLs, since the resolved URL has ambiguous taint, would it be possible to use the second-to-last URL in the redirect chain? (the one that provided a redirect to the ambiguous data: URL) Are there any cases where the second-to-last URL would also be ambiguous?

[Mihai Sucan]

I bumped into this bug working on my Web application which uses Canvas.

In Gecko 1.9.0 images with a data URL did mark the canvas as unsafe. Gecko 1.9.1 fixes this issue and now we can draw images with data URLs in Opera and Firefox as well. I would suggest that Webkit does the same.

With regards to the redirection problem I'd say just mark the canvas as unsafe if the data URL comes from a redirection.

[Adam Barth]

I forgot about this bug and fixed the issue in Bug 29305.  I didn't add a test for the redirect case.  If you think that's important, please file a bug for adding a test case and CC me.

*** This bug has been marked as a duplicate of bug 29305 ***