286499 - users misuse host wildcards (*.) in permissions

Status: RESOLVED DUPLICATE of bug 259445

(Core :: Networking: Cookies, enhancement)

Description

[Dan M]

Options/Preferences Dialog, Cookies (or Images, or Popup windows), Exceptions.
Type in by hand a host that's permitted to set cookies. *We* all understand that
subdomains are also allowed, so yahoo.com gives permission to all of yahoo.com.
It seems many users with just slightly too much knowledge do not understand,
typing in *.yahoo.com, instead. See for example the opening comment of bug
286232. In fact the host *.yahoo.com matches no real domain, and this entry has
no real effect at all on your permissions. I've seen many people do this; I
think it's a common misunderstanding.

Yes, this is user error. But it seems to me we should account for it. Many
people have studiously entered host permissions that have no effect, and give no
direct indication of their lack of efficacy. Mozillazine forum complaints of
Yahoo Mail objecting that Firefox doesn't accept cookies are not uncommon. I
wonder how many of those are because of this misunderstanding?

I see two choices: immediately strip off any leading *. entered in the dialog,
or store it with the pointless wildcard but strip it off when building the hash
table. I think the former would be initially bewildering, but also less
misleading. After all, keeping and displaying the leading *. incorrectly implies
that (*.yahoo.com and yahoo.com) are different. Most users knowledgeable enough
to add the *. are knowledgeable enough to figure out what it means when we keep
dropping it. I lean toward stripping off the leading *. immediately. (We might
also do both, thereby correcting legacy users' permissions files.)

Comment 1

[[e-mail]]

Agreed. We could also add text in the permissions window to the effect of
wildcards being useless. One sentence should do the trick. I hope at least our
help docs explain it...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Or we could complain on invalid hostnames (which this is, no?) and suggest to
the user that if they're trying to have a domain and all subdomains whitelisted
they should just whitelist the domain.... (this last clause shows why I don't
design UI, eh?  ;) )

Comment 3

[Mike Connor [:mconnor]]

No.  If the user is using a wildcard, their intention is pretty clear, we should
just do it, and _possibly_ include a sentence explaining it.  I'm not even sure
if we need to go that far, since users actually adding exceptions are almost by
definition saavy enough to understand after the first time.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, I'll buy that for wildcards.

I still think that after wildcard-stripping we could use hostname-validity
checking... but I guess that's food for another bug.  ;)

Comment 5

[[e-mail]]

http://lxr.mozilla.org/mozilla/source/browser/components/preferences/permissions.js#106

that's where the wildcard stripping needs to go.

Comment 6

[Darin Fisher]

How do you validate a hostname?  You should be careful about making assumptions
about what the hostname of a URL looks like.  It may not be a name that is
resolved using DNS.

Comment 7

[benc]

We've dealt with a lot of these issues in "No Proxy For" already.

In short, the back-end filtering does not use strings with a leading "*".

However, the front end allows it, and the "*" is removed when the pref string is
parsed into an array. 

I think you want a front-end that allows users to enter something sensible, but
then do some minor fix-ups to store the values in a way that makes sense.

I would prefer that the users enter a domain string, and be given a menu/radio
selector that says: [hostname-only | domain-only | domain & sub-domains].

FQDN validation can be done, I wrote a JS function that does it, but in some
places, like this, it might be better to let people enter whatever they want.
Sometimes the OS allows things to slip through that don't make a lot of sense.