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.lafayette@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=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.
>



-- 
Pierre.