Circular dependency in PRIVATE section guidelines: usage requirements vs. usage-blocking absence

[pbennett]

The guidelines state that the PRIVATE section exists for "owners of privately-registered domains who themselves issue subdomains to mutually-untrusting parties."

The guidelines also state that "projects not serving more than thousands of users are quite likely to be declined."
These two criteria can create a circular dependency.

For a domain that architecturally functions as a registry — issuing independent subdomains to independent parties with full DNS control — many of the things that would generate "active usage" in the way reviewers measure it (hosted websites, TLS certificates, hosting platform integration) are themselves gated on PSL inclusion:

Hosting platform verification:
Services that consume the PSL to determine domain ownership boundaries (Vercel, Netlify, etc.) will treat all subdomains under a non-PSL-listed domain as belonging to a single entity. Only one user can verify ownership; all subsequent users are blocked.
Cookie isolation: Without PSL inclusion, any subdomain holder can set cookies readable by all other subdomain holders — a security issue that discourages legitimate use.
Certificate issuance: CA rate limits apply per registrable domain as determined by the PSL, constraining independent subdomain owners.

The result: reviewers look at CT logs or hosted sites to gauge usage, find very few, and decline. But the reason there are very few is precisely because the domain isn't on the PSL. The submitter is told to "encourage users to start using the submitted entry" — but users can't fully use it until it's listed.

So, how should the PSL evaluate PRIVATE section submissions where:

The domain architecturally meets the stated criteria (independent subdomains, mutually-untrusting parties, independent DNS control per subdomain), and
The low current web-hosting usage is a direct, demonstrable consequence of the domain not being on the PSL?

Is the architectural criterion sufficient, or is demonstrated active web hosting always required regardless of whether the PSL's absence is what's preventing it? If the latter, this should be made explicit in the guidelines, because the current text doesn't state it and the stated purpose of the PRIVATE section implies architectural eligibility.

For comparison
Many entries currently in the PRIVATE section were presumably added based on their architecture — that they issue subdomains to independent parties — not because reviewers first counted how many active websites existed under them.

Were herokuapp.com, pages.dev, vercel.app, netlify.app, azurewebsites.net, etc. all required to demonstrate thousands of actively hosted sites with TLS certificates before being listed?
If so, how did their users get hosting platform verification and proper cookie isolation before listing?
If those entries were added based on architectural merit and the operator's credible commitment to the service, that seems like the right model — and it's a model that would resolve the circular dependency for future submissions too.

What I'm asking for
I'm not asking for my specific PR to be reconsidered here. I'm asking for one of:

Acknowledgment that the circular dependency exists and guidance on how submitters in this situation should proceed (e.g., a minimum number of DNS-active subdomains rather than web-hosted sites, or architectural review as an alternative path), or
An explicit policy update stating that demonstrated web-hosting activity is a hard prerequisite regardless of architecture, so that future submitters with similar services know upfront that they need to solve the chicken-and-egg problem by other means before applying.

Either answer would be useful. The current state — where the guidelines describe an architectural criterion but PRs are evaluated on a usage criterion that the guidelines don't state and that PSL absence itself prevents meeting — is unclear and leads to frustrating circular conversations for both submitters and reviewers.

[pencilnav]

Related: #2782

[fakeboboliu]

Just my 2 cents, the criteria are relatively clear: PSL should be the result of your service growth, not an incubator.

For most of the CA services we know, the restrictions are either lenient enough for start-up projects, or they can be used by communicating with them, and all of this is even free

[hiifeng]

just to clarify, there are many ways that organizations can demonstrate they are mature, stable and trustworthy projects by operating for a period of time.

In fact, architecting those namespace without the need or requirement of the PSL listing being mission critical is ironically one of the strongest signals of the maturity, stability and trust.

After a decade and a half of responding to pull requests, rationales and premises for inclusion, it becomes very obvious which requestors or requests are sus and which are legit. It is gradient, not polarized on these things, but some of the signals that are 'flags' are

artificial urgency or persistent bumps or nags
thin, if any demonstration of actual users being served
utillity / benefit to the org is greater than their users
we need X to work ([cloudflare|gitlab|etc])

The text above comes from a previous reply by Jothan. I hope it’s helpful and gives you a better sense of how the PSL review process works. Ironically, if a project can operate normally without relying on the PSL, that actually shows it’s more mature. In fact, many projects were running independently before being added to the PSL, without depending on it to build up active users. That in itself is a signal of a mature, trustworthy project, and it also makes running the project a lot smoother.

[pbennett]

I want to respectfully point out that the reasoning you just presented is self-contradictory:

The position is: "If a project can operate normally without relying on the PSL, that shows maturity, and that maturity is a signal for PSL readiness."

But the PRIVATE section exists specifically to solve problems that cannot be solved without PSL inclusion.
Cookie isolation between mutually-untrusting subdomain owners is enforced by browsers using the PSL.
There is no alternative mechanism.

A project cannot "architect around" the need for proper cookie boundaries — that's one of the entire reasons this list exists and why herokuapp.com, pages.dev, netlify.app, and hundreds of other entries are in the PRIVATE section.

If "operating without the PSL" is the prerequisite for being added to the PSL, then logically no new entry should ever be added to the PRIVATE section. Yet new entries are added regularly. So this standard is not actually being applied universally — which brings me back to the original question this issue was filed to ask:

