Remove domain no longer under Supabase control.

[darora]

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

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• 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:

• 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)
  • Cloudflare
  • Letsencrypt
  • <UPDATE THIS LIST WITH YOUR LIMITATIONS! REMOVE ENTRIES WHICH DO NOT APPLY! REMOVE THIS LINE!>

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

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms
• 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)

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

---

Description of Organization

Supabase builds and operates a Backend-as-a-Service platform (database, data APIs, realtime functionality, etc).

I work at Supabase on the Infrastructure team.

Organization Website:

https://supabase.com/

Reason for PSL Inclusion

N/A - request is for removing a domain that was added by us in #1363 , but has expired and is no longer under our control.

Number of users this request is being made to serve:

N/A - request for removal

DNS Verification via dig

Can't create the entry under the domain being removed as it is no longer owned by us. For verification, I've created a record under our primary domains:

> dig +short TXT _psl.supabase.com
"https://github.com/publicsuffix/list/pull/2037"

> dig +short TXT _psl.supabase.io 
"https://github.com/publicsuffix/list/pull/2037"

Results of Syntax Checker (make test)

============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

[dnsguru]

This was noted in #1763 a year ago

[darora]

Linking to the correct PR: #1753

@dnsguru are we OK to remove the specific domain in this PR? Or are removals on hold pending a long-term solution?

[simon-friedberger]

For verifying, it would be helpful if @inian could comment here that this removal is indeed desired. If that is not a possibility I could also send an email to security@supabase.io and ask for confirmation. Let me know if you would like me to do that. @darora

[macgrayson]

For verifying, it would be helpful if @inian could comment here that this removal is indeed desired. If that is not a possibility I could also send an email to security@supabase.io and ask for confirmation. Let me know if you would like me to do that. @darora

I'd suggest sending an email to confirm, just to be on the safe side. It looks like a third-party organization is already using this domain to offer free subdomain services. They're eager to scoop up expired domains listed in the PSL and provide services under those domains. They even advertise the domains as being in the PSL. For instance, the domain paba.se has already been used on a Chinese forum with claims that it can be used on Cloudflare simply because it is in the PSL.

Is there anything we can do to stop expired domains being re-registered and staying in the PSL?

[groundcat]

According to the WHOIS records, the domain was created after Subapase let it expire, likely being registered by a different party.

domain: paba.se
created: 2024-04-28
modified: 2024-05-27
expires: 2025-04-28

This might not be an isolated case, as I've seen similar situations such as #1401 comment and #713 where a different registrant (L53[.]net) took over 2 expired PSL domains and opened up subdomain registration for users with the sole purpose of exploiting its presence in the PSL to bypass third-party restrictions, particularly those imposed by Cloudflare.

Although new registrants of any expired PSL domains are not necessarily malicious, it is concerning that there is a potential that some might take advantage of expired PSL domains in the future to bypass critical measures like anti-spam or antivirus filters. For example, some blocklists whitelist PSL domains (Firefox Tracking Protection example), relying on the PSL to determine domain separation, which could be exploited by bad actors.

I'm not a PSL maintainer, so I'm unsure of the exact procedures for handling expired domains that are taken over, transferred, or repurposed. In the past, it seems the PSL has accepted such cases, like with us.kg #1755 , where a nonprofit took over an expired domain and continued a discontinued service. The new registrant submitted a PR, and since they met guidelines, it was accepted.

I'm guessing if the new registrant of paba.se is genuine and provides an SLD registration service that meets all PSL inclusion requirements, and if they submit a PR, they might have a chance. It seems they do provide a subdomain service at https://nic.paba.se and CT shows a number of subdomains. However, if they are aware of the PSL and exploit it without submitting a proper PR, it might not reflect well on them...

[simon-friedberger]

Confirmed by email.

[darora]

Sorry I missed your earlier comments; thanks for resolving over email!