Last Comment Bug 438304 - Public Suffix ("Effective TLD") List should be dynamically updated
: Public Suffix ("Effective TLD") List should be dynamically updated
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: unspecified
: All All
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-10 03:09 PDT by Gervase Markham [:gerv]
Modified: 2010-03-23 16:32 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Gervase Markham [:gerv] 2008-06-10 03:09:19 PDT
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] 2008-06-10 03:15:57 PDT
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 2008-06-10 09:31:13 PDT
> 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] 2008-06-11 02:01:53 PDT
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] 2008-06-11 02:06:56 PDT
(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] 2008-06-11 04:20:15 PDT
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: gavin@gavinsharp.com] 2008-06-11 19:03:42 PDT
(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] 2008-06-12 01:47:22 PDT
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] 2008-06-25 07:28:24 PDT
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] 2009-10-08 09:40:20 PDT
Looks like we are getting by, updating it manually.

Gerv

Note You need to log in before you can comment on or make changes to this bug.