Baldinof commented 4 months 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

[x] Description of Organization
[x] Robust Reason for PSL Inclusion
[x] DNS verification via dig
[x] Run Syntax Checker (make test)
[x] Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

Submitter affirms the following:

[x] We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

[x] This request was not submitted with the objective of working around other third-party limits

[x] The Guidelines were carefully read and understood, and this request conforms
[x] The submission follows the guidelines on formatting and sorting

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)

[x] Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

Description of Organization

We are Strapi.io and we develop an open-source headless CMS. Our users create their own Strapi project to manage their content and data.

We also provide cloud hosting services for our users, so they can deploy their Strapi project on our platform.

I am Florent Baldino, I work as an SRE at Strapi.io specifically on the cloud hosting platform.

Organization Website:

https://strapi.io

Reason for PSL Inclusion

A Strapi project is a node.js application that needs to be hosted.

We created Strapi Cloud to let our customers deploy their Strapi project:

the project server is hosted on a subdomain of strapiapp.com in the form of <project-id>.strapiapp.com
Strapi being a CMS, it is possible for our users to upload files to their own project. These files are stored on a subdomain of the form <project-id>.media.strapiapp.com

We would like strapiapp.com to be on the PSL in order to:

Restrict the projects use of cookies to their own personal subdomain. This isolation guarantees security to each of our customers (e.g. in the case of some iframe exploit)
Avoid domain reputation of a.media.strapiapp.com affecting b.media.strapiapp.com, given that a and b are distinct content creators. Owner of a.media.strapiapp.com could upload a phishing HTML file, and this should not affect the reputation of b.media.strapiapp.com. This also seems to be best practice, given that similar site hosting platforms have entries in the PSL.

DNS Verification via dig

dig +short TXT _psl.strapiapp.com
"https://github.com/publicsuffix/list/pull/1982"

dig +short TXT _psl.media.strapiapp.com
"https://github.com/publicsuffix/list/pull/1982"

Results of Syntax Checker (`make test`)

Waiting for CI run

yahesh commented 4 months ago

Sorting looks good to me.

simon-friedberger commented 4 months ago

[x] Expiration (Note: Must STAY >2y at all times)
- [x] strapiapp.com expires 2026-11-22
[x] DNS _psl entries (Note: Must STAY in place)
[x] Tests pass
[x] Sorting (TY @yahesh)
[x] Reasoning/Organization description

See:

[x] Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

trabelsiemna8 commented 4 months ago

[ ] Expiration (Note: Must STAY >2y at all times)

[ ] strapiapp.com expires 2024-11-22

[x] DNS _psl entries (Note: Must STAY in place)

[x] Tests pass

[x] Sorting (TY @yahesh)

[x] Reasoning/Organization description

See:

[x] Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

Hello, is it mandatory to extend domain registration, even though the auto-renewal is already set?

dnsguru commented 4 months ago

Short answer is Yep.

Most registries publish the expiration date in whois / rdap so that it can be looked up and not burn volunteer reviewer cycles.

Putting an entry in the PSL has a long term impact, so having an expiration date that is also long term helps signal from the requestor that they are committed to the domain(s) in the request.

Temporary entries are not acceptable. Domains can be renewed to an extended a period of up to 10 years. 10 seemed long. Many of us wanted 5, but we settled on 2.

Less time than that signals that the domain names might not renew and would leave debris for PSL maintainers and future registrant to deal with, which wastes a lot of time and causes problems for all involved except the one who requested the now-stale entry that breaks cookies for the new registrant.

"Trust us, we will renew it" typically has similar odds to a coin flip, so we arrived at "2 years from today's date or longer" to give room for PR submitters to signal their commitment (and thus qualification for listing).

trabelsiemna8 commented 4 months ago

Short answer is Yep.

Most registries publish the expiration date in whois / rdap so that it can be looked up and not burn volunteer reviewer cycles.

Putting an entry in the PSL has a long term impact, so having an expiration date that is also long term helps signal from the requestor that they are committed to the domain(s) in the request.

Temporary entries are not acceptable. Domains can be renewed to an extended a period of up to 10 years. 10 seemed long. Many of us wanted 5, but we settled on 2.

Less time than that signals that the domain names might not renew and would leave debris for PSL maintainers and future registrant to deal with, which wastes a lot of time and causes problems for all involved except the one who requested the now-stale entry that breaks cookies for the new registrant.

"Trust us, we will renew it" typically has similar odds to a coin flip, so we arrived at "2 years from today's date or longer" to give room for PR submitters to signal their commitment (and thus qualification for listing).

Hello, thanks for the detailed explanation, I extended the domain registration strapiapp.com for 2 years. it will expire in November 2026, should it be ok to get the check passed?

simon-friedberger commented 3 months ago

@Baldinof The CI ran fine. Please update the initial request. Also, can you please elaborate which Cloudflare and Letsencrypt limitations you are working around?

Baldinof commented 3 months ago

@Baldinof The CI ran fine. Please update the initial request. Also, can you please elaborate which Cloudflare and Letsencrypt limitations you are working around?

Nice!

@simon-friedberger We are not working around cloudflare / letsencrypt, should I just remove the section?

simon-friedberger commented 3 months ago

If you're not working around any restrictions make the list empty but keep the task.

Baldinof commented 3 months ago

Alright, it's done.

Baldinof commented 3 months ago

Thank you @simon-friedberger :)