513834 - eTLD update for .local

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Adam Langley]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/4.0.202.2 Safari/532.0
Build Identifier: 

.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.

Reproducible: Always

Comment 1

[Adam Langley]

Attachment: patch

Patch to add .local to Mozilla's eTLD list

Comment 2

[Peter Kasting]

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.

Comment 3

[Gervase Markham [:gerv]]

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? 

Gerv

Comment 4

[Peter Kasting]

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.

Comment 5

[Gervase Markham [:gerv]]

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

foo

then they can always convert

a.foo
b.foo
c.foo

back into 

*.foo

and that would be valid.

Gerv

Comment 6

[[e-mail]]

(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. ;)

Comment 7

[Peter Kasting]

(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
> .local.)

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 8

[Gervase Markham [:gerv]]

Comment on attachment 397775 [details] [diff] [review]
patch

r=gerv.

Gerv

Comment 9

[Gervase Markham [:gerv]]

http://hg.mozilla.org/mozilla-central/rev/83a484d77b0d

Gerv

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #9)
> http://hg.mozilla.org/mozilla-central/rev/83a484d77b0d

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 <[e-mail]>" -m"Bug 513834  - add "local" to Public Suffix List. r=gerv." ...files...

rather than:

hg ci -m"Bug 513834  - add "local" to Public Suffix List. Patch by Adam Langley, [e-mail]; r=gerv." ...files...

Comment 11

[Gervase Markham [:gerv]]

Nominating for branches. Companion bug 513834. Justification: keeping public suffix list in sync across branches (this change should have no effect on Firefox itself).

Gerv

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 397775 [details] [diff] [review]
patch

Approved for 1.9.1.5 and 1.9.0.16, a=dveditz for release-drivers

Comment 13

[Gervase Markham [:gerv]]

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

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3aa22391ebe7d5aac6d56813418092b329d92cac

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/22e923bf460b4de772063d121d42ff40a5ce1948

Gerv

Comment 14

[Al Billings [:abillings - ex-MoCo]]

Verified in source for 1.9.1 and 1.9.0. Nothing else for QA to do here.