WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 29305
17150
safe <img src=data:...> should not mark <canvas> unsafe
https://bugs.webkit.org/show_bug.cgi?id=17150
Summary
safe <img src=data:...> should not mark <canvas> unsafe
Anne van Kesteren
Reported
2008-02-02 02:27:21 PST
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).
Attachments
Add attachment
proposed patch, testcase, etc.
Oliver Hunt
Comment 1
2008-06-28 00:55:55 PDT
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
Comment 2
2008-06-30 16:08:18 PDT
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
Comment 3
2008-06-30 16:23:49 PDT
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
Comment 4
2008-07-01 01:38:56 PDT
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
Comment 5
2008-07-01 01:50:27 PDT
> 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
Comment 6
2008-07-01 09:24:31 PDT
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
Comment 7
2008-07-01 10:12:12 PDT
(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
Comment 8
2009-09-10 08:59:47 PDT
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
Comment 9
2009-09-19 10:19:38 PDT
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
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug