Re: Steps to creating a browser standard for the moz-icon:// scheme
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 marc...@opera.com mailto:marc...@opera.com wrote: Hi, On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com mailto:pierre.lafaye...@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-rev...@ietf.org mailto: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. -- Marcos Caceres Opera Software
Re: Steps to creating a browser standard for the moz-icon:// scheme
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.
Re: Steps to creating a browser standard for the moz-icon:// scheme
Hi, On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette pierre.lafaye...@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-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
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_ERRhttp://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#security_err exception. See Security with canvas elementshttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements in the HTML5 Draft Standardfile:///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 marc...@opera.com wrote: Hi, On Sun, Mar 21, 2010 at 4:16 PM, Pierre-Antoine LaFayette pierre.lafaye...@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-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
On Thu, Feb 4, 2010 at 1:34 AM, timeless timel...@gmail.com wrote: 2010/2/3 Adam Barth w...@adambarth.com: You've been getting a lot of feedback from Mozilla. Jonas Sicking, Robert O'Callahan, and Boris Zbarsky are all leading members of the Mozilla community. I guess that makes me a trailing member :) I was going to mention you, but then your email spoke about Nokia so I was worried that I was confused. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
Is there anyone from Mozilla on this mailing list? I'd like to get their opinion on these matters. 2010/2/1 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com So it seems like there is a general consensus that at least some parts of the icon URI scheme are useful and are worth standardizing. One thing I was confused about was the mention of the File object; I initially believed we were referring to http://www.mozilla.org/js/js-file-object.html, however, if I'm not mistaken, I think people actually mean the FileUpload object. I've summarized the issues discussed thus far: *Possible Usage Examples:* # Return the platform icon for the given extension icon:.zip?size=16state=disabled # query form icon:.mp3;16;disabled # short form # Return the platform icon for the specified file URI icon:file:///home/pierre/test.png # Return an icon for a standardized identifier name icon:stock/gtk-go-up?size=menu icon:stock/newtab;32;disabled icon:stock/home;16 icon:stock/refresh;48 *Security risks* - Probing??? - Mozilla has been exposing the moz-icon scheme to the web for years. - Avoiding Cross-domain theft of arbitrary images; machine fingerprinting - Canvas getPixelData and toDataURL API calls - The only issue has been the cross-domain image theft ( http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html) vulnerability in Firefox 2 that has since been resolved with cross-domain checks. - User interaction visual exploit - Gets user to confirm a known pixel is present in the icon image - Very loose exploit; basically tricking a user into providing information about her installed applications - Mozilla allows this exploit - Can retrieve the width and height of an image without security checks. *File URIs in icon scheme* - What are the use cases? - Browser, local html, web sites where files are uploaded by user. - Risk of file system probing?? - Maybe if somehow the web site can acess the image data for an icon. - Can we use an input File object instead? - Idea: Get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. - Idea: The File object could give you an icon: URL that specifically identifies that file's icon. - Idea: The File object could give you the data URI for the icon. *Stock Images* - Should we include the stock image option in the specification? - Hard to define a common set of icons (and sizes) across all platforms - Cross platform: save, zoom in/out, print, folder, file, cut, paste, copy, delete, add, ok, cancel, about, info, help, quit, strikethrough, underline, select font, select color, quote, center, left/right align, change font, text-size, list, bold, italic, etc. - E.g. http://www.pygtk.org/docs/pygtk/gtk-stock-items.html - Browser specific: newtab, forward, back, stop, home, refresh, etc. - Possibly find a set of creative common icons that can always be used if the platform does not provide the stock icons. - How do we choose which icons should be included in the stock? *Icon Sizes* - Default image size of 16x16 - Should sizes be predefined identifiers, e.g. tiny, small, medium, large? - What sizes are acceptable? - Platform differences - Mac OSX supports: 16×16, 32×32, 48×48, 128×128, 256×256 and 512×512 pixels and multiple states - Windows XP supports: 16x16, 32x32, 48x48 and upscales up to 256x256 - Should an arbitrary integer be allowed causing a potential scaling of icons? *Naming of URI* - Should we use about:icon or res:icon rather than add a new scheme? - IMO, icon: is still the ideal choice. The two big ones are: the allowance of the file:// syntax versus adding a getIconURI() type method to the FileUpload object and the support for stock images. Perhaps the file:// syntax can work for internal and local pages in the same way that the file URI only works locally. Whereas the FileUpload object can be used to retrieve the icon URI or data URI or something. I'm guessing the icon URI returned would have to be using the icon:file-extension syntax? For the stock images, if people could comment on the plausibility of this option. 2010/2/1 Ian Fette (イアンフェッティ) ife...@google.com Just to be clear, I believe Pierre was referring to file extensions (e.g. .jpg) not browser extensions. At any rate, I think it would be convenient, if you are able to get a File handle, to also be able to get an image representation of the file. That could be some thumbnail if the OS has already generated and stored a thumbnail and it's essentially free to get it on the platform, or if a thumbnail is not available (or perhaps regardless of whether or not a thumbnail is available) you could get some other image representation that is somehow representative of the file type (e.g. some icon
Re: Steps to creating a browser standard for the moz-icon:// scheme
You've been getting a lot of feedback from Mozilla. Jonas Sicking, Robert O'Callahan, and Boris Zbarsky are all leading members of the Mozilla community. Adam 2010/2/3 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Is there anyone from Mozilla on this mailing list? I'd like to get their opinion on these matters. 2010/2/1 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com So it seems like there is a general consensus that at least some parts of the icon URI scheme are useful and are worth standardizing. One thing I was confused about was the mention of the File object; I initially believed we were referring to http://www.mozilla.org/js/js-file-object.html, however, if I'm not mistaken, I think people actually mean the FileUpload object. I've summarized the issues discussed thus far: Possible Usage Examples: # Return the platform icon for the given extension icon:.zip?size=16state=disabled # query form icon:.mp3;16;disabled # short form # Return the platform icon for the specified file URI icon:file:///home/pierre/test.png # Return an icon for a standardized identifier name icon:stock/gtk-go-up?size=menu icon:stock/newtab;32;disabled icon:stock/home;16 icon:stock/refresh;48 Security risks - Probing??? - Mozilla has been exposing the moz-icon scheme to the web for years. - Avoiding Cross-domain theft of arbitrary images; machine fingerprinting - Canvas getPixelData and toDataURL API calls - The only issue has been the cross-domain image theft (http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html) vulnerability in Firefox 2 that has since been resolved with cross-domain checks. - User interaction visual exploit - Gets user to confirm a known pixel is present in the icon image - Very loose exploit; basically tricking a user into providing information about her installed applications - Mozilla allows this exploit - Can retrieve the width and height of an image without security checks. File URIs in icon scheme - What are the use cases? - Browser, local html, web sites where files are uploaded by user. - Risk of file system probing?? - Maybe if somehow the web site can acess the image data for an icon. - Can we use an input File object instead? - Idea: Get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. - Idea: The File object could give you an icon: URL that specifically identifies that file's icon. - Idea: The File object could give you the data URI for the icon. Stock Images - Should we include the stock image option in the specification? - Hard to define a common set of icons (and sizes) across all platforms - Cross platform: save, zoom in/out, print, folder, file, cut, paste, copy, delete, add, ok, cancel, about, info, help, quit, strikethrough, underline, select font, select color, quote, center, left/right align, change font, text-size, list, bold, italic, etc. - E.g. http://www.pygtk.org/docs/pygtk/gtk-stock-items.html - Browser specific: newtab, forward, back, stop, home, refresh, etc. - Possibly find a set of creative common icons that can always be used if the platform does not provide the stock icons. - How do we choose which icons should be included in the stock? Icon Sizes - Default image size of 16x16 - Should sizes be predefined identifiers, e.g. tiny, small, medium, large? - What sizes are acceptable? - Platform differences - Mac OSX supports: 16×16, 32×32, 48×48, 128×128, 256×256 and 512×512 pixels and multiple states - Windows XP supports: 16x16, 32x32, 48x48 and upscales up to 256x256 - Should an arbitrary integer be allowed causing a potential scaling of icons? Naming of URI - Should we use about:icon or res:icon rather than add a new scheme? - IMO, icon: is still the ideal choice. The two big ones are: the allowance of the file:// syntax versus adding a getIconURI() type method to the FileUpload object and the support for stock images. Perhaps the file:// syntax can work for internal and local pages in the same way that the file URI only works locally. Whereas the FileUpload object can be used to retrieve the icon URI or data URI or something. I'm guessing the icon URI returned would have to be using the icon:file-extension syntax? For the stock images, if people could comment on the plausibility of this option. 2010/2/1 Ian Fette (イアンフェッティ) ife...@google.com Just to be clear, I believe Pierre was referring to file extensions (e.g. .jpg) not browser extensions. At any rate, I think it would be convenient, if you are able to get a File handle, to also be able to get an image representation of the file. That could be some thumbnail if the OS has already generated and stored a thumbnail and it's essentially free to get it on the platform, or if a
Re: Steps to creating a browser standard for the moz-icon:// scheme
Just to be clear, I believe Pierre was referring to file extensions (e.g. .jpg) not browser extensions. At any rate, I think it would be convenient, if you are able to get a File handle, to also be able to get an image representation of the file. That could be some thumbnail if the OS has already generated and stored a thumbnail and it's essentially free to get it on the platform, or if a thumbnail is not available (or perhaps regardless of whether or not a thumbnail is available) you could get some other image representation that is somehow representative of the file type (e.g. some icon for JPEG files -- this image does not need to be part of the standard, does not need to be consistent across browsers, but should ideally be consistent for all JPEG files you call geticon on within the same UA on the same computer... My $0.02 2010/1/31 Maciej Stachowiak m...@apple.com On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote: 2010/1/29 Ian Fette (イアンフェッティ) ife...@google.com 2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: * Parameter: size * Values: [integer | button | toolbar | toolbarsmall | menu | dialog] * Description: If integer, this is the desired size in square pixels of the icon *Else, use the OS default for the specified keyword context. integer scales the icons to the desired size. I think we'd at least need a few different sizes for a default set of icons. I'm not sure that such icons exist. I don't see a need to standardize anything solely for use by extensions. What we should ask is which icons are useful for Web content, since that is where we have the interoperability constraint. Extensions do not currently interoperate between different browsers, nor is this planned as far as I can tell, so they cannot be the sole use case for any part of a Web standard IMO. Regards, Maciej
Re: Steps to creating a browser standard for the moz-icon:// scheme
Yes but in Windows XP they upscale anything over 48x48 I believe. On 1 February 2010 01:24, timeless timel...@gmail.com wrote: 2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
So it seems like there is a general consensus that at least some parts of the icon URI scheme are useful and are worth standardizing. One thing I was confused about was the mention of the File object; I initially believed we were referring to http://www.mozilla.org/js/js-file-object.html, however, if I'm not mistaken, I think people actually mean the FileUpload object. I've summarized the issues discussed thus far: *Possible Usage Examples:* # Return the platform icon for the given extension icon:.zip?size=16state=disabled # query form icon:.mp3;16;disabled # short form # Return the platform icon for the specified file URI icon:file:///home/pierre/test.png # Return an icon for a standardized identifier name icon:stock/gtk-go-up?size=menu icon:stock/newtab;32;disabled icon:stock/home;16 icon:stock/refresh;48 *Security risks* - Probing??? - Mozilla has been exposing the moz-icon scheme to the web for years. - Avoiding Cross-domain theft of arbitrary images; machine fingerprinting - Canvas getPixelData and toDataURL API calls - The only issue has been the cross-domain image theft ( http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html) vulnerability in Firefox 2 that has since been resolved with cross-domain checks. - User interaction visual exploit - Gets user to confirm a known pixel is present in the icon image - Very loose exploit; basically tricking a user into providing information about her installed applications - Mozilla allows this exploit - Can retrieve the width and height of an image without security checks. *File URIs in icon scheme* - What are the use cases? - Browser, local html, web sites where files are uploaded by user. - Risk of file system probing?? - Maybe if somehow the web site can acess the image data for an icon. - Can we use an input File object instead? - Idea: Get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. - Idea: The File object could give you an icon: URL that specifically identifies that file's icon. - Idea: The File object could give you the data URI for the icon. *Stock Images* - Should we include the stock image option in the specification? - Hard to define a common set of icons (and sizes) across all platforms - Cross platform: save, zoom in/out, print, folder, file, cut, paste, copy, delete, add, ok, cancel, about, info, help, quit, strikethrough, underline, select font, select color, quote, center, left/right align, change font, text-size, list, bold, italic, etc. - E.g. http://www.pygtk.org/docs/pygtk/gtk-stock-items.html - Browser specific: newtab, forward, back, stop, home, refresh, etc. - Possibly find a set of creative common icons that can always be used if the platform does not provide the stock icons. - How do we choose which icons should be included in the stock? *Icon Sizes* - Default image size of 16x16 - Should sizes be predefined identifiers, e.g. tiny, small, medium, large? - What sizes are acceptable? - Platform differences - Mac OSX supports: 16×16, 32×32, 48×48, 128×128, 256×256 and 512×512 pixels and multiple states - Windows XP supports: 16x16, 32x32, 48x48 and upscales up to 256x256 - Should an arbitrary integer be allowed causing a potential scaling of icons? *Naming of URI* - Should we use about:icon or res:icon rather than add a new scheme? - IMO, icon: is still the ideal choice. The two big ones are: the allowance of the file:// syntax versus adding a getIconURI() type method to the FileUpload object and the support for stock images. Perhaps the file:// syntax can work for internal and local pages in the same way that the file URI only works locally. Whereas the FileUpload object can be used to retrieve the icon URI or data URI or something. I'm guessing the icon URI returned would have to be using the icon:file-extension syntax? For the stock images, if people could comment on the plausibility of this option. 2010/2/1 Ian Fette (イアンフェッティ) ife...@google.com Just to be clear, I believe Pierre was referring to file extensions (e.g. .jpg) not browser extensions. At any rate, I think it would be convenient, if you are able to get a File handle, to also be able to get an image representation of the file. That could be some thumbnail if the OS has already generated and stored a thumbnail and it's essentially free to get it on the platform, or if a thumbnail is not available (or perhaps regardless of whether or not a thumbnail is available) you could get some other image representation that is somehow representative of the file type (e.g. some icon for JPEG files -- this image does not need to be part of the standard, does not need to be consistent across browsers, but should ideally be consistent for all JPEG files you call geticon on within the same UA on the same computer... My
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Feb 1, 2010, at 4:04 AM, Pierre-Antoine LaFayette wrote: Yes but in Windows XP they upscale anything over 48x48 I believe. According to the internets, icons for Windows Vista or later are supposed to include bitmaps up to 256x256 (6 total sizes in the standard format) and will actually be used. Previous versions of Windows only used sizes up to 64x64. Icons for Mac OS X Leopard or later are supposed to include bitmaps up to 512x512 (also 6 total sizes). Previous versions only went up to 128x128. In all cases, the OS will interpolate other sizes. http://en.wikipedia.org/wiki/Apple_Icon_Image_format http://en.wikipedia.org/wiki/ICO_(icon_image_file_format) By contrast, iPhone OS app icons are 57x57. Regards, Maciej On 1 February 2010 01:24, timeless timel...@gmail.com wrote: 2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote: 2010/1/29 Ian Fette (イアンフェッティ) ife...@google.com 2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: * Parameter: size * Values: [integer | button | toolbar | toolbarsmall | menu | dialog] * Description: If integer, this is the desired size in square pixels of the icon *Else, use the OS default for the specified keyword context. integer scales the icons to the desired size. I think we'd at least need a few different sizes for a default set of icons. I'm not sure that such icons exist. I don't see a need to standardize anything solely for use by extensions. What we should ask is which icons are useful for Web content, since that is where we have the interoperability constraint. Extensions do not currently interoperate between different browsers, nor is this planned as far as I can tell, so they cannot be the sole use case for any part of a Web standard IMO. Regards, Maciej
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/29 Ian Fette (イアンフェッティ) ife...@google.com 2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: * Parameter: size * Values: [integer | button | toolbar | toolbarsmall | menu | dialog] * Description: If integer, this is the desired size in square pixels of the icon * Else, use the OS default for the specified keyword context. integer scales the icons to the desired size. I think we'd at least need a few different sizes for a default set of icons. I'm not sure that such icons exist. -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. -Ian 2010/1/28 Adam Barth w...@adambarth.com On Wed, Jan 27, 2010 at 6:24 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Adam, could you provide your thoughts on using about:icon? I'd prefer not to use about:icon, but I don't think it matters much. Currently, the only URL in the about scheme that's accessible to web content is about:blank. I believe Internet Explorer has a res scheme that might be more appropriate. That's a general way to refer to browser-provided resources with URLs. Perhaps res:icon?ext=htmlsize=32 At a higher level, we could bikeshed about the name forever. You should pick whatever you think is most aesthetic since you're driving the process. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. Could you elaborate on the use cases for these icons? What sort of web applications would really benefit from emulating the native look and feel of the user's OS, and in particular, what sort of functionality would these icons be used to represent? My concern is that application developers will find it difficult for their app's own custom theme to visually integrate well with system specific icons. It seems much more likely that developers would want to have all icons used to be designed with a common style. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/26 Maciej Stachowiak m...@apple.com On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. To gain an interoperability benefit, we would presumably need to define the set of icons available, right? Why do you think that? Can you please elaborate? The icons should be the native icons for a particular file type. What possibly need to define is size, what to do if the filetype is unknown, whether we should include Browser specific stock image identifiers to allow the use of Browser themed icons, etc. Chromium currently has an internal scheme (chrome://fileicon/path) that it is using for internal HTML pages and Mozilla's moz-icon scheme is already exposed to web content. I am not sure if other browsers have similar schemes for providing icon resources internally. I am working on the Internet Draft for this and will be seeking feedback soon enough. If anyone has any thoughts on security issues, it would be most welcomed as a thorough security analysis is required for the draft. I would recommend not using // in URLs of this scheme unless they have an authority component. It is better for them not to look like a hierarchical URI in that case. Agreed. Regards, Maciej Thanks. 2010/1/26 Adam Barth w...@adambarth.com On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam -- Pierre. -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: The actual use case that triggered my want to have this was the FTP and file:// URI directory listings pages in Chromium. They currently are quite bland and without icons, as may be true for other browsers. Opera doesn't have icons for files, i think Safari uses 2 stock icons for folders and files. Firefox' equivalent pages use the moz-icon scheme and have the platform specific icons. Makes for very nice directory listing pages. OK, and I suppose the standard directory listing pages that Apache generates could also make use of them. It wasn't clear from your original mail that this was just about file type icons, based on the file extension. You also mentioned: stock-image is of the format: stock/icon-name icon-name is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'. It's not clear what the use cases for these are, but for these, it does seem like we would need to define a common set of icons that are available, unlike the file type icons that can load the system's associated icon. Have you considered using the existing about: URI scheme for this? This scheme is in the process of being standardised, and it is possible for specs to define URIs using it, which are then meant for resolving in application/platform specific ways. See the draft here. http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt The important part is defined in section 5, which has significant amendments described here, which have yet to be integrated into the draft. http://lists.w3.org/Archives/Public/public-html/2009Sep/0755.html http://lists.w3.org/Archives/Public/public-html/2009Sep/0767.html You could write a spec to define an about:icon URI to work like this like, e.g. about:icon?html;32 or about:icon?ext=htmlsize=32 (though, I think being shorter and avoiding '' is better, so authors don't have to bother escaping it in their HTML) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
2010/1/27 Maciej Stachowiak m...@apple.com
On Jan 27, 2010, at 4:49 AM, Pierre-Antoine LaFayette wrote:
2010/1/26 Maciej Stachowiak m...@apple.com
On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote:
Yes, I wish to expose the platform and possibly Browser theme specific
icons to web content with the Icon URI scheme. The idea is to allow the Icon
URI scheme to be used anywhere an image is specifiable by a data URI in HTML
and JavaScript. This will allow web content to emulate the look and feel of
the native Operating System and of the Browser itself in the case of themed
icons. I believe this will benefit both content creators and consumers.
To gain an interoperability benefit, we would presumably need to define
the set of icons available, right?
Why do you think that? Can you please elaborate? The icons should be the
native icons for a particular file type. What possibly need to define is
size, what to do if the filetype is unknown, whether we should include
Browser specific stock image identifiers to allow the use of Browser
themed icons, etc.
For the stock images, how can you ever reasonably rely on them without
knowing which ones are available? Getting a generic unknown image in those
cases is not likely to be good fallback.
Yes, I was thinking that the stock image seems like something that should
not be standardized for that reason. Mozilla supposedly has things like: *
moz-icon://stock*/tab-new?size=menu. For example.
Side note on security: it has to be impossible to determine the contents of
any image retrieved via such a URL, or even to detect if any two are
different, or it becomes possible to probe the filesystem or probe the
user's set of file type bindings (if it varies per OS), both of which would
be privacy violations.
I've been looking into this. A web application should never be able to
download the contents of an icon URI. The main thing to prevent is the
canvas 2D context using getPixelData or toDataURL to retrieve the data of an
image with an icon URI that has been painted onto the canvas. This one is
known (
http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html
).
Another more subtle exploit was described to me by Chromium's Glen Murphy:
The only other attack I can think of off the top of my head (which
also exists for cross domain images) is super contrived as it exploits
vision and relies on user interaction:
1. Assume that the 'no app' icon has a pixel at 8,8 that is color A
(e.g the middle of a blank page icon).
2. Assume that the app you want to detect has an icon with a color B
pixel at 8,8.
3. Set it up so that there are two links of color A and B, each with
the 8,8 pixel of the icon stretched as a background.
4. This makes only one of the links visible, those links can then
entice the user to click.
div style=-webkit-border-image: url(icon://file.type) 7 7 8 8 repeat
repeat; width:200px; height:20px; border:1px;
a style=color:B; href=# onclick=alert('you do not have X
installed'); return false; /free pony!/a
/div
div style=-webkit-border-image: url(icon://file.type) 7 7 8 8 repeat
repeat; width:200px; height:20px; border:1px;
a style=color:A; href=# onclick=alert('AHAR! You have App XXX
installed! How embarassing for you!'); return false; /free pony!/a
/div
However this is a bit of a stretch. You could just as easily trick people
into telling you what applications they have installed through some sort of
interactive content, or simply by asking.
This implies a constraint that all icons (including unknown and missing
file) have to be the same size, which may not match the native look of all
operating environments. Probing file existence may also be doable via a
timing attack, but I am not sure that is solvable.
I'm not sure why you believe that the icons must be the same size. The web
application should not know anything about the icon displayed to the user
other than the URI it used to display it. If this is the case, then
filesystem probing won't occur. Can you give me an example of how one would
probe file existence of an icon URI? The only thing I can think of is if an
application used an icon URI with an arbitrary file path that whose
existence is probable and simply got the user to confirm that an icon (or a
pixel/color) is shown somehow.
Perhaps icons for specific existing files (rather than a file type) should
be retrieved using a File object rather than a path. If the Web app has a
File object then it already has access to the contents of the file, so there
is no probing risk. You could even give it access to the bitmap of the icon
in such a case (for example by making it usable on the canvas without
tainting).
How would the syntax work for img src=? / tags. Isn't the point that we
don't want the web application to have access to the contents of the file?
How does it obtain the File object? Wouldn't it have to probe for the File
object it wants? I'm not very
Re: Steps to creating a browser standard for the moz-icon:// scheme
Thanks again for the feedback! 2010/1/27 Lachlan Hunt lachlan.h...@lachy.id.au Pierre-Antoine LaFayette wrote: The actual use case that triggered my want to have this was the FTP and file:// URI directory listings pages in Chromium. They currently are quite bland and without icons, as may be true for other browsers. Opera doesn't have icons for files, i think Safari uses 2 stock icons for folders and files. Firefox' equivalent pages use the moz-icon scheme and have the platform specific icons. Makes for very nice directory listing pages. OK, and I suppose the standard directory listing pages that Apache generates could also make use of them. It wasn't clear from your original mail that this was just about file type icons, based on the file extension. You also mentioned: stock-image is of the format: stock/icon-name icon-name is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'. It's not clear what the use cases for these are, but for these, it does seem like we would need to define a common set of icons that are available, unlike the file type icons that can load the system's associated icon. So Mozilla has special stock image identifiers, e.g. *moz-icon://stock*/tab-new?size=menu, that I believe return themed icons. I'm not entirely sure what all the options are. There doesn't seem to be documentation for these, it is likely that it is something mostly intended for internal use. I've been thinking that including something like this would not be reasonable as we probably won't be able to agree on some set of stock icons and sizes or even simply which identifiers should be included. E.g. endless variants of: Do we really need separate icons for 'ok' and 'yes' ? Plus all Browsers have their own UIs and themes and as such have different icon sets. Have you considered using the existing about: URI scheme for this? This scheme is in the process of being standardised, and it is possible for specs to define URIs using it, which are then meant for resolving in application/platform specific ways. The only thing is that about URIs are more for providing users information (hence the name about) and perhaps offering configuration options. Such URIs have commonly been used by web browsers for providing access to built-in functionality, such as application information, preferences, settings, or easter eggs While it would be nice to piggy-back on the about: scheme, it does not seem appropriate. An icon: URI scheme is intuitive and concise. I think the only about: URL that Browsers make web accessible is about:blank (and about:mozilla in FF). You can have about:memory in an anchor tag in Chromium for example. Not that making about:icon web accessible would be that big of a deal but it may violate some design principles, at least on the Chromium side. Adam, could you provide your thoughts on using about:icon? See the draft here. http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt The important part is defined in section 5, which has significant amendments described here, which have yet to be integrated into the draft. http://lists.w3.org/Archives/Public/public-html/2009Sep/0755.html http://lists.w3.org/Archives/Public/public-html/2009Sep/0767.html You could write a spec to define an about:icon URI to work like this like, e.g. about:icon?html;32 or about:icon?ext=htmlsize=32 (though, I think being shorter and avoiding '' is better, so authors don't have to bother escaping it in their HTML) I like the shorter syntax as well. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 27, 2010, at 6:00 AM, Pierre-Antoine LaFayette wrote: I'm not sure why you believe that the icons must be the same size. Because you can get the width and height of an img element without any security checks. Even if the width and height properties of HTMLIamgeElement did not expose this (and they do), examining the layout would expose it. The web application should not know anything about the icon displayed to the user other than the URI it used to display it. If this is the case, then filesystem probing won't occur. Can you give me an example of how one would probe file existence of an icon URI? The only thing I can think of is if an application used an icon URI with an arbitrary file path that whose existence is probable and simply got the user to confirm that an icon (or a pixel/color) is shown somehow. Perhaps icons for specific existing files (rather than a file type) should be retrieved using a File object rather than a path. If the Web app has a File object then it already has access to the contents of the file, so there is no probing risk. You could even give it access to the bitmap of the icon in such a case (for example by making it usable on the canvas without tainting). How would the syntax work for img src=? / tags. Isn't the point that we don't want the web application to have access to the contents of the file? How does it obtain the File object? Wouldn't it have to probe for the File object it wants? I'm not very familiar with the File object so if you could elaborate it would be greatly appreciated. You get a File object through a file being explicitly selected by the user, via input type=file. There is no opportunity for any kind of probing attack. My suggestion is that you could get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. Alternately, the File object could give you an icon: URL that specifically identifies that file's icon. This is safer than letting Web applications get the icon for any file they can guess the path to. For the use of paths in icon URIs, I see it as not really useful for web applications but more for Browsers (FTP and file:// directory listings) and possibly user created local HTML pages. There's no need for interoperability in mechanisms that are only needed for features that are built-in to the browser. And I note that it's clearly not needed for FTP directory listings - you don't actually want such files to map to a real file path. The path thing is also a poor fit for operating systems that do not have a user-visible concept of file paths, such as iPhone OS. It could lead to writing inappropriately platform-dependent code given the path format differences and filesystem layout differences among operating systems. True. That is why I imagine that web applications would be using the icon:extension syntax (and maybe a Browser specific stock image syntax) whereas Browsers and local HTML pages would benefit from the file path syntax. I don't think there is a need to standardize features solely for the benefit of browsers and local HTML pages, particularly if they may be a security risk when used in remote Web pages. Regards, Maciej
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Wed, Jan 27, 2010 at 11:44 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 27, 2010, at 6:00 AM, Pierre-Antoine LaFayette wrote: I'm not sure why you believe that the icons must be the same size. Because you can get the width and height of an img element without any security checks. Even if the width and height properties of HTMLIamgeElement did not expose this (and they do), examining the layout would expose it. The web application should not know anything about the icon displayed to the user other than the URI it used to display it. If this is the case, then filesystem probing won't occur. Can you give me an example of how one would probe file existence of an icon URI? The only thing I can think of is if an application used an icon URI with an arbitrary file path that whose existence is probable and simply got the user to confirm that an icon (or a pixel/color) is shown somehow. Perhaps icons for specific existing files (rather than a file type) should be retrieved using a File object rather than a path. If the Web app has a File object then it already has access to the contents of the file, so there is no probing risk. You could even give it access to the bitmap of the icon in such a case (for example by making it usable on the canvas without tainting). How would the syntax work for img src=? / tags. Isn't the point that we don't want the web application to have access to the contents of the file? How does it obtain the File object? Wouldn't it have to probe for the File object it wants? I'm not very familiar with the File object so if you could elaborate it would be greatly appreciated. You get a File object through a file being explicitly selected by the user, via input type=file. There is no opportunity for any kind of probing attack. My suggestion is that you could get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. Alternately, the File object could give you an icon: URL that specifically identifies that file's icon. This is safer than letting Web applications get the icon for any file they can guess the path to. For the use of paths in icon URIs, I see it as not really useful for web applications but more for Browsers (FTP and file:// directory listings) and possibly user created local HTML pages. There's no need for interoperability in mechanisms that are only needed for features that are built-in to the browser. And I note that it's clearly not needed for FTP directory listings - you don't actually want such files to map to a real file path. The path thing is also a poor fit for operating systems that do not have a user-visible concept of file paths, such as iPhone OS. It could lead to writing inappropriately platform-dependent code given the path format differences and filesystem layout differences among operating systems. True. That is why I imagine that web applications would be using the icon:extension syntax (and maybe a Browser specific stock image syntax) whereas Browsers and local HTML pages would benefit from the file path syntax. I don't think there is a need to standardize features solely for the benefit of browsers and local HTML pages, particularly if they may be a security risk when used in remote Web pages. I agree with Maciej. I have a hard time seeing a use case that doesn't originate in File objects, so being able to get the icon directly there seems like a safer way to go. / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Thu, Jan 28, 2010 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote: I agree with Maciej. I have a hard time seeing a use case that doesn't originate in File objects, so being able to get the icon directly there seems like a safer way to go. It can still expose which application the user has handling that file type, if the icon data is somehow exposed via canvas.drawImage or whatever. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Wed, Jan 27, 2010 at 6:26 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jan 28, 2010 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote: I agree with Maciej. I have a hard time seeing a use case that doesn't originate in File objects, so being able to get the icon directly there seems like a safer way to go. It can still expose which application the user has handling that file type, if the icon data is somehow exposed via canvas.drawImage or whatever. Indeed. I think we should make these urls never be considered same-origin as any other origin. Thus a canvas would always get its taint bit set if an icon is drawn. We should also return some default-sized icon for unknown types, to make it somewhat harder to detect when no application is installed to handle a particular file type. That, in combination with the fact that pages only get access to icons for files where the user has exposed the full file contents to the page (through drag'n'drop or input type=file), makes me much less worried about privacy leaks. There's still some risk of privacy leak though, so i'm all ears if others have further ideas or in general don't think this is safe enough. / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
On 1/27/10 9:32 PM, Jonas Sicking wrote: Indeed. I think we should make these urls never be considered same-origin as any other origin. Thus a canvas would always get its taint bit set if an icon is drawn. Note that this is effectively the case in Gecko (since -moz-icon URIs have no host, so never test equal to anything else in terms of origin). -Boris
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. Chromium currently has an internal scheme (chrome://fileicon/path) that it is using for internal HTML pages and Mozilla's moz-icon scheme is already exposed to web content. I am not sure if other browsers have similar schemes for providing icon resources internally. I am working on the Internet Draft for this and will be seeking feedback soon enough. If anyone has any thoughts on security issues, it would be most welcomed as a thorough security analysis is required for the draft. Thanks. 2010/1/26 Adam Barth w...@adambarth.com On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. To gain an interoperability benefit, we would presumably need to define the set of icons available, right? Chromium currently has an internal scheme (chrome://fileicon/path) that it is using for internal HTML pages and Mozilla's moz-icon scheme is already exposed to web content. I am not sure if other browsers have similar schemes for providing icon resources internally. I am working on the Internet Draft for this and will be seeking feedback soon enough. If anyone has any thoughts on security issues, it would be most welcomed as a thorough security analysis is required for the draft. I would recommend not using // in URLs of this scheme unless they have an authority component. It is better for them not to look like a hierarchical URI in that case. Regards, Maciej Thanks. 2010/1/26 Adam Barth w...@adambarth.com On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam -- Pierre.
Re: Steps to creating a browser standard for the moz-icon:// scheme
Personally, I think this would be useful. The way to do this is to register the URI scheme on this page: http://www.iana.org/assignments/uri-schemes.html You can find the instructions for registering a URI scheme here: http://www.rfc-editor.org/rfc/rfc4395.txt I haven't read that document in a while, but as I recall, the first step is writing an Internet-Draft that describes how the URI scheme works: http://www.ietf.org/ietf-ftp/1id-guidelines.html Here's an example Internet-Draft that defines the about scheme (as in about:blank or about:config): http://tools.ietf.org/html/draft-holsten-about-uri-scheme Let me know if you need help with the mechanics of the process. Adam On Sun, Jan 24, 2010 at 2:42 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Hi, I'm doing some development on the Chromium project and have been in the discussion with Chromium developers regarding the possibility of adding a new web scheme for requesting platform icons.. This idea was inspired by Mozilla's moz-icon:// URI scheme which works as such: What *is* a moz-icon URI you ask? Well, it has the following syntax: moz-icon://[file-uri | file-with-extension | stock-image]? ['?'[parameter-value-pairs]] file-uri is a legal file: URI spec. You only need to specify a file: URI inside the icon if the file you want the icon for actually exists. file-with-extension is any filename with an extension, e.g. dummy.html. If the file you want an icon for isn't known to exist, you can omit the file URI, and just place a dummy file name with the extension or content type you want: moz-icon://dummy.html. stock-image is of the format: stock/icon-name icon-name is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'. XXXcaa Should these considered platform dependent or can we share and document them? Legal parameter value pairs are listed below: Parameter: size Values: [integer | button | toolbar | toolbarsmall | menu | dialog] Description: If integer, this is the desired size in square pixels of the icon Else, use the OS default for the specified keyword context. Parameter: state Values: [normal | disabled] Description: The state of the icon. Parameter: contentType Values: mime-type Description: The mime type we want an icon for. This is ignored by stock images. So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. I would like to know whether this idea would be something that would warrant the development of an open standard and, if so, how I would go about proposing such a scheme. Thanks for your time. -- Pierre.
