For those first discovering the PSL, a brief review.

There are ~90 prior comments concentrated mostly in two prior submissions from 2016 and 2021 so far: https://news.ycombinator.com/from?site=publicsuffix.org

This is the top comment on the 2021 discussion:

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

There are another couple dozen comments on a few submissions of that: https://news.ycombinator.com/from?site=github.com/sleevi

HN frequently suggests that DNS should be used to solve this; sleevi replied a few years back with:

> This has been a common suggestion since before the Publix Suffix List existed, as you can see from the linked issues in the text (and the references to the IETF DBOUND WG). Like most things, on first glance, it seems like it does make sense. Except it has a lot of issues, which you can see have been discussed for 15 years without resolution, even though yes, it would scale better.

This list sees a lot more updates than you'd probably think: https://github.com/publicsuffix/list/commits/main/

I was looking at this in terms of trying to keep an app up-to-date, and there was a lot more churn than I expected. If you have a security reason to be reading this, you may need to put some effort into maintaining this... at least, technically. I doubt there's hardly an app out there "properly" keeping up with this and the world seems to largely hold together even so.

The Public Suffix List changes often. I have once worked with a team who built a major feature on top of PSL, but the person who built it did not at all consider how it might handle changes to it. Basically, the feature analyzed domains and uses PSL data to extract the "important part" of the domain, and then stored that in the database as part of a primary key in a table. But when the PSL changes, the database needed to be taken offline for certain tables to be completely rebuilt. And code querying the database had to be updated in lockstep with the database changes. This design made zero-downtime deployments difficult. It then took quite a while for the team to evolve the schema such that the database contents would not depend on the PSL.

This is just one cautionary tale I have personally experienced.