Allow Cross-Origin Resource Sharing?

[clark800]

It would be convenient to be able to update the public suffix list from within a progressive web app. This would just require Access-Control-Allow-Origin: * in the HTTP response headers. Is this possible or is it intentionally disallowed?

[sleevi]

It’s intentionally disallowed. It would be dangerous to do so, precisely because there’s no alignment with what the browser’s notion of the PSL is, and no one should be writing new apps using the PSL except for cookies.

[clark800]

@sleevi Thanks for the info! In my case, it doesn't matter if it aligns with the browser, so there is no danger. It would be really nice if the browser provided an API to get the public suffix from a hostname, but I haven't been able to find that.

The publicsuffix.org site says "It is available for use in any software", so curious why you say "no one should be writing new apps using the PSL except for cookies"?

[sleevi]

There is inherent danger if not using it for cookies. https://github.com/sleevi/psl-problems

The browser does not provide an API, in part because you end up with different results across browser versions and across browsers; there's no way to "safely" or "correctly" use the PSL as a boundary for security or privacy, and version/interop skew are prime examples of that. Even with cookies, there's a degree of unsolved complexity (e.g. if a cookie was previously set by an entity now added/now removed from the PSL, it doesn't get purged)

In short, unless you're writing a browser, or trying to replicate cookies as a browser does, you're best served by focusing on the domain. If you're trying to "linkify" something, you should use the ICANN Root Zone Database, because you have no need for the PSL. If you're trying to do something like attribution of an entity, the PSL is easily gamed by anyone interested in bypassing that attribution.

[clark800]

In my case, I'm trying to get the domain that corresponds to the scope of a password so that it can be used as a salt for a hash-based generative password manager. So for example: "mail.google.com", "www.google.com", and "google.com" should all resolve to "google.com" since these are all use the same password, but "a.co.uk" and "b.co.uk" should not resolve to "co.uk" since these are different password domains. Is there a better option than the PSL for this?

I know it's possible for issues to arise due to the PSL being updated or out-of-sync, but the app allows manual overrides for this case and the issue has never actually arisen during many years of use.

[sleevi]

Right, that's definitely a dangerous use of the public suffix list.

An alternative approach would be to store the password for the domain, and when encountering a node with a shared parent, asking the user whether or not to share the password with that parent domain (or sibling).

Password sharing is perhaps one of the prime examples where the PSL has false-positives (i.e. indicating a password can be shared with its base; any shared-hosting entity not on the PSL), false negatives (same-org entities that use the PSL to separate out cookies or other content), and has issues with the version skew I mentioned (a password originally stored for "domain.example" would no longer be accessible once "domain.example" was added to the PSL, to indicate that "sub1.domain.example" and "sub2.domain.example" were separate)

You would also likely find it's a substantially better user-experience through secondary post-processing for your use case (e.g. using a trie, which minimizes both storage overhead and lookup time, and is the most popular of approaches)

[clark800]

Generative password managers never store passwords, they generate them deterministically every time. And one of the primary advantages over conventional password managers is that they do not require synchronization between devices. So if you create your google account on your laptop at "accounts.google.com", then try to login on your phone at "mail.google.com" the phone has to resolve this to the same domain as the computer without any communication between the devices. This is important because it means that the password manager is not dependent on any servers (decentralized), and even works when it's completely offline.

As you said, the PSL solution isn't perfect, but I have not found a better option to satisfy this requirement. And since the user is presented with the "guess" based on the PSL for verification and the option to edit, the "danger" is a risk that the user can easily manage with careful attention.

[sleevi]

Thanks. As hopefully my previous messages conveyed, you cannot safely use the PSL in such a generative process. The security issues involved by changes to the PSL should hopefully be clear, and thus the lack of CORS headers here is a benefit to user security.

The alternative I gave, for such generative approaches, requires you only store the original FQDN used to generate a password, and only so that you can prompt the user to use such a generated password on FQDNs that share a common ancestor in the DNS tree.

To this original issue, there are no plans to expose CORS headers. To this specific issue, please reconsider the use of the PSL, as it will be harmful towards security and interoperability if used as described.

[clark800]

That approach does not satisfy the requirements described in my last comment.

Anyways, thanks again for the info.

[jakearchibald]

I wrote a blog post about origins vs sites, which included an interactive form to compare the two. I had to proxy the PSL because it doesn't have CORS headers 😢

https://jakearchibald.com/2021/cors/#origins-vs-sites