This is a minor information leak - a script can determine if a file with some recognized image format exists at a given URL, either on the user's local drive or another site the user has access to, such as inside a firewall. If a file exists at that URL but it is not an image file, this script will not be able to see it. Adding CheckLoadURI to images would fix the local case, however this causes some nasty regressions in Composer and has been postponed indefinitely. The problem is that onLoad handlers for images fire only if an image exists.

What's the composer problem, exactly? /be

Adding CheckLoadURI for images broke the ability to add local images to a page in Composer.

So can't composer hackers fix that lesser bug, rather than causing this greater (for a browser, and taking into account composer's relative market share and other factors like quality) bug to be futured? /be

Even if you think the composer bug that would result from closing this information leak quickly is the greater bug, it's still wrong to leave this bug hanging, and not to involve any composer people. Mitch, can you find someone who could help -- maybe jfrancis? /be

Bug 69070 is the bug for adding checkloaduri to images

It appears Composer needs to be provided the appropriate api's to clue security in. I thought Jesse did that in his patch: http://bugzilla.mozilla.org/ attachment.cgi?id=46183&action=view in bug http://bugzilla.mozilla.org/ show_bug.cgi?id=69070. In comment 23 of that bug he mentions the change: editor/base/nsEditorShell.cpp Added a setAppType call to tell the docshell it's a composer. (Similar to code in mailnews/base/src/nsMsgWindow.cpp.) Tell me what security cruft to put in composer and I'll put it there. If no such cruft exists, that's a bug.

I talked to Mitch about this bug last week when I was in MV. He didn't seem to think this was a problem that needed to be addressed in the MachV timeframe. My understanding is that the fix is actually in nsImageFrame or somewhere outside of mozilla/editor. I have agreed to help Mitch with testing any proposed patches. Mitch--is the most recent patch in bug 69070 the correct patch to tweak to address this bug?

I wonder if this problem is related to bug 148199 (broken images don't redisplay). If image onload isn't fired, that would explain bug 148199, which actually *is* very important to fix for MachV

I think the risk of this fix outweighs the gain, so let's put this off for now. The information leak caused by this bug is not very serious, right?

If the risk isn't very serious, then why don't we open the bug?

It seems pretty clear that there is a Composer bug that should be fixed so that we can do the right thing and CheckLoadURI for images. This should be done sooner rather than later.

The intranet problem can also be fixed by implementing security zones, bug 165531.

I'm beginning to think CheckLoadURI for images is the wrong approach - it only fixes the local drive case, not the intranet case, and I'm trying to move away from CheckLoadURI where possible since it impedes some legitimate uses. One way to fix this problem would be to lie about nonexistent images. According to the Rhino Book, the Image.complete property should be set to true on error, but it is not. I have filed bug 190561 on that. The other part is trickier - we would have to stop throwing onError events and always throw onLoad instead, which would violate the spec, I'm sure. As this is a minor security issue, I have no strong feelings either way - either lie to the DOM that all image loads are successful, or wontfix this bug and maybe work on a Security Zones-type system instead as Heikki suggested. What say you?

Not firing onError events is not exactly acceptable -- people do rely on those for real error handling....

Clearing milestone

We've plugged the local file hole (bug 69070), for remote web images there are just too many ways to detect them.