This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Multipage: http://www.whatwg.org/C#security-with-canvas-elements Complete: http://www.whatwg.org/c#security-with-canvas-elements Comment: Why do we want to taint on style set and not on style use? Posted from: 71.184.125.56 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111017 Firefox/10.0a1
In particular, as far as I can tell Gecko taints the canvas if a tainted fill or stroke style is actually used to paint something, not just when the style is merely set. There is a subtle but important (imo) issue here: if we at some point allow CanvasPatterns that contain images and are mutable, then the "taint on draw" approach would Just Work while the current approach would have to be changed in some way (either to retaint all canvases that have the pattern as a style on pattern change or to taint on draw or something). I should also note that the property of being same-origin may not be time-invariant when document.domain is involved; I haven't looked into what implementations actually do there. What are the benefits of the current model apart from it maybe being slightly easier to define?
One benefit is that you don't have to track origin once you lose the HTMLImageElement object. I don't see why we'd allow patterns to be mutated, but I grant your point. Any other implementors have an opinion? Is there a test for this?
I believe WebKit computes the taint bit for the pattern when createPattern is called. It's helpful to do the computation when the HTMLImageElement is present in case we need to look at the network activity that occurred when the image was loaded (e.g., to check whether CORS when through fine).
> One benefit is that you don't have to track origin once you lose the > HTMLImageElement object. At least in Gecko; this is not a huge hardship: it's a single pointer in the pattern data structure.... It's stored when the pattern is created, along with the actual image data. > I believe WebKit computes the taint bit for the pattern when createPattern is > called. That sounds pretty equivalent to what we do. > Is there a test for this? Yes: http://test.w3.org//html/tests/submission/PhilipTaylor/canvas/security.pattern.canvas.fillStyle.html http://test.w3.org//html/tests/submission/PhilipTaylor/canvas/security.pattern.canvas.strokeStyle.html http://test.w3.org//html/tests/submission/PhilipTaylor/canvas/security.pattern.image.fillStyle.html http://test.w3.org//html/tests/submission/PhilipTaylor/canvas/security.pattern.image.strokeStyle.html See also https://bugzilla.mozilla.org/show_bug.cgi?id=693051 which was filed on Gecko not passing those tests. We can switch to doing that, obviously, but we're not sure that's the best behavior going forward...
Any opinions from other browser vendors? (Opera, Microsoft?) I don't really see much of an argument one way or the other. Doing it early seems cleaner from a security perspective and may be imperceptibly more efficient (especially if the pattern is used more than once). Doing it later is more forwards-looking. The earlier point about document.domain is an interesting one. Once document.domain is set, all future uses of images will be tainted (since the effective origin of a document after document.domain is set can never match the origin of an image), so one way that this would affect things today is when document.domain is set between the pattern being initialised and the pattern being used. I think this is a non-issue from a security perspective, and it does seem like if you've been using a pattern and reading it that it would be weird for it to suddenly stop working. I think personally I would lean towards what the spec has now, but I'm happy to change it if the majority of browsers want to change it.
Note that as far as I can tell right now the spec says to use the document origin, not the effective script origin, for the security check. So per spec, document.domain should have no effect. That's not the case in Gecko right now, I'm pretty sure. Again, no idea what other UAs do.
Hm, good point. I wonder if we should change that. I guess we should, for consistency, though I suppose it makes the API more of a pain to use if you're also using document.domain... I'm going to make the change (diff below) but if there's feedback to the contrary then I'll change it back. I haven't tested browsers on this; it makes the spec more like Gecko on this issue according to what you (bz) have said above. In the meantime I would really like to get feedback from Microsoft or Opera about what they would prefer here. In the absence of any further feedback, I guess I'll leave the spec as is, since that seems to be what is most widely implemented (everyone I tested but Gecko does it the way the spec says, according to one of the tests above that I used to quickly probe this).
Checked in as WHATWG revision r6776. Check-in comment: Origins should be based on the effective origin. http://html5.org/tools/web-apps-tracker?from=6775&to=6776
(In reply to comment #8) > Checked in as WHATWG revision r6776. > Check-in comment: Origins should be based on the effective origin. > http://html5.org/tools/web-apps-tracker?from=6775&to=6776 We don't really have a strong opinion here... this looks like a minor issue. I don't think there's a big enough problem here to necessitate a spec change.
Ian, what's the actual effect of the spec change? If I have a site at foo.bar.com and it sets document.domain to bar.com, does that allow it to read image data from bar.com?
> If I have a site at > foo.bar.com and it sets document.domain to bar.com, does that allow it to read > image data from bar.com? I hope not! That would be a security vulnerability. :) IMHO, we should just pretend document.domain doesn't exist for all of these modern security checks.
I agree, esp on the "security vulnerability" bit; hence the question. To be clear, Gecko's behavior at the moment is that if the document has set document.domain then drawing _any_ non-CORS image into the canvas taints the canvas. At least that's what I believe based on code inspection; I have only proved it, not tested it. ;)
What the spec now says is that once you've set document.domain, any image (actually even any that had the right CORS headers) would taint. I'll revert it, given the reaction above. Of course without this we have interesting implications, e.g. two different scripts that are both same-effective-origin can get different results when they do getImageData(). Modulo that issue, looks like there's nothing to change here, so I guess I'll close the bug. Please reopen it if you add a comment that you want me to see.
Checked in as WHATWG revision r6789. Check-in comment: Go back to ignoring document.domain changes for the purposes of canvas tainting. http://html5.org/tools/web-apps-tracker?from=6788&to=6789
> Of course without this we have interesting implications, e.g. two different > scripts that are both same-effective-origin can get different results when they > do getImageData(). I believe the same is true for XMLHttpRequest today.
(In reply to comment #11) > IMHO, we should just pretend document.domain doesn't exist for all of these > modern security checks. I concur, FTR.