- From: Philip Taylor <philip@zaynar.demon.co.uk>
- Date: Wed, 22 Aug 2007 14:39:31 +0100
- To: Mihai Sucan <mihai.sucan@gmail.com>
- CC: public-html <public-html@w3.org>
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