list VS psl-problems

perfect use case for the public suffix list (https://github.com/publicsuffix/list)

I just made up `blogger.com` as an example. I probably could have picked a better one. `blogspot.com` & its many TLD variations are on the list.

It looks like the repo where the list is maintained [1] is pretty active. YMMV, I'm not a maintainer or anything..

[1] https://github.com/publicsuffix/list

There's the Public Suffix List https://publicsuffix.org/ but it's limited to domain names, so your github.com/rails example isn't covered. I'm pretty sure HN simply has a manually coded list of URL patterns for popular domains.

Browsers use the public suffix list to determine cookie scope. You can even get your own domains added to it.

https://publicsuffix.org/

Are you sure? Looking at their website[1] I see:

> Highlight the most important part of a domain name in the user interface

Which is my suggestion above.

> If you are using it for something else, you are encouraged to tell us, because it helps us to assess the potential impact of changes

Which sounds cautiously supportive of additional use cases.

[1] https://publicsuffix.org/

Sounds like Bluesky screwed up by not implementing the https://publicsuffix.org/ list

Furthermore, what constitutes a "Site" will also change henceforth. You can only add a primary domain (such as example.com) and the subdomains which are listed on the public suffix list (such as github.io, blogspot.com, etc.). Thus, your own subdomains (such as xyz.example.com or www.example.com) won't be allowed in Adsense.

> In fact I think Firefox would have to implement a similar approach if it were popular enough

They implement an omnibox that works well. Why would they need to do this if they were more popular? I suppose they use the domain suffix list for this. It's probably not bulletproof, but it works well enough and doesn't hammer the root DNS servers.

https://publicsuffix.org/

Ryan Sleevi has written about this before on Hacker News and here's his list https://github.com/sleevi/psl-problems

It's definitely possible that Ryan would consider using this for HN a reasonable choice, because it's mostly cosmetic, but in general you should just not add more dependencies.

Before you begin to make use of the PSL, consider some of its problems: https://github.com/sleevi/psl-problems

FWIW, the link above successfully convinced me and a coworker not to use the PSL.

(googler here, but this is my opinion)

I think there's a big abstraction gap between what we use domains for and what they were supposed to be used for, in a way that we shouldn't assume any ownership only based on the domain itself.

For instance you can have a number of sites that use separate domains but are owned by the same entity (N domains for 1 party). You could also have the same base domain being used for several unrelated parties, think hosting a store on Shopify (1 domain for N parties). This is so ambiguous that even inside the browser you have two different implementations on the way you handle this attribution, one for cookies and one for Single-Origin Policy.

There's a good write up about this problem at https://github.com/sleevi/psl-problems. Sometimes I wonder how the web got here with the amount of kludge that we have to carry.