Thanks for bringing this up, it’s always good to mention potential security issues! Long story short, it’s not causing a security problem for us. We have code and mechanisms (prefixing, auto-detection, encrypted cookies, header overrides, etc.) for preventing session attack issues. The theoretical future risks due to accidental leakage by browsers at this point are not concerning enough (yet) to justify a mass migration of all our users to a different top level domain.
If I was to make a change here, it would probably be to move the front-store Neocities site to www.neocities.org, but that is also not an ideal solution, because it breaks the trust model that our users are familiar with. I may decide to do this in the future, but doing this to soley satisfy an ambiguity issue with the PSL would be pretty difficult for me to justify.
If the PSL is being used as a sole required mandate for quota limit removal, I’d like to discuss that a bit more. If it’s not the sole mandate, you can safely ignore the following text.
I’m not opposed to the PSL existing and I think it provides a good service, but I am worried about relying on it as the sole required mandate for being able to use Let’s Encrypt in larger organizations. In a nutshell, PSL breaks many legitimate scenarios where a root domain should be allowed to function, while still providing an explicit barrier between it and the subdomains:
- As mentioned, the update process takes a long time. Having a several month waiting period to start a new hosting service is a significant barrier to entry that will prevent many new adopters from considering both PSL and Let’s Encrypt.
- Maintenance on the PSL seems to be based on occasional developer availability, further complicating the issue. I’m certain it’s because the maintainers are busy at their primary jobs and that there is no ill will, but it’s worth noting.
- There is no specification for how domains on the list will behave once they are added to the list, it’s left as an exercise to the implementers (which is why I had no idea it would break our cookies with some implementations). I’m not convinced we’ve hit “peak unintended consequences” here yet, and the potential repercussions are devastating, as removing from the PSL is also very difficult and time consuming.
- There are (I believe) legitimate pull requests in that list that have been sitting there for long periods of time (what’s the process for escalation/rejection?).
- It’s IMHO still abusable by attackers, if that’s Lets Encrypt’s primary concern (no business verification or notary requirements).
So I do believe that a complementary PSL-like system is needed for Let’s Encrypt if it does not yet exist.
In the interim, I’m also not a fan of arbitrary decisionmaking and I understand where you’re coming from, but I’d love it if you could make an exception for Neocities for the moment. We’re ready to go with Let’s Encrypt as soon as we can safely launch with support for it.