- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 14 Mar 2011 18:38:37 -0700
IMHO, drawWindow is a bad idea for the security of the platform. For example, there's a complex interaction with trying to hide the color of hyperlinks to prevent history sniffing. Adam On Mon, Mar 14, 2011 at 6:28 PM, Jonas Sicking <jonas at sicking.cc> wrote: > And this is why it's a bad idea to separate "right to embed" from > "right to read" :( > > http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html > > / Jonas > > On Mon, Mar 14, 2011 at 5:52 PM, Gregg Tavares (wrk) <gman at google.com> wrote: >> Someone pointed out that once you have HTML5->Canvas->WebGL, even though you >> can't call readPixels or toDataURL or getImageData because of cross origin >> issues you can write a shader that takes longer depending on the color and >> then just time draw calls to figure out what's in the texture. >> >> In other words, if you want to prevent security issues you could only do >> this on same origin content. >> >> But then you open another can of worms. Once you can put content in a >> texture you want to be able to let the user interact with it (like they can >> with 3d css) but then you run into the issue that you don't know what the >> user's shaders are doing so you have to let JavaScript translate mouse >> coordinates which is probably another security issue on top of being a PITA >> to implement. >> >> >> On Fri, Mar 11, 2011 at 8:35 AM, Erik M?ller <emoller at opera.com> wrote: >> >>> I bet this has been discussed before, but I'm curious as to what people >>> think about breathing some life into a more general version of Mozillas >>> canvas.drawWindow() that draws a snapshot of a DOM window into the canvas? >>> https://developer.mozilla.org/en/drawing_graphics_with_canvas#section_9 >>> >>> I know there are some security considerations (for example listed in the >>> source of drawWindow): >>> >>> ?// We can't allow web apps to call this until we fix at least the >>> ?// following potential security issues: >>> ?// -- rendering cross-domain IFRAMEs and then extracting the results >>> ?// -- rendering the user's theme and then extracting the results >>> ?// -- rendering native anonymous content (e.g., file input paths; >>> ?// scrollbars should be allowed) >>> >>> I'm no security expert, but it seems to me there's an easy way to at least >>> cater for some of the use-cases by always setting origin-clean to false when >>> you use drawWindow(). Sure it's a bit overkill to always mark it dirty, but >>> it's simple and would block you from reading any of the pixels back which >>> would address most (all?) of the security concerns. >>> >>> I'm doing a WebGL demo, so the use-case I have for this would be to render >>> a same-origin page to a canvas and smack that on a monitor in the 3d-world. >>> Intercept mouse clicks, transform them into 2d and passing them on would of >>> course be neat as well and probably opens up the use-cases you could dream >>> up. >>> >>> So, I'm well aware its a tad unconventional, but perhaps someone has a >>> better idea of how something like this could be accomplished... i.e. via SVG >>> and foreignObject or punching a hole in the canvas and applying a transform >>> etc. I'd like to hear your thoughts. >>> >>> -- >>> Erik M?ller >>> Core Developer >>> Opera Software >>> >> >
Received on Monday, 14 March 2011 18:38:37 UTC