Re: Steps to creating a browser standard for the moz-icon:// scheme

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.


On 21 March 2010 14:04, Marcos Caceres <marcosc@opera.com> wrote:

> Hi,
>
> On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette
> <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.
> > 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.