Exposing icons to web pages with chrome://fileicon
Pierre-Antoine LaFayette
--
Pierre.
Brett Wilson
We can't expose chrome: URLs to web pages for security reasons
("chrome:" has special security rules). We could expose a different
scheme for this type of thing if we wanted. It seems nice but a low
priority to me.
Brett
Pierre-Antoine LaFayette
We could expose a different scheme for this type of thing if we wanted. It seems nice but a low
priority to me.
--
Pierre.
Brett Wilson
<pierre.l...@gmail.com> wrote:
>> We could expose a different scheme for this type of thing if we wanted. It
>> seems nice but a low
>>
>> priority to me.
>
> Well I'd be the one implementing it :) Just wanted confirmation that this
> approach would be okay. Say a chrome-icon:// scheme that works exactly like
> moz-icon? I believe this new scheme would provide a nicer solution
> to crbug.com/24421 than IPC from the webkit glue layer requesting icon data
> from the Browser.
I'm not sur ehow the mozilla one works. Does it just go off the
extension of the file? I think you can implement that in a reasonable
way, although you have to be careful not to block the network thread
on the file I/O or system calls. If this actually needs to go to disk,
there are a bunch of security checks you will have to do very
carefully since we don't want regular web pages to request this for
random local files.
Brett
Pierre-Antoine LaFayette
// (1) file://<some valid platform specific file url> // (2) //<some dummy file with an extension> // (3) stock/<icon-identifier>
--
Pierre.
Pierre-Antoine LaFayette
/** * nsIIconURI * * This interface derives from nsIURI, to provide additional information * about moz-icon URIs. * * 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. */
--
Pierre.
Adam Barth
extensions to the web platform, especially if they require new magical
schemes.
The proper path forward for this feature is to create an open standard
that every browser can implement and put it through the W3C or IETF
process.
Adam
On Sat, Jan 23, 2010 at 5:49 PM, Pierre-Antoine LaFayette
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
TAMURA, Kent
I'm aware there is a similar internal URL scheme in Chromium, namely chrome://fileicon/<path>, that is used in DOM UI pages. Why could we not simply have something like moz-icon, that takes simply an extension and a size rather than the file path and make it web accessible? This way web developers can access the platform icons in their HTML pages.
I have a similar bug, http://crbug.com/13225 , and I'm implementing new IPC messages because exposing icons via URL is dangerous.
TAMURA Kent
Software Engineer, Google
James Bliss
> I'm afraid malicious web pages can steal platform icons. They are not free
> basically.
Can someone clarify for the new guy why it's dangerous for a malicious
page to have access to platform-specific images?
-- James
Glen Murphy
>> basically.
>
> Can someone clarify for the new guy why it's dangerous for a malicious
> page to have access to platform-specific images?
In this case it would be able to tell what software you have installed
by figuring out what shows up for files associated with those
applications.
Pierre-Antoine LaFayette
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
--
Pierre.
Glen Murphy
> the web page? The icon data isn't going out to the web server it is simply
> being rendered in the browser. Am I missing something?
I'm not aware of the full extent of the security worries that the
others in the thread were referring to (and I am definitely not a
security person), but you do have to do things like make sure that
when the image is written to a canvas, that canvas is marked as
read-only so that getImageData can't read it (like what happens for
cross domain images are today), so it is another layer of checks you
have to add.
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>
As I said though, there are probably other attacks that people are
worried about, I was just pointing out why exposing the icons could be
bad.
Pierre-Antoine LaFayette
--
Pierre.