300289 - Feature: UI to blacklist sites for install

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Aaron Slunt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+

The "Allowed Sites - Software Installation" dialog
(Tools->Preferences->Content->Allowed Sites (to install software) will allow
subdomains of blah.com to install software. If a user enters blah.com to install
software from, any subdomains (xxx.blah.com) has the same privileges as blah.com
itself, to install anything. The user is not told about this happening, and this
could lead to a user thinking they're installing software off a whitelisted site
(just the domain itself), when in reality they're installing it off the
subdomain and very well could get screwed over. There are things I think should
be happening here:

1) Tell the user that by entering xxx.com, they're allowing all subdomains to be
whitelisted as well.
2) Make a user use * if they want to allow all subdomains through.

Either way, a user's trust could be taken advantage here, when the whitelist
should be trying its best to make sure that doesn't happen.

Summary: user adds a domain to the whitelist, all subdomains of this domain are
automatically whitelisted, and the user is never told about it in any way.

Reproducible: Always

Steps to Reproduce:
1.Add mozdev.org to your whitelist
2.Notice how all subdomains of mozdev.org are allowed to install extensions.
3.

Comment 1

[Anders Conbere]

This can only occur if the user enters a top level domain into the Whitelist by
hand.  Adding a site from the whitelist popup dialog when attempting an install
only adds the single site and not sub-domains.  I believe that the current
behavior is exactly what should be expected when entering a top level domain
into the whitelist.

test case
http://www.bytecave.net/
http://test.bytecave.net/

Anders

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #1)
> Adding a site from the whitelist popup dialog when attempting an install
> only adds the single site and not sub-domains.
I assume that method also uses nsIPermissionManager. If so, it will allow
subdomains of the current domain to install extensions. sub.www.bytecave.net can
install extensions in your testcase. The two domains you mentioned are not
subdomains of each other.

Comment 3

[Daniel Veditz [:dveditz]]

Semantic nits: the whitelist allows sub-domains of mozdev.org to *ask* if you
want to install software. You can always say no. It's rare that a trustworthy
domain will have an abusive sub-domain. For instance, all the mozdev projects
have you click on a link to get an install -- already an explicit user request.
When there is an abusive subdomain it's no different than in the days before the
whitelist (e.g. Netscape 4.0 through 7.2) which was still perfectly safe but
allowed spammy sites to annoy you with modal prompts.

The backend supports blocking sites, it's not used only because no one came up
with a decent UI for it (and also because so far not a single example of an
abusive subdomain of a commonly trusted domain has been found). If this turns
into a real problem we could do something like add a "Never for this site"
button to the confirmation dialog.

But this is a hypothetical problem. In the real world addons.mozilla.org is the
only whitelisted site and the numbers of potential victims who whitelist any
other site are small. An attacker is more likely to just walk people through
bypassing the whitelist to get some goodies.

Comment 4

[Tracy Walker [:tracy]]

dan, should this be confirmed or won't fix?

Comment 5

[Gabriel Sjoberg]

Changing this to an enhancement request.

-1 from me.

Comment 6

[Aaron Slunt]

No way this is an enhancement.

Comment 7

[Daniel Veditz [:dveditz]]

We are not going to duplicate a permission manager just for installs, and the
current permission manager works this way on purpose. In practice a malicious
sub-domain of a trusted domain is rare, and even currently users can cancel the
install and then un-whitelist the super-domain that turned out to be
untrustworthy. We can morph this into a feature request or we can WONTFIX it.

In rare cases a sub-domain of a site whitelisted for install might abuse that
ability and need to be blocked. In practice this might never happen though,
unless people are whitelisting sites by hand and being too general.

We could add a "block" button to the current site management dialog
--and/or--
We could add a "prevent installs from this site" checkbox to the install
confirmation dialog (so that when a subdomain starts annoying you, you can turn
it off for future annoyance right there as you click "cancel").

If we do the RFE that asks for the ability to allow one-time installs from the
infobar then this becomes even less important than it already is, because
hopefully that will lead to very very few sites ever being whitelisted.

Assigning to Beltzner for UI design, but we should hold off until after we do
the one-time-installs feature first and see if we still want it after that.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

This is on my radar. I'll try to whip something up.

(dveditz: the rfe you're talking about is bug 252830, right?)

Comment 9

[Aaron Slunt]

beltzner, any update?

Comment 10

[Robert Strong (they/them - no direct email)]

btw: this doesn't touch any extension manager code... it does touch permissions manager, preference ui, and possibly xpinstall though I believe that already has this functionality.

Comment 11

[Aaron Slunt]

Beltzner, have you came up with anything? If not I'll just close it, as stated here since the user is asked beforehand if they want to install something, then it's entirely their fault if they screw up.

God I as a clutz a few years ago X_X

Comment 12

[Dave Townsend [:mossop]]

Beltzner tells me he has no further plans here. While we still have a white list, for most sites people will be using the allow one install button which makes this feature unnecessary I think.