Re: Review of 3.14.11. The canvas element

Mihai Sucan wrote:
>> Mozilla has a non-standard drawWindow method, to draw whole Windows 
>> into the canvas (e.g. for thumbnails), which sounds similar to your 
>> proposal. It is limited to trusted content (like extensions) for 
>> security reasons: [...]
> 
> If the script is on the same (sub)domain as the page, then allow using 
> drawWindow(), if not raise an exception.
> 
> The idea is: the page includes the script, it's therefore trusted, being 
> hosted in the same place. If the page includes cross-domain 
> IFRAMEs/images/objects/embeds, then hide them in the render.

As I understand it, "hide them" is the cause of all the implementation 
concerns - it's easy to say, but non-trivial to write code for :-)
If browser developers indicate they are willing to implement it and can 
cope with the security issues, I don't expect there would be other 
significant problems with the feature.

> However, take into consideration two facts:
> 
> 1. the JavaScript function doesn't need to capture the page render to 
> steal the information from inputs. That's obvious - the script can use 
> the DOM to take the vlues directly. You can't protect anyone from that. 
> Thus, I see no reason to consider this a security issue, more than, say, 
> having scripts themselves running in the page...

Normal scripts can't get information about the pixels in an image, they 
can't get the filename from an <input type=file>, they can't see what 
the user's scrollbars look like and draw their own fake UI, they can't 
see whether a user has visited a link before (or at least some specs 
(e.g. CSS3 Selectors) suggest that browsers should prevent that). Those 
would be new problems exposed by a drawWindow function.

> 2. the drawImage() method defined by the HTML 5 spec can take an 
> HTMLImageElement. The spec does not define any security-related 
> restrictions. One could go about drawWindow in the same way.

It does define restrictions, slightly indirectly - you can draw any 
image onto the canvas, but then you can't retrieve any data from the 
image unless it was from the same origin. ("Security: To prevent 
information leakage, the toDataURL() and getImageData() methods should 
raise a security exception if the canvas has ever had an image painted 
on it whose origin is different from that of the script calling the 
method.")

The same restriction against toDataURL/getImageData could be applied 
whenever drawWindow is used, which I expect would avoid most security 
problems. That would limit the usefulness (e.g. you couldn't use 
drawWindow to draw some text onto an image and then use toDataURL to 
save it, like in a paint program) - I don't know whether that limit 
would significantly affect the overall usefulness of the feature 
compared to alternative solutions, since that depends on what people 
would actually want to use drawWindow for.

-- 
Philip Taylor
philip@zaynar.demon.co.uk

Received on Wednesday, 22 August 2007 13:39:40 UTC