W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

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

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 22 Mar 2010 10:29:36 +0100
Message-ID: <4BA73880.2080503@opera.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT