Because the whitelist checks the site that the link was clicked on, and not the site the add-on is hosted on, and as addons.mozilla.org is in the whitelist by default, if I set the homepage for my account on addons.mozilla.org to point at an xpi, users will not get a whitelist alert if they click on the link in my developer profile there. They still get an alert asking if they want to install the add-on from wherever it's hosted, so it's no big deal I don't think - the whitelist is designed to prevent spamming the user with install dialogs, and I can't execute any javascipt or anything to do that, but I thought this bug was worth filing anyway. Any comments? Oh, you can also hide the xpi file extension eg. http://justcameron.com/temp/installxpi/ and there's no problems there.

This is not a security bug in Firefox. Presumably the trusted site (addons in this case) will police its user-created content and enforce some sort of Terms of Service. If not then that site should not be trusted. Should be closed INVALID if this remains a Firefox bug. If you want to turn it into an AMO policy bug then that would make some sense. One obvious solution for AMO would be to have author pages come from a different host than the one actually serving the addon links. Otherwise you've got to police them (which you really do anyway -- what if someone adds the goatse.cx image?).

Rightio, an AMO bug it is. I wasn't really sure about it being a security bug anyway but meh. For the record, external urls aren't policed at all atm.. maybe we'd do something if someone complained, but yeah. I suppose we could do outgoing.mozilla.org/?goingto=http://google.com "You are now leaving a Mozilla page. Please be aware that Mozilla is not responsible for the content of external links, etc. etc. etc." With a patch incoming for Bug 343573, we need to give this some attention. I can already imagine "AMO has not yet published my new version, which promises to be 50 squillion times better, but if you want to be up to date, get it from http://badlink.com"

I thought installTrigger was about preventing drivebys mainly, yeah, though we'll probably get this for free with Remora, given the likelihood of a different site name.

I think we should consider moving AMO to another domain and standardize installations using an installation service on the current domain or services.addons.mozilla.org. Thoughts?

I thought the whitelist only cares about the page that the link is on, not where the link points to? Won't we have the same problem then if we move our installations elsewhere?

Plopping into 5.0.9 for now until we triage into a more specific milestone. I'd like to get to this in the next couple of releases as we'll be doing more and more with external links. Plus, it's blocking HTML implementation. I'm thinking our best solution will be registering a new domain (that I won't mention here, lest someone beat us to it) and have a redirection script there that pulls the URL from a new links table and redirects.

(In reply to comment #8) > I'm thinking our best solution will be registering a new domain And before Wil frowns at me, if we can make sure the whitelist treats services.addons.mozilla.org as a different domain than addons.mozilla.org, we can just use that. (The new domain idea was mainly stemming from needing to host the future developer forums on a different domain, at which point our options would be forums.amo or a new TLD.)

(In reply to comment #9) > (In reply to comment #8) > > I'm thinking our best solution will be registering a new domain > > And before Wil frowns at me, if we can make sure the whitelist treats > services.addons.mozilla.org as a different domain than addons.mozilla.org, we > can just use that. So we'd get a message that says: Firefox prevented this site (services.addons.mozilla.org) from asking you to install software on your computer. That doesn't seem like a great solution - from a user's point of view it sounds like a misconfiguration on mozilla's part and they'll probably just click "allow"

It turns out the whitelist includes subdomains as well, so the redirecter can't even live on *.addons.mozilla.org.

(In reply to comment #11) > It turns out the whitelist includes subdomains as well, so the redirecter can't > even live on *.addons.mozilla.org. So the plan is to find a URL that doesn't sound official and put the redirect script there?

filed bug 523249 for the redirector

This bug should include these fields as well: add-on support URL, user homepages

Comment on attachment 410372 [details] [diff] [review] bouncing external links for Addon.{homepage,support_url} & User.homepage This is alright, except the homepage is shown on the page with the full outgoing.m.o URL instead of what the user entered. Please fix that before commit