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=16&state=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 (イアンフェッティ) <ifette@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 $0.02
>
> 2010/1/31 Maciej Stachowiak <mjs@apple.com>
>
>
>> On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote:
>>
>>
>>
>> 2010/1/29 Ian Fette (イアンフェッティ) <ifette@google.com>
>>
>>> 2010/1/28 Maciej Stachowiak <mjs@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
>>
>>
>


-- 
Pierre.