Closed Bug 537975 Opened 16 years ago Closed 15 years ago

Update Public Suffix List for many TLD+1s from pseudo-registry (?)

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: zerodpx, Assigned: zerodpx)

Details

Attachments

(1 file)

Attached file List of pseudo-TLD+1s
This is an offshoot from bug 528470. In that bug, we discussed adding de.ki to the Public Suffix List as a pseudo-TLD+1. After checking with the folks there to see if they desired inclusion in the list, I received an email stating "we think that including our domains is the right thing and so we are sending you a list of all the domains that are part of our subdomain project" along with an attached list of close to 1450 websites. (I have attached a copy to this bug.) I'm not sure whether to add all these or not. There's no formal problem with them, we've included a few such sites in the past, and our list is already quite long. On the other hand, if the company running these goes belly-up or loses control of some of these sites, we'll become inaccurate without an obvious neutral third-party site that lists the details (like Wikipedia tries to do for real TLDs). I'm leaning toward reluctantly adding them because I can't really justify not doing so unless we decide to include no such sites at all. Other opinions?
Perhaps people who buy domains in these hierarchies should be made aware that they are forgoing whatever cookie security "top-owned" domains have. Maintaining a list like in this attachment, not derived from registries, seems very difficult. If registries can be bugged to respond on IDN punycode policies, maybe bugging them on suffix policies is the best course of action. Also, the terminology is a problem. The "eTLD" name morphed to the more neutral "Domain Suffix", which some Wikipedia editors abhor (* see below), and then I see ietldlist.xml, not well documented by Microsoft as far as I can tell, along with the Windows registry key "FEATURE_USE_IETLDLIST_FOR_DOMAIN_DETERMINATION". I take it the purpose is to distinguish allowable local, non-internet domain names or something like that. And now "pseudo-TLD" for a non-official eTLD, and "eTLD+1s" for a domain one level deeper? At some point the cookie crumbling public, or at least tech heads, need to be able to discuss these things, and Google/Wikipedia are thin on results for these new terms. (The original Netscape cookie spec calls all this "tail-matching", by the way.) IMHO, adding pseudos would make the situation for the public even more murky, so now add significantly to security. The domain owners need to understand there own cookie realms. A UI displaying the site's cookie domain "realm" would be cool. If "realm" is the right term! [*] Wikipedia editor rejecting (twice) "suffix" as a term in the Domain Name System article, because it is not official: http://en.wikipedia.org/w/index.php?title=Domain_Name_System&action=historysubmit&diff=336532757&oldid=336515287
sorry, typos.... IMHO, adding pseudos would make the situation for the public even more murky, so not add significantly to security. The domain owners need to understand their own cookie realms.
(In reply to comment #1) > Perhaps people who buy domains in these hierarchies should be made aware that > they are forgoing whatever cookie security "top-owned" domains have. Perhaps, but that's not really our job (nor is it possible for us to do it). This is a request for the pseudo-registries. > Also, the terminology is a problem. Terminology should have zero influence on our decision about behavior. I consider it an explicit non-goal to behave in a way that Wikipedia editors, or anyone else, feel like they have good names for.
I agree about the terminology & about the import Wikipedia. My point is that not having well-known terms means the security issue is not well-known, and that is a problem. We can try to code around the users' ignorance, but should try to reduce it also. IMHO, maintaining a list of off-registry eTLD's is a bridge too far, but it's debatable.
(In reply to comment #4) > IMHO, maintaining a list of off-registry eTLD's is a bridge too far It's a bridge we crossed a while ago; our list already contains more than one of these.
Sorry for the delay in adding my thoughts here :-) I agree we've crossed this bridge, but there's a bit difference between adding the highly respectable iki.fi and a few dozen other domains, and adding a list of 1450. We might reasonably decide any of the following: 1) add the new ones 2) grandfather the old ones in, but don't add any more 3) row back to just official ones from ICANN-affiliated (or whatever the right word is) registries IMO the PSL is all about where the divisions of control lie. fooshop.shops.yahoo.com and barshop.shops.yahoo.com are both shops, and the shops are independently controlled, but the _domains_ are not - Yahoo controls them both. The situation is very different to fooshop.com and barshop.com. I think Peter's point about companies going belly-up or losing control of domains is a good one. The further we get from official divisions, the more likely it is that info we add will go out of date, and someone (a user or a domain owner) will get inconvenienced. And I don't want to go down the line of legal agreements with these subdomain companies to get them to tell us about changes. It's all matters of degree, but we have to put the line somewhere. <sigh> Do we have any idea how big this industry is? If we ad 1450 today, will another list of 14,500 appear tomorrow? Gerv
pkasting: any thoughts on my thoughts? Gerv
There's nothing you've added that I have any response to. I can't answer your final question except to guess that probably there are many other similar cases.
OK. Let's not do this, then. Gerv
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: