- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 3 Feb 2010 11:25:30 -0800
- To: Pierre-Antoine LaFayette <pierre.lafayette@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>
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.lafayette@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.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. >
Received on Wednesday, 3 February 2010 19:26:27 UTC