Hi there, if possible can Vercel please treat is-a.bot as a public suffix like is-a.dev and other similar services.
You can see the subdomain service here: GitHub - free-domains/is-a.bot: Grab your own sweet-looking .is-a.bot subdomain. · GitHub
The domain has been applied to be listed on the PSL but has not been approved just yet as I’m writing this.
This issue is basically the same as Is-a-dev domain issue and Recognise hrsn.dev as a public suffix .
Thanks.
Update: Subdomains can be used across accounts with a simple access verification step. Vercel respects the Public Suffix List when treating a domain as an eTLD. You should NOT submit a request to add your domain to the PSL unless it is actually appropriate for inclusion (see guidelines)
If you get is-a.bot on the Public Suffix List, let me know and I’ll make sure Vercel’s list is synced to match
@amyegan It appears that the commercial company, Vercel, with paid staff and support, is directing people to a volunteer-maintained service to work around their service limitations or operational constraints.
The Public Suffix List should not be a way for Vercel to offload support work. Putting the pressure on volunteers is inappropriately handing off work debt.
(Edit: I am a PSL Volunteer)
This isn’t really a Vercel support question. There is already a way to use subdomains across multiple accounts, which is a valid solution for some use cases.
If a domain isn’t on the Public Suffix List, browsers won’t recognize it properly. That would result in security issues for separate sites using that domain as a suffix, among other things. In the case of a free domain service, that would be a problem.
The part of this that may involve Vercel support is manually triggering a list sync to make sure PSL updates are picked up faster than they might otherwise be. I hope that makes sense!
It would be much easier if Vercel would treat the domain as a public suffix like my other domains as it is not wise for us to allow users to delegate TXT records to `_vercel.is-a.bot`. Please reconsider as I cannot apply for the PSL until I have reached ~3,000 users on this specific domain name.
@amyegan We have an entire wiki page about this: Third Party Diffusion · publicsuffix/list Wiki · GitHub
I don’t see how this isn’t a Vercel issue, and this is not the first time we PSL Volunteers had to dealt with similar request where a user was directed by an entity (most of the times, commercial company like Vercel and Cloudflare) to submit their domain into the PSL in order for the user to workaround their service limitations or operational constraints. (See PSL PR #2782)
What Vercel currently does with “unblocking subdomain limitations” is no different from what Facebook and Apple did with their “unblocing limitations” (See PSL Issue #1245) and again, is using the Public Suffix List as a way to offload support work and are putting the pressure on volunteers instead of your own support, which is inappropriately handing off workdebt.
We would appreciate Vercel establishing an independent support workflow to handle these subdomain inquiries and relieve the burden on us PSL volunteers.
Related: add `is-a.bot` by wdhdev · Pull Request #3120 · publicsuffix/list · GitHub
@hrsn Vercel hosts websites and apps. As such, it has a responsibility to care about the safety and security of the web. Vercel respects the PSL when considering whether something is treated as a subdomain or public suffix.
For more understanding of why, I recommend this third-party post which explains the key concepts nicely: Understanding Effective TLDs (eTLDs) and the Public Suffix List | Digging DNS
@pencilnav I recognize that it may feel like work is being offloaded onto the PSL maintainers. While that is not the intention (see reasons above), I would be happy to change the wording I use in the future to discourage people from opening inclusion requests for domains that are not appropriate. Please let me know if there is any specific language you would prefer that I use when this question is asked in the future (e.g. minimum requirements for inclusion, request to not open a request unless appropriate, etc.)
@amyegan Quote: Third Party Diffusion · publicsuffix/list Wiki · GitHub
The Public Suffix List is incorporated for a number of uses, and the project does not prescribe how it is or is not used.
One use case that has evolved which places increasing burden on the volunteer PSL maintainers is where some providers point to the PSL as being a place to get included in order to add or change functionality within their systems.
This third party diffusion includes, in some cases, where the presence or absence of entries is leveraged by companies to point customer requests away to an external party in order to keep their own support or customer flow simplified.
Instead, address your customers directly. While referring folks away may make for a simple checkbox next to done for your project or elegant customer service FAQ flow for you or your company, it dumps irritated folks who are affected onto the volunteers that help maintain this project.
It should go without mention that it is inappropriate to do so, but mention it we must. The volunteer resourcing drain is annoying and disrespectful, but it is secondary to directing your customers/clients to potentially request things that might break their websites if not handed off after careful qualification BEFORE handing them off. It is also a crucially important fact about the private section of the PSL that it infers ZERO security.
The inclusion of a domain name that is core to a project may have unexpected affectations that were not desired, and should be reviewed with the support department of the referring party to ensure that they have walked you through the impacts and consequences of PSL inclusion so that you have an intentional experience / outcome with the systems/services that referred you, and have made every attempt to resolve it with them.
In every case, the most appropriate solution to issues such as those that point towards having entries in the PSL should first be resolved with the referring party, as utilizing the PSL as a workaround for engineered limits likely sidesteps important security or other intentional concerns that fed the logic to have those limits.
@pencilnav I’m not sure what you’re trying to get at by reposting the wiki that was already shared. I did read it and offered to change how I respond to future requests for a domain to be treated as if it were a public suffix. Vercel does already offer a way for people to use the same domain across multiple teams.
Can you please explain in your own words exactly what you would prefer that I do in these cases? I’m not sure if you’re suggesting that Vercel should treat a domain as a public suffix even when it isn’t or if you have some other proposed solution