User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/188.8.131.52 Safari/532.0
.local is the TLD used by Rendezvous/Bonjour/mDNS. We (Chromium) are thinking about adding .local to our eTLD list because we use that list to detect when the user is entering a hostname vs a search.
Firstly, we don't like to fork this list. Secondly, we're wondering about unintended consequences since .local isn't quite like the other entries in the file.
Created attachment 397775 [details] [diff] [review]
Patch to add .local to Mozilla's eTLD list
FWIW, I think this change is OK. It means that an intranet machine at foo.local will not be able to read/write cookies for "local", which seems like the right outcome. I can't think of any other consequences off the top of my head.
The default cookie rule for unknown TLDs is one dot - i.e. cookies can be set for .wibble.somethingnew but not for .somethingnew. So the cookie behaviour for .local would not change.
We probably need a list of things people are using the list for, so that we can better assess the possible consequences of additions like this one. I mean, we at Mozilla know what we are using it for, but the use you name is a new one I hadn't heard of before.
Are you able to provide a list of things Chromium is using the Public Suffix List for?
The two uses I'm aware of are:
* Restricting cookie usage (like Firefox)
* Determining "search" versus "navigation" for inputs in the Omnibox
We might also use this when determining which hostnames are part of the same TLD+1 for things like same-origin checks or the "most-visited" set of sites? I am clueless, that might be totally wrong and even nonsensical.
I don't know offhand whether our cookie code has a default rule of "one dot" like yours. I'm not sure it does.
The net result of the above is that Chromium always benefits from greater specificity. For example, changing "*.foo" to "a.foo b.foo" lets us be more precise in our Omnibox behavior. (However, not many changes of this sort have landed in the past because here upstream we've been told that the former syntax is preferable for its simplicity, since Mozilla gains no benefit from this.)
I know there are thoughts of doing a combined search/address field for Firefox in the 4.0 timeframe; if that comes to fruition you will probably also benefit from this kind of detail.
I cannot think of a downside to making this change for either Mozilla or Chromium except that a user purposefully trying to search for "foo.local" by typing it and hitting enter will be unhappy. This seems like a highly unlikely use case.
Re: adding .local, I'd like to check with a few more people. CCing dwitte and dbaron.
The one dot rule has been the default cookie rule for many, many years, and it's also the documented fallback behaviour for the PSL. (Or will be once I've pushed the current documentation update - bug 514384!) So I would hope and expect that the Chromium code does that.
The list is maintained for the benefit of all; greater specificity is fine, as long as it does not lead to the list being incorrect. Please feel free to submit changes of that nature.
After all, if someone wants a laxer version of the list, as long as there is no entry for simply
then they can always convert
and that would be valid.
(In reply to comment #4)
> I don't know offhand whether our cookie code has a default rule of "one dot"
> like yours. I'm not sure it does.
It's not actually our cookie code that enforces that. Our eTLD service, when asked about a host for which no entry on the list applies, will use the TLD. So cookies, and everything else, should do the right thing. Do you handle this case differently? (I'm guessing you do, otherwise we wouldn't be talking about .local.)
> The net result of the above is that Chromium always benefits from greater
> specificity. For example, changing "*.foo" to "a.foo b.foo" lets us be more
> precise in our Omnibox behavior. (However, not many changes of this sort have
> landed in the past because here upstream we've been told that the former syntax
> is preferable for its simplicity, since Mozilla gains no benefit from this.)
Hmm. We should gain a benefit, though, right? If we used "*.foo" then we'd disallow domain cookies for ".c.foo", which would be wrong, and would likely break the site. Since the point of the list is to get things right, we should endeavour to make it accurate. (Am I missing something?)
Anyway, to the point, I don't have an objection to adding .local. Or to Chromium assuming a TLD as described above. ;)
(In reply to comment #6)
> (In reply to comment #4)
> > I don't know offhand whether our cookie code has a default rule of "one dot"
> > like yours. I'm not sure it does.
> It's not actually our cookie code that enforces that. Our eTLD service, when
> asked about a host for which no entry on the list applies, will use the TLD. So
> cookies, and everything else, should do the right thing. Do you handle this
> case differently? (I'm guessing you do, otherwise we wouldn't be talking about
We use different rules when calling from the address bar code (where we must not assume TLDs where we don't have rules to back them up, or users could never enter search queries that looked vaguely like hostnames) and the cookie code. Perhaps our behavior for cookies is the same as yours. Like I said, I haven't looked into it closely anytime recently so I can't recall offhand.
As for the benefit of a narrower list, I didn't think of that. I think you're right (although this is likely a rare case). I suppose one low-priority task would be for someone to audit all the registries for the current list...
Comment on attachment 397775 [details] [diff] [review]
(In reply to comment #9)
For future reference, in hg, when you land patches for other people, the preferred way of attributing the patch to them is using the -u option rather than giving the author in the commit message. That is:
hg ci -u"Adam Langley <firstname.lastname@example.org>" -m"Bug 513834 - add "local" to Public Suffix List. r=gerv." ...files...
hg ci -m"Bug 513834 - add "local" to Public Suffix List. Patch by Adam Langley, email@example.com; r=gerv." ...files...
Nominating for branches. Companion bug 513834. Justification: keeping public suffix list in sync across branches (this change should have no effect on Firefox itself).
Comment on attachment 397775 [details] [diff] [review]
Approved for 184.108.40.206 and 220.127.116.11, a=dveditz for release-drivers
Checked in on all branches.
Checking in netwerk/dns/src/effective_tld_names.dat;
/cvsroot/mozilla/netwerk/dns/src/effective_tld_names.dat,v <-- effective_tld_names.dat
new revision: 1.11; previous revision: 1.10
Verified in source for 1.9.1 and 1.9.0. Nothing else for QA to do here.