What is the actual, consistently-applied standard?

I'm not asking this rhetorically. I'm asking because the written guidelines say one thing (architectural eligibility for domains issuing subdomains to mutually-untrusting parties), the PR review applied a different standard (demonstrated active web hosting), and this thread is now proposing a third standard (operating successfully without PSL inclusion as proof of maturity). These three cannot all be the criterion simultaneously.

A clear answer — even if the answer is "we require X and Y and Z, and your project doesn't meet them" — would be more useful than circular reasoning, both for me and for future submitters.

[hiifeng]

I understand the point you're making, and I also understand why it can feel frustrating.

When I first applied to have my project added to the PSL, I ran into a very similar situation. My submission was declined twice because the project was considered too small at the time. It wasn't accepted until the third attempt, about eight months later.

During that period, I focused on continuing to grow the project and attract real users. At the same time, I tried to be transparent with users about the limitations that exist before PSL inclusion. For example, I recommended minimizing the use of cookies where possible, or relying on host-only cookies to reduce cross-subdomain risks.

So I do understand the “chicken-and-egg” concern you're describing. From what I've seen over time, the reviewers generally treat PSL inclusion as something that follows demonstrated project maturity rather than something that enables it. It can be a slow process, but that seems to be how the review process tends to work in practice.

[simon-friedberger]

I understand your frustration, I wish we didn't have to gate-keep PSL addition at all. I brought this up again in a meeting with other browser vendors in the last year and it was denied "because size is still a concern".

Some of this can be remedied with __Host- cookies. And __Host-http- can achieve even better separation.

And of course - quoting PhearZero:

Many projects will not take the time to provision certificates or even drive much traffic to that source. This seems like it would be in direct competition with their primary domains.

Yes, in fact, most people prefer having a separate domain anyway which also solves the isolation problem.

[pencilnav]

Response to #2782 (comment)

Even within the current state of the system, the user metrics seem to meet the requirements as I understand it. The users in the NFD ecosystem are genuine and many have re-occurring subscriptions. This seems very much inline with the spirit of the org and the intent for PRIVATE. I do not know of any legitimate way to satisfy these requirements as outlined, given the lack of isolation between subdomains. (why many users just use it for vanity purposes like myself, I am unaffiliated with txnlab and just a user of NFD)

Please check #2805 (comment) #2805 (comment). There are also other entries that was denied from adding into the PSL, and after a few months, exceeded the user count requirements and got merged.

@PhearZero

[456dev]

So to get accepted, You would have to run your service without important security features? On the hope that you get big enough for the psl, before someone finds a way to make your service exploitable?

Not everyone can enforce a certain type of cookie to be used (e.g. running user applications that can set response headers, or even delegating hosting to users themselves)

[pbennett]

So to get accepted, You would have to run your service without important security features? On the hope that you get big enough for the psl, before someone finds a way to make your service exploitable?

It's even worse - it means for your users they can't use some hosting services - at all.

[dnsguru]

Let's follow that argument, as it prompts some important (rhetorical) questions.

If an inability to use some hosting services exists without PSL inclusion, or a lack of security features is important that can't exist without having a PSL entry, why would someone offer something exploitable, incomplete or insecure to users that would have a dependancy on a project like the PSL or thrust the ownness of these attributes onto those volunteers?

[456dev]

I'm not sure, let's ask the browsers why they rely on it for security features.

For certain features, I don't see why it needs to be a centralised list at all, instead of some DNS record to state that cookies should not be shared below this level (for example)

I get having a trusted list is useful for some purposes, (as much as it increases your workload with people asking for inclusion to bypass restrictions services put in place)

But I cannot see the benefit of using it to gatekeep stuff like cookie /strict origin isolation, which would just make it harder for a malicious website/service operator to do anything nasty with.

Also, it's not nessesaraly the service that is exploitable, but users content.
Not everyone want to spend however much on a domain for every user to keep stuff isolated, including Google, which uses the psl as a core security feature
(E.g. https://bughunters.google.com/blog/beyond-sandbox-domains-rendering-untrusted-web-content-with-safecontentframe )
And *.usercontent.goog

[simon-friedberger]

@456dev Yes, we should build something better. Nobody has invested enough time to do it yet. The problem with new DNS records is that they sometimes get blocked by firewalls and - mostly - the additional latency of doing a separate network lookup.

[dnsguru]

Ultimately, the reason PSL even exists is to solve a wide problem which is that there was not / is not any effective method in the DNS to allow the administrator of a given domain name to clearly articulate their preferences, in more granularity than DNS offers, about the manner they would prefer the internet, applications, etc interact with their namespace.

The problem with new DNS records is that they sometimes get blocked by firewalls and - mostly - the additional latency of doing a separate network lookup.

There is no deliniation between a 'good actor' and a 'bad actor' in DNS also, which was one of the many places the IETF DBOUND slipped on a banana peel.

In the case here, with .algo / .algo.xyz - there is a little bit more potentially under the hood with respect to how stuff will interop or behave as it may relate to any kind of shim/bridging stuff going on.

The circular concern is noted, but usage levels have been expressed as one of the considerations out of respect for filesize modesty and the millions of daily downloads the PSL gets - that the size of the project be a consideration in the rationale of merging a pull request.