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

[Pierre-Antoine LaFayette]

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
>  exception.
> See Security with canvas 
> elements
>  in
> the HTML5 Draft 
> Standard
>  [HTML5]
> for further details.


On 21 March 2010 14:04, Marcos Caceres  wrote:

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

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

[Marcos Caceres]

Hi,

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

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

[Pierre-Antoine LaFayette]

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:

   1. The specification of an icon URI scheme that resolves platform icons
   by filetype
   2. 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-rev...@ietf.org.
It is located here:
http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html.
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.