3 ms·

That helped me understand how to roughly tell, given two URLs, they can be cross-site or same-site. The addition of Public Suffix in this mix slightly confuses

That helped me understand how to roughly tell, given two URLs, they can be cross-site or same-site. The addition of Public Suffix in this mix slightly confuses things, but I can see why it's necessary for services that give out subdomains. This is actually my first time hearing of it (or to be precise, knowing of it as a concept), and yet it seems to have been around since 2007!

colordrops 6y ago
What I don't understand is why there needs to be a public shared list of suffixes. Couldn't a cookie attribute define the suffix itself?
- jub0bs 6y ago
  You'll find an answer in https://web.dev/same-site-same-origin/ https://web.dev/same-site-same-origin/: [...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created. If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).
- Thorrez 6y ago
  We don't want people setting cookies on com . You might say "oh, just don't set cookies on single-label hosts", well you still have problems with co.uk . There needs to be a list of things like co.uk that you can't set cookies on.
  - the8472 6y ago
    Since this is a domain name concern, couldn't this be solved with some DNS record indicating that?
    - jub0bs 6y ago
      AFAIK, there is no proposal to add a type of DNS record that would allow you to do that. And I don't think that this type of configuration should be done at the DNS level rather that at the HTTP one.
      - chrismorgan 6y ago
        The public suffix list currently isn’t done at the DNS level or the HTTP level—rather it’s a hard-coded list that all the browsers copy. If I were redesigning whatever I felt like without backwards-compatibility concerns, things like TLS certificate authentication, HTTP Strict Transport Security and public suffix matters would certainly all be done through DNS. Not sure if anyone has ever seriously suggested shifting the PSL into DNS, but it seems a pretty reasonable goal to me. Certainly a few other things of this general style (that is, things you need to know before making the HTTPS connection) have been shifting into DNS, and a public suffix list is a better candidate than most because it’s a comparatively restricted set of people that will be using it, so they can cope with setting DNS records (that is, you’re not pushing everyone into implementing it, which would be completely doomed to failure).
    - Thorrez 6y ago
      That's an interesting idea. One downside is that DNS isn't secure. So if someone can MITM your DNS (a coffee shop wifi for example), they could then set cookies on com . And if browsers erase cookies as soon as they see this DNS flag, the coffee shop could erase all your google.com cookies for example.
      - colordrops 6y ago
        What about secure DNS?

colordrops 6y ago

What I don't understand is why there needs to be a public shared list of suffixes. Couldn't a cookie attribute define the suffix itself?

jub0bs 6y ago
You'll find an answer in https://web.dev/same-site-same-origin/ https://web.dev/same-site-same-origin/: [...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created. If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).
Thorrez 6y ago
We don't want people setting cookies on com . You might say "oh, just don't set cookies on single-label hosts", well you still have problems with co.uk . There needs to be a list of things like co.uk that you can't set cookies on.
- the8472 6y ago
  Since this is a domain name concern, couldn't this be solved with some DNS record indicating that?
  - jub0bs 6y ago
    AFAIK, there is no proposal to add a type of DNS record that would allow you to do that. And I don't think that this type of configuration should be done at the DNS level rather that at the HTTP one.
    - chrismorgan 6y ago
      The public suffix list currently isn’t done at the DNS level or the HTTP level—rather it’s a hard-coded list that all the browsers copy. If I were redesigning whatever I felt like without backwards-compatibility concerns, things like TLS certificate authentication, HTTP Strict Transport Security and public suffix matters would certainly all be done through DNS. Not sure if anyone has ever seriously suggested shifting the PSL into DNS, but it seems a pretty reasonable goal to me. Certainly a few other things of this general style (that is, things you need to know before making the HTTPS connection) have been shifting into DNS, and a public suffix list is a better candidate than most because it’s a comparatively restricted set of people that will be using it, so they can cope with setting DNS records (that is, you’re not pushing everyone into implementing it, which would be completely doomed to failure).
  - Thorrez 6y ago
    That's an interesting idea. One downside is that DNS isn't secure. So if someone can MITM your DNS (a coffee shop wifi for example), they could then set cookies on com . And if browsers erase cookies as soon as they see this DNS flag, the coffee shop could erase all your google.com cookies for example.
    - colordrops 6y ago
      What about secure DNS?