ICANN/private distinction for PSL-based resource limits

[quasicomputational]

The document currently talks about bypassing resource limits by having malicious (or just clueless) sites register themselves as a public suffix, and hence receiving a full resource allocation for each of their cheap-to-set-up subdomains. However, such sites would go into the private section of the PSL. Applying resource limits based on only the ICANN section isn't, to my eyes, obviously flawed in the same way - it fails closed as nodded to already in the document, but at least it doesn't fail open and allow resource exhaustion attacks (as, e.g., same-origin-only resource limits would).

I think that PSL-based resource limits need a bit more discussion. My suggestion is either a demonstration how even only using the ICANN section of the PSL is vulnerable to abuse, or explicit acknowledgement in the FAQ that this is a use-case that the PSL is actually suited to and that PSL alternatives do not (currently) have an answer for.

[sleevi]

Are you aware of any user agent that applies restrictions like that? Otherwise, isn’t this moot?

[quasicomputational]

I'm not aware of a user-agent, no. But it's something I was doing in an extension, and, if it's an idea I've had, I'm sure plenty of other people have thought similarly before me.

[sleevi]

I’m not sure any UA would ever implement it, for the obvious reasons like github.io or appspot.com. Unless you want those non-functional/want to break that use case for domain holders, there’s no reasonable way with the current ecosystem to deploy this, right? And the problem of multiple 2LD registrations is still there. Admittedly, I didn’t try to address the hypotheticals of how someone might misuse it; I only focused on common misunderstandings and existing misuse.

[quasicomputational]

Well, my use-case was where the data is not precious and discarding it was, at worst, mildly annoying rather than breaking; false positives causing data loss in edge cases (which I very much think github.io and appspot.com are) were OK. If that condition doesn't obtain, the dilemma about whether to risk enabling exhaustion attacks or to lose precious data is much harder.

I can definitely appreciate that this isn't the common case (though I also think it's not that uncommon) and the desire not to include all the potential uses/abuses of the PSL, but, considering that the document does already bring up PSL-based resource limits and does use an example that'd be stopped by an ICANN-section-only scheme, I think it could use at least a mention.

[sleevi]

I’ll have to think about how to capture that even an ICANN-based block would fail. Like I said, I thought it was obvious how such restrictions still fall down, but I’ll give a noodle how to possibly make it more explicit. In the years of ranting about it (while maintaining it), I’ve never encountered anyone suggesting that for Web Platform features.