# Images with file:/// src attribute not showing up in IE7



## nathanb (Aug 6, 2007)

Hey,

I have a plug-in for Internet Explorer that displays images in certain web pages. To save bandwidth, the image is stored locally (distributed with the plug-in). I dynamically write an img tag with the src attribute set to file:///x:/path/to/image.gif. This works fine in IE6, but in IE7 all I get is the image placeholder. It's not a broken image, it's just like it's refusing to load the image entirely.

Am I doing something wrong? The element I'm writing looks like this:

```
[IMG]file:///C:/Documents%20and%20Settings/Nathan/Application%20Data/IEPlugin/skin/image.gif[/IMG]
```
The code to insert it looks like this:

```
var image = doc.createElement('img');
image.setAttribute('src', getIconURL());
image.setAttribute('border', '0');

target.appendChild(image);
```
getIconURL just does some magic to find the current user's application data folder and then returns the url you see above (or whatever URL is appropriate for the current user's computer, of course).

Help appreciated 
Nathan


----------



## tomdkat (May 6, 2006)

I've seen this kind of behavior in other browsers as well. I think Opera behaved for me this way once. I uploaded a web page to the server that accidentally referenced a file on my local file system and Opera didn't display the image.

Sorry I can't be of any help.

Peace...


----------



## nathanb (Aug 6, 2007)

It may be a "security feature" to keep remote pages from snooping around on a user's hard drive, but it's not like what I'm trying to do is a security risk in any way. I would definitely appreciate any suggestions about how to fix this, as it's an important piece of functionality.

Nathan


----------



## Shadow2531 (Apr 30, 2001)

The browser definitely shouldn't allow you to embed local images on a remote page by default.

What happens if you add the site to the trusted zone for IE? Does that help?

Also, for IE, a raw, backslashed windows path instead of a file URI might work.

On a side note, for future reference, the file protocol has different forms.

For example, for localhost, it can be both file:/// or file://localhost/
Whatever format you use, you want to make sure it works in all UAs you plan to support. (This goes for plugins functions that compute a base URI from document.location also.)


----------



## nathanb (Aug 6, 2007)

> The browser definitely shouldn't allow you to embed local images on a remote page by default.
Why? I can't see the security risk. It's not like the image is being sent back to the remote server.

> What happens if you add the site to the trusted zone for IE? Does that help?
That does help, but since the add-on can add this image to any page, then that would mean the entire web would have to be in the trusted zone...obviously not a good idea.

> Also, for IE, a raw, backslashed windows path instead of a file URI might work.
I'll try that. Since it's an IE plugin, there are no browser compatibility issues.

> For example, for localhost, it can be both file:/// or file://localhost/
This is because, in your second example, it is trying to access the "remote" network path //localhost/ (like typing \\servername\sharename in the Windows Explorer address bar). Hopefully windows is intelligent enough to realize that 127.0.0.1 = loopback and doesn't actually go out to port 139 or whatever and try to connect. But if it doesn't allow a file:/// url, it probably won't allow a network/UNC path either.

> Whatever format you use, you want to make sure it works in all UAs you plan to support.
> (This goes for plugins functions that compute a base URI from document.location also.)
I'm not sure what you mean by this. Could you elaborate? I don't actually get the path using document.location; I do it by resolving %APPDATA% and then appending my own path onto the end (%APPDATA%\IEPlugin\skin\image.gif), then using a regex to switch the path separator chars and slapping a file:/// on the front.


----------



## Shadow2531 (Apr 30, 2001)

nathanb said:


> > The browser definitely shouldn't allow you to embed local images on a remote page by default.
> Why? I can't see the security risk. It's not like the image is being sent back to the remote server.


Here's an example of why it shouldn't be allowed by default.
http://kb.mozillazine.org/Firefox_:_Issues_:_Links_to_Local_Pages_Don't_Work

It can get worse when the image isn't really an image and it exposes some bug.



> > What happens if you add the site to the trusted zone for IE? Does that help?
> That does help, but since the add-on can add this image to any page, then that would mean the entire web would have to be in the trusted zone...obviously not a good idea.


O.K.



> > Also, for IE, a raw, backslashed windows path instead of a file URI might work.
> I'll try that. Since it's an IE plugin, there are no browser compatibility issues.


