17150 2008-02-02 02:27:21 -0800 safe <img src=data:...> should not mark <canvas> unsafe 2009-09-19 10:19:38 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) PC OS X 10.5 RESOLVED DUPLICATE 29305 P2 Normal --- 0 annevk webkit-unassigned abarth grahamperrin mihai.sucan oliver sam oldest_to_newest 69162 0 annevk 2008-02-02 02:27:21 -0800 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). 84639 1 oliver 2008-06-28 00:55:55 -0700 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 :-/ 84797 2 annevk 2008-06-30 16:08:18 -0700 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.) 84798 3 oliver 2008-06-30 16:23:49 -0700 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. 84832 4 sam 2008-07-01 01:38:56 -0700 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. 84834 5 abarth 2008-07-01 01:50:27 -0700 > 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? 84886 6 sam 2008-07-01 09:24:31 -0700 I was only referring to the data: url case. In general, I believe we need to base our tainting policy on the resolved URL. 84889 7 collinj 2008-07-01 10:12:12 -0700 (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? 146211 8 mihai.sucan 2009-09-10 08:59:47 -0700 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. 148506 9 abarth 2009-09-19 10:19:38 -0700 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 ***