Yes, it’s weird to have a maintainer asking people not to use their project, but the PSL was a very specific (and unfortunate) hack for a very specific (and unfortunate, and browser-created) problem. It is something we live with, not something we like. While the ideal world is “don’t use any list at all, use the protocols as God, the IETF, and IANA intended”, if you are going to use a list, using the IANA list, updated daily, is much better than the PSL.
Do not use the PSL for anything that is not “cookies abusing the Host header”
To the extent it is used by cookies, we still want to maintain a fair and equitable solution. However, we also want to actively discourage any new users or use cases, to the extent possible, while we also try to fix cookies.
Ideas like https://github.com/privacycg/first-party-sets provide a possible model. While FPS doesn’t directly address this, as part of keeping a narrow scope, the approach to explicitly expressing boundaries is one that has the best viable path. However, that’s effectively “Deprecate the Host option for cookies”, so... that’s a big task.
Simply sabotaging the PSL doesn’t force the problem to be solved, so mostly, it’s an education campaign of “We made a mistake; learn from ours, rather than repeating it.”
WebAuthn ends up relying on the PSL as well (via a concept of "registrable domains" and WHATWG). Presumably you'd want that to just require Same Origin instead?
The WebAuthN case in particular is quite unfortunate, and one I tried to discourage early on (along with the whole app facets approach)
I would recommend libPSL[2]. It was written by one of the maintainers of GNU Wget and is currently used by both GNU Wget and libcurl.
Disclosure: I was one of the early contributors to libpsl and closely involved in its initial formation.
[1] https://publicsuffix.org/learn/ [2] https://github.com/rockdaboot/libpsl
https://github.com/rockdaboot/libpsl/blob/master/src/psl.c is 2K lines, most of it appears to deal with memory management, character twiddling, and processing/conversion.
Maybe the cookie management?
Punycode is a method for encoding international unicode into ascii prefixed with XN--. So this will correctly associate cookies for either the unicode term or its punycode ascii equivalent.
As exanples, wikipedia indicates the international domains with the most name registrations as being the russia's "рф", taiwan's "台灣" and china's "中国", which are represented in DNS as "xn--p1ai", "xn--kpry57d", and "xn--fiqs8s", respectively.
The data appears to indicate hosting sites where users can register their own names against a providers domain ( username.example.com ) as well as exceptions to this where the host's own site then uses subdomains ( www.example.com, admin.example.com, cdn.example.com ) and the host's cookies should still be used.
It lists specific tlds, wildcards where appropriate with *, and notes exceptions to wildcarding by prefixing with !.
Certainly far from something that would be impossible to write your own parser for, but getting everything right on your first go would be harder than one might expect, and getting things wrong here would be likely to leak the user's information between various sites.
Is actually hard to implement correctly and interoperably, even among browsers, and there are sharp edge cases along the way (such as holes within domain trees).
The author of the library referenced at least worked with the PSL maintainers and browsers to make sure they were faithfully and correctly implementing things :)
For example, posts from ansuz.sooke.bc.ca have been popular on HN. Sooke is a municipality, BC is a province.
https://en.wikipedia.org/wiki/.ca#Third-level_(provincial)_a...
Yes, I know about the PSL DNS query service. That's only marginally better. The public suffix flag should be a record on the domain itself.
Which is to say: things went wrong in circles because different folks had different problems, those different problems had incompatible requirements, and so things spun in circles for a number of years as every idea failed to solve the problem for everyone simultaneously, while narrowly-specified solutions were shot down for not solving enough problems.
I remember reading how browsers were accepting cookies that'd be sent to many other sites on the same host level because the browsers had no idea on what authority level to differentiate.
-----
[1] - or second, then again counting root as level 0 seems reasonable.
So there's an awkward way of defining things in various contexts, like cookie permissions, whether a domain is registerable, whether it is a registry the next level up
As the original comment suggested it's a bit of a non sequitur to call anything below the initial host label to be a TLD. I was just suggesting there isn't a generally accepted moniker for what they're called.
The public suffix list makes some kind of definition, mainly for cookie-level permissions.
https://en.wikipedia.org/wiki/.ca#Third-level_(provincial)_a...
Second level domains are by definition not top level domains.
-edit- Ha–I thought this was a top-level comment. I think that counts as irony.
Is this list controlled by Mozilla. Or perhaps some group of browser oranisations/companies.
Personally, not speaking for any other user, I am not really a fan of the browser deciding what is or is not an "acceptable" TLD, because the browser is not the only program I use for generating and sending HTTP. I use a variety of programs. Perhaps if I have some control over the browser's list. For example, I the user can add or subtract "TLDs".
In the past I have done this by running an edited copy of the root.zone on the local network. I think it is a cleaner, less application-specific, solution than relying on a list compiled by a browser vendor(s).
Browsers can easily override the "IANA TLD list" as well as the DNS I set up on the local network. I am not saying they are doing this through this list, but the capability is there. Browsers like Firefox are certainly not shy about constantly manipulating how domains and urls display in an address bar, Chrome wants to "protect" the user from "evil" pages, etc. It is a slippery slope. I like the idea of overriding the IANA but not the idea of this being outside the control of the user, decided by some browser vendor(s). I do not want/need applications making decisions about what is or is not a TLD, or in this case what is a legitimate subdomain for purposes of cookies. I already do that through control over the zone files I serve and system resolver settings; I control, i.e. filter, cookies through a local proxy.
The root.zone has grown exponentially and is full of cruft now thanks to the "gTLD" scheme, as others have noted. If you really care about this stuff, I don't think you can rely on someone else to address the problem for you. Mozilla or whomever produces the "public suffix list" is no doubt tied to the online ad industry in some way, directly or indirectly.