1. 11

  2. 8

    You should be careful about using this list for anything involving security or resource limits.

    • The list is not exhaustive, and never will be. You can’t use absence of a (sub)domain in the list as a permission to share anything across subdomains. The list can’t express situations where domain owners have irregular usage, like customer1.example.com, customer2.example.com and login.example.com.

    • Resource limits that are per “website” using the list incentivise abusers to add *.f-u.example.com to the list to be able to use one domain to create unlimited number of fake “independent” websites to work around limits.

    • It’s not safe to remove entries from this list, and it’s not sustainable to grow it forever. Don’t build anything important on a dead-end model.

    1. 2

      Thank you for posting this link. Eye opening. Appreciated!

    2. 5

      The PSL is a valuable resource for web browsers and it is great that mozilla made it publicly available.

      A few years ago I wrote a library to use it for the NetSurf browser and blogged about how I did that.

      The post might be interesting to others here to show how this list can be used in a practical way https://vincentsanders.blogspot.com/2016/09/if-i-see-ending-i-can-work-backward.html

      1. 1

        For a browser to be secure, it’s not just valuable it’s strictly necessary.

      2. 1

        How outdated/lacking is the Wikipedia List of TLDs compared to this?

        1. 3

          This is more than just tlds. For example, github.io is on this list but not the tld list.

          1. 2

            Oh, understood. That seems really unscalable to manage; per above this list is pretty useless for domain validation. I guess it’s just a curiosity piece, or maybe has some data science use?

            1. 3

              It’s a historic wart in browser/web specifications. We’d usually like everything depend on origin (as in scheme,host port) to be the scope and security’s boundary of a web page (i.e., Same Origin Policy). But we can’t. Cookies have been specified earlier and are bound to a domain and can be expanded to a subdomain or a parent domain. For this, we need to know where the domain ends and where the public suffix starts (e.g., different length for .com and .co.uk)

              A long while ago, people found out they could set cookies for all of .co.uk, which isn’t a registered domain but sort-of looked like it. That was not great.

              The public suffix list is the fix for that. Meanwhile, it has grown to expand and contain all sorts of services with user registerable sub domains, like github.io, so users won’t set cookies on other user’s domains.

              1. 1

                Wonder if cookies will ever be possible to lock down to host only, not parent domain?

                With stuff like OAuth, single sign-on can be solved without sharing auth state in cookies.

                1. 2

                  We’ll try. Mike West (Google) has a draft in the IETF