O.K.



> > For example, for localhost, it can be both file:/// or file://localhost/
> This is because, in your second example, it is trying to access the "remote" network path //localhost/


file://localhost/ and file://emptystring/ (file:///) are equivalent. "localhost" is a special case, which means "the machine from which the URL is being interpreted" and not a remote host.
file://host/, file://///host/ for example are the same also.

So, *if* you're computing a base URL from a file URI, you might get different types of the same thing and you might want to handle that. Many browser plugins use document.location for computing a base URL and it bites them when they only handle file:/// because browsers differ in file URI methods that they use. But, the file URI differences can spring up in other URI based values.

Since you're just doing stuff for IE, you probably won't have to worry about this, but for future references...


----------



## nathanb (Aug 6, 2007)

>Here's an example of why it shouldn't be allowed by default.
>http://kb.mozillazine.org/Firefox_:_Issues_:_Links_to_Local_Pages_Don't_Work

# Allowing sites to detect your operating system by checking default installation paths 
This is pointless, as IE sends the operating system version as part of the user-agent string. Why go to the trouble of linking a local file when you can just check the HTTP header?

# Allowing sites to exploit system vulnerabilities (e.g., C:\con\con in Windows 95/98)
This is a slightly better argument, but it's annoying that web browsers have to be hobbled because of vulnerabilities introduced in a poorly-designed OS "feature".

# Allowing sites to detect browser preferences or read sensitive data
In this case I don't think sensitive data could be read, but who knows what sort of security vulnerabilities are out there? I wouldn't have guessed that you could get adware from opening a jpeg either, but the Microsoft GDI+ bug allowed exactly that to happen (as you mention above).

I realize that it's not the fault of anyone here that IE behaves this way, but it makes me upset when people say "this feature is a security vulnerability" and that in itself is enough reason to restrict the behavior of well-meaning plugins. 

So now that we've established that what I'm trying to do is a BAD THING, is there any way for me to do it? Or do I have to waste both the user's bandwidth and ours by using a remote URL each time?


----------



## Shadow2531 (Apr 30, 2001)

> So now that we've established that what I'm trying to do is a BAD THING


There should be a way to do it for IE at least with activeX or vbscript or something, if not js alone. Maybe load a java applet t hat displays the pics.

You could (if forced to) run some tiny server to serve the pics. Then they'd load, but that's a last resort.

If all you need to do is display the pics, the Windows Media Plugin will display pictures even from local files. You might need to use scripting for the WMP plugin to load the local pictures though.

Anyway, see http://msdn2.microsoft.com/en-us/library/ms649488.aspx
I think you can add your process to some key so IE will allow it.


----------



## nathanb (Aug 6, 2007)

> I think you can add your process to some key so IE will allow it.
That looked promising, but I think it's only for applications hosting the web browser control, not for plug-ins (I tried adding the name of the .dll we install as the process name, and it didn't help). 

> Also, for IE, a raw, backslashed windows path instead of a file URI might work.
By the way, I tried this, and it still didn't work. Some debugging indicates that IE actually converts the raw path to a file:/// url behind the scenes.

For the record, this IE add-on is a port of a Firefox extension. Getting the images to display in Firefox using chrome:// urls is incredibly easy. I'm sure I'm preaching to the choir here, but I can't wait for the day when a browser that is much better than IE has the dominant market share and poor developers like me don't have to write code for such crufty platforms 

Thanks for your suggestions. We're trying to be as lightweight as possible, so doing things like using the WMP plugin or starting up our own small server (and how much of a security risk would THAT be? One buffer overflow error on our part and we're on the front page of secunia.com) are not really in the picture unless there's no other options.

Much appreciated,
Nathan


----------



## nathanb (Aug 6, 2007)

I think your comments may have indirectly pointed at a solution, Shadow2531. I was looking through the FeatureControl registry key, and I found the FEATURE_LOCALMACHINE_LOCKDOWN key. I tried adding the name of our .dll to that key with a DWORD value of zero, and it worked.

If we write this key in our installer, hopefully that will prevent the problem from appearing.

Thanks for helping point me in the right direction,
Nathan


----------

