438304 - Public Suffix ("Effective TLD") List should be dynamically updated

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[Gervase Markham [:gerv]]

We can update the public suffix list when we do security updates, which have a good take-up rate. But if this data changes faster than we expect (perhaps in the future) or if people stop installing updates, or when updates for a product end, there is potential for a reduced user experience.

It would be better if this file were regularly pulled (say every fortnight) off a mozilla.org server.

Gerv

Comment 1

[Dave Townsend [:mossop]]

Bug 414122 moved the effective TLD data into the application code in effect, I don't think it is possible to download a file and use it now.

Comment 2

[Jesse Ruderman]

> But if this data changes faster than we expect (perhaps in the future)

Let's not add a bunch of complexity and extra network requests just because it "might be an issue in the future".

> or when updates for a product end

If you're using an end-of-lifed branch of Firefox, having an out-of-date TLD list is the least of your problems.

Comment 3

[Gervase Markham [:gerv]]

The discussion on DNSOP regarding this issue is here:
http://www.ietf.org/mail-archive/web/dnsop/current/msg06100.html

I am told that the number of TLDs is set to increase in the next few years. 

If this data stops being updated, and registries change their policies to e.g. permit foo.zz when before only foo.com.zz was allowed, then it will be as if the browser has cookies turned off for foo.zz if they want to share cookies across www.foo.zz and login.foo.zz. This isn't great.

You could argue that this is just tough luck for an end-of-lifed product. But in the past, we haven't actively sought to "time-bomb" our code with relation to web compatibility. "When updates stop, it slowly breaks" isn't great engineering. For example, the phishing feed will continue to work in an EOLed Firefox.

Gerv

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #3)
> If this data stops being updated, and registries change their policies to e.g.
> permit foo.zz when before only foo.com.zz was allowed, then it will be as if
> the browser has cookies turned off for foo.zz if they want to share cookies
> across www.foo.zz and login.foo.zz. This isn't great.

Can we not make the service fallback in the case of a page in an unknown effective TLD and use some sane setting for cookies?

Comment 5

[Gervase Markham [:gerv]]

Dave: I don't understand what you are suggesting. What is an "unknown effective TLD"? Can you give an example?

In the scenario I suggest, you are in the situation where the effective TLD list is telling you actively to do one thing, but the right thing to do is different.

Gerv

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> For example, the phishing feed will continue to work in an EOLed
> Firefox.

I'm not sure that's true - what do you mean by "work"? I don't think anyone has guaranteed that the anti-malware and anti-phishing blacklists for all clients will be updated indefinitely.

Comment 7

[Gervase Markham [:gerv]]

What I meant was that the phishing feed will not stop working just because the client has been EOLed. And if it gets turned off for some other reason, the user can configure a different one. 

Gerv

Comment 8

[Gervase Markham [:gerv]]

We've already had one instance where, because the list was incorrect, an organization couldn't set domain-wide cookies and their portal broke in Firefox 3. I really think it would be wise to have a faster way of updating this list.

Gerv

Comment 9

[Gervase Markham [:gerv]]

Looks like we are getting by, updating it manually.

Gerv