If one were to visit : http://forums.mozillazine.org/viewtopic.php?t=351130&highlight=spellbound And click the extension link to http://exchangecode.com/spellbound/downloads/spellbound-dev_20060108.xpi for the spellbound extension, one will note that the url that firefox says is trying to install the extension is forums.mozillazine.org not exchangecode.com (assuming you have a blank white list / one that doesn't already have either of these in it). I've setup another example here : http://tgraham.googlepages.com/teset; you'll note again that the URL it says is trying to install the extension is wrong- googlepages.com vs the actual extensionmirror.nl. Whether this has security implications is unclear. I've been unable to work out whether Firefox shows the wrong url - but adds the right one to the extension white list. If this is the case, then the problem appears only visual. However, if it is not the case, then this could potentially be used as an exploit - if user is on page A which they view as being secure and click a extension link actually hosted on page B, it will appear as being on page A - potentially exposing themselves to malicious code. Tested on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4, Windows Vista beta 2.

Good point -- we shouldn't say "www.google.com is trying to install..." when you click a link in Google search results that has been replaced with an XPI -- or worse, go through an open redirect script that resides on www.google.com. dveditz/beltzner, do you know if there's an existing bug report about this issue?

afaik this was an intentional design decission at some point, but oh well.

Yes it was... the whitelist is an anti-annoyance measure, and so it displays the website which is "annoying" you (forums.mozillazine.org), not the actual source of the XPI (which is displayed later in the XPInstall dialog). I don't think this should be security-sensitive.

This is intentional. The url is for the site with the link to the xpi or the code that initiated the install and not the site hosting the xpi. The whitelist prevents sites from displaying the xpinstall dialog by initiating an install and the xpinstall dialog with the countdown is where the url to the xpi is displayed. I agree with bsmedberg that this should not be security sensitive.

Jesse, if you disagree please feel free to reopen and suggest an alternative behavior that better matches user expectation requirements.

Oh, I missed that this is about the infobar rather than the dialog. I don't worry too much about what the infobar says, since it can be spoofed easily ;) At least on the trunk, the dialog gives the full URL of the XPI, and does not give the URL of the referring page.

There are two sites involved, and two completely separate pieces of UI that each show only one of them. forums.mozillazine.org (site 1) is attempting to install software that is stored on exchangecode.com (site 2). Or perhaps forums.mozillazine.org is "recommending/asking that you install". If site 1 is whitelisted the actual install confirmation dialog shows the source of the install package. Maybe this would all be clearer if the two sites were combined in one piece of UI, though presumably the user knows where they are when they click on an install link (not necessarily if it's a framed page). So if you generally trust forum members you can whitelist f.m.o, but you'll still see the actual source site, which is a good thing if some spammer invades and posts links to getspyware.com Why don't we trust the install source site instead? Because hackers of have been known to link to legit but known-vulnerable versions of, for example, ActiveX controls and that's not an area in which we're seeking parity with IE. Think, for example, of the likely success a random evil site might have encouraging users to install one of the old vulnerable versions of AdBlock. Users would think "You know, someone else recommended AdBlock to me earlier, and this one comes from ftp.mozilla.org so it must be OK". No, only the latest AdBlock as recommended by addons.mozilla.org (served over SSL) is OK (as far as we know). Beyond addons.mozilla.org users can add their own trusted sites, and power-users can turn off the whitelisting requirement entirely if they wish. I sure wish we had an allow-once feature to bypass whitelisting. Right now people don't know they can copy the install link and paste it into the location bar (manually trusting the link), so instead they permanently whitelist sites that perhaps don't warrant it.

Allow-once is bug 252830.

Continued, sort of, in bug 358266 comment 1.