- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 22 Mar 2010 10:29:36 +0100
- To: Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>
- CC: public-webapps <public-webapps@w3.org>
Hi Pierre, On 21/03/10 10:15 PM, Pierre-Antoine LaFayette wrote: > Thank you Marcos for your feedback. You are correct; I did not make it > clear that the calls to getImageData and toDataURL should raise the > standard exception that occurs when attempting to access data of a > tainted canvas. I've updated the document to make it more explicit: > > An Image object with an icon URI as its src attribute MUST NOT be > considered as same-origin as any other origin. If an Image with an > icon URI src is drawn to a canvas, the canvas MUST be considered > tainted and have its origin-clean flag set to false. As such, if > "getImageData" or "toDataURL" is called on a canvas that has been > tainted by icon URI Image data, the method MUST raise a SECURITY_ERR > <http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#security_err> exception. > See Security with canvas elements > <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements> in > the HTML5 Draft Standard > <file:///K:/draft-icon-uri-scheme/draft-lafayette-icon-uri-scheme-00.html#HTML5> [HTML5] > for further details. Looks good to me :) > On 21 March 2010 14:04, Marcos Caceres <marcosc@opera.com > <mailto:marcosc@opera.com>> wrote: > > Hi, > > On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette > <pierre.lafayette@gmail.com <mailto:pierre.lafayette@gmail.com>> wrote: > > Hi everyone! > > Sorry I've let this thread go a bit stale. I've been tied up with > more > > pressing matters for a while now :( > > From the all the great feedback in this thread, I've been able to > determine > > that there really should be 2 parts to this proposal: > > > > The specification of an icon URI scheme that resolves platform > icons by > > filetype > > The extension of the File object interface to include methods to > retrieve > > its icon data or perhaps an icon URI that doesn't taint the canvas > > > > The first part is a reduction of the original scope of the icon > URI scheme > > to the essential functionality that everyone seemed (if I'm not > mistaken) to > > be okay with. I'm sure further functionality could be added in > the future if > > needed. > > Everyone seemed to agree that #2 is a good idea --albeit not > mine; credit to > > Maciej for this one. > > So for the first part, I've put together a draft document that > I'd really > > like everyone to comment on before I even consider sending it out to > > uri-review@ietf.org <mailto:uri-review@ietf.org>. > > It is located > > here: > http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html. > > Just had a quick read... overall, the document reads quite well. > > However, I think the following might be a little bit underspecified: > > "Applications MUST NOT allow the getImageData and toDataURL methods to > access to the Image data of platform icons drawn to the canvas." > > I agree with the rationale of the security consideration, but perhaps > it would be nice to throw an appropriate DOM exception here... might > help developers know programmatically why they are not allowed to > access these things. Without some kind of indication, it might leave > people thinking that there is a bug in the browser or that they've > done something wrong. > > > I hope it correctly interprets the issues we've discussed. > > For the second part, I'm not exactly sure what the correct > procedure is. I > > imagine it would involve making an addendum to the existing File > interface > > specification. So if anyone has any guidance on this, it would be > greatly > > appreciated. > > Once again; thanks for everyone's help and patience in this process. > > -- > > Pierre. > > > > > > -- > Marcos Caceres > http://datadriven.com.au > > > > > -- > Pierre. -- Marcos Caceres Opera Software
Received on Monday, 22 March 2010 09:30:17 UTC