search

publicsuffix / list

The Public Suffix List
https://publicsuffix.org/
Mozilla Public License 2.0
2k stars 1.2k forks source link

add `wdh.app` #2067

Closed wdhdev closed 1 month ago

wdhdev commented 1 month ago

Public Suffix List (PSL) Pull Request (PR) Template

Each PSL PR needs to have a description, rationale, indication of DNS validation and syntax checking, as well as a number of acknowledgements from the submitter. This template must be included with each PR, and the submitting party MUST provide responses to all of the elements in order to be considered.

Checklist of required steps

Submitter affirms the following:

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

Description of Organization

I am an individual software engineer who hosts websites, APIs, automation tools, etc for my clients which are usually small businesses or organisations.

Organization Website:

https://william.net.au

Reason for PSL Inclusion

I require cookie security as multiple different websites and APIs are hosted on this domain (they are automatically deployed with a wdh.app subdomain, e.g. mywebsite123.wdh.app), some of which have login pages which must remain separate.

We also have preview deployments deployed on nested subdomains (e.g. preview1.mywebsite123.wdh.app) and it would be good to treat each hosted app as an individual domain.

Number of users this request is being made to serve:

500+, this is an estimate based off how many people are using these websites and APIs.

DNS Verification via dig

dig +short TXT _psl.wdh.app
"https://github.com/publicsuffix/list/pull/2067"

Results of Syntax Checker (make test)

All tests passed.

groundcat commented 1 month ago
wdhdev commented 1 month ago

It might be helpful if you could specify the nature of the service (SaaS, subdomain registry, or web hosting on subdomains, etc.) that is planned or what types of websites your clients are hosting under this domain that necessitates the separation for security.

Predominately web hosting. However some are hosting internal dashboards with logins and such which use cookies which require separation to avoid any browser confusion and to avoid any potential super cookies across the entire domain name.

No SERP result in Google yet.

This domain is mainly used as a backend, with other domains reverse proxied to it. For example, api.wdh.gg is reverse proxied to p8wwsks.wdh.app.

You indicated third-party limits to work around in your PR are Cloudflare and Let's Encrypt; if this is not your intention, perhaps you need to remove these lines.

Whoops, I forgot to remove that section from the PR template. I am not looking to work around these limits. I have updated the PR template.

You mentioned "500+, this is an estimate based off how many people are using these websites and APIs." Is the 500 count for existing users who have been using this specific domain since July 13 or the planned usage (the portion of users from your user base that will use this specific domain)?

This is a fairly accurate estimate of the amount of individual users that are sending requests to these domains (not the actual amount of organisations hosting content on these.) This is estimated to grow to 1000's of users per month based off the analytics of some companies that will be moving their infrastructure to wdh.app.

simon-friedberger commented 1 month ago

This domain is mainly used as a backend, with other domains reverse proxied to it. For example, api.wdh.gg is reverse proxied to p8wwsks.wdh.app.

This means that the clients think they are talking to api.wdh.gg and putting wdh.app on the PSL won't change their behavior.

This is generally an issue with a lot of PSL submissions. After some kind of testing most of them move to a dedicated URL for production and they don't really need to be listed.

(Edited: Had it backwards.)

wdhdev commented 1 month ago

That's true however cookie separation is still required as there will be some production instances running on wdh.app subdomains.

simon-friedberger commented 1 month ago

Questions:

  1. As @groundcat said above: It might be helpful if you could specify the nature of the service (SaaS, subdomain registry, or web hosting on subdomains, etc.) that is planned or what types of websites your clients are hosting under this domain that necessitates the separation for security.

  2. We also have preview deployments deployed on nested subdomains (e.g. preview1.mywebsite123.wdh.app) and it would be good to treat each hosted app as an individual domain.

    Did you mean to add those? This will make the preview and whatever app is running on that site share cookies.

Issues: In the current state this probably doesn't meet the bar for relevance.

wdhdev commented 1 month ago
  1. As @\groundcat said above: It might be helpful if you could specify the nature of the service (SaaS, subdomain registry, or web hosting on subdomains, etc.) that is planned or what types of websites your clients are hosting under this domain that necessitates the separation for security.

Web hosting on subdomains.

  1. Did you mean to add those? This will make the preview and whatever app is running on that site share cookies.

Yes, that is intended. Basically mywebsite123.wdh.app would be the production instance and preview1.mywebsite123.wdh.app would be a preview instance. Sort of how pages.dev is configured on the PSL currently.

wdhdev commented 1 month ago

@simon-friedberger Is there any more rationale I need to provide or anything else I need to do?

simon-friedberger commented 1 month ago

This is missing a convincing argument for relevance. The estimated user numbers are low.

Projects that are smaller in scale or are temporary or seasonal in nature will likely be declined. Examples of this might be private-use, sandbox, test, lab, beta, or other exploratory nature changes or requets. It should be expected that despite whatever site or service referred a requestor to seek addition of their domain(s) to the list, projects not serving more then thousands of users are quite likely to be declined.

You are also advertising is-a-fullstack.dev: 40 domains is-local.org: 40 is-cool.dev: 120 is-not-a.dev: 113 localplayer.dev: 33 is-a.dev: 2853

The first few look very light.

wdhdev commented 1 month ago

You are also advertising is-a-fullstack.dev: 40 domains is-local.org: 40 is-cool.dev: 120 is-not-a.dev: 113 localplayer.dev: 33 is-a.dev: 2853

These domains are unrelated to this request as those are on behalf of organisations I work with, this request is for my own personal hosting service, which is completely different. Also those numbers seem to be outdated from my calculations. is-a.dev is currently at 4,657 subdomains, not 2,853. As for the other 5, there are a total 643 subdomains across them, which is a significantly smaller than is-a.dev, however still growing by the day as it is only a fairly new service (also, one of which isn't on the PSL so that will slow growth a bit as users prefer subdomains that are on the PSL for security purposes).

Please also note I've noticed those subdomain scanners like (https://subdomainfinder.c99.nl) aren't completely accurate as they are missing quite a few of the subdomains that are under that domain.

This is missing a convincing argument for relevance. The estimated user numbers are low.

The main reason for this is due to it is a private hosting, however the content hosted on it is public and is used by 500-1000+ users per month and is estimated to grow significantly (to thousands of users per month) as we are moving more infrastructure to the service. Therefore, being on the PSL would benefit the users accessing these production sites (cookie security, URL highlighting, etc).

simon-friedberger commented 1 month ago

It would be helpful, if you could make a statement of the form we are migrating the following services: x, with a users y, with b users z, with c users

wdhdev commented 1 month ago

It would be helpful, if you could make a statement of the form we are migrating the following services: x, with a users y, with b users z, with c users

My personal infrastructure/websites, which receives upwards of 3,800 visitors per month. An accounting firm's infrastructure which has 2,200 users per month. I will also be migrating some is-a.dev infrastructure to it as well, however I do not have analytics for that, but I can estimate around ~100-250 users per month, possibly more.

wdhdev commented 1 month ago

I've just added preview.wdh.app to this request as we are going to start deploying preview deployments on preview.wdh.app subdomains like mywebsite123.preview.wdh.app.

I've added a TXT record for that subdomain as well:

dig +short TXT _psl.preview.wdh.app
"https://github.com/publicsuffix/list/pull/2067"
simon-friedberger commented 1 month ago