[whatwg] Canvas and drawWindow

[Adam Barth]

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
>>>
>>
>