Add convex.cloud and convex.site regional domains

[gautamg795]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• 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).

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)

N/A

• 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, and 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 to them.
• The submission follows the guidelines on formatting and sorting.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 30 days.

Abuse Contact: security@convex.dev

• Abuse contact information (email or web form) is available and easily accessible.

  URL where abuse contact or abuse reporting form can be found: convex.dev/security

---

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 and cause other issues, and the rollback timing is acceptable. Proceed anyways.

---

Description of Organization

Convex is a cloud-hosted backend application platform that companies use to build and run full-stack web applications. The platform includes a database, compute engine, authentication, file storage, and more. Developers use Convex to build dynamic apps with real-time data and scalable APIs.

Convex serves both frontend and backend infrastructure on behalf of its customers. The frontend content (such as static sites or web apps) is served via one subdomain pattern, and backend APIs and object storage are served via another. These are isolated from Convex's own corporate sites.

I am an engineer at Convex submitting this request on behalf of the company.

Organization Website:

convex.dev

Reason for PSL Inclusion

This submission extends on #2436 and #1767 by adding our new "regional" subdomains. While Convex previously hosted user-owned content at <unique-name>.convex.{cloud,site}, we're now adding prefixes to disambiguate users in different regions. This does not apply to the previously-added convex.app at this time. As we'll now be hosting untrusted user code and content at *.{us-east-1,eu-west-1}.convex.{cloud,site} we're adding these regional domains to the list for the usual security reasons around cookie isolation and domain reputation.

Both convex.cloud and convex.site are registered until at least 2029 and will continue to maintain more than one year remaining on registration. The _psl TXT records will be maintained and kept up to date.

Number of users this request is being made to serve:
100,000+

DNS Verification

dig +short TXT _psl.us-east-1.convex.cloud
"https://github.com/publicsuffix/list/pull/2772"

dig +short TXT _psl.us-east-1.convex.site
"https://github.com/publicsuffix/list/pull/2772"

dig +short TXT _psl.eu-west-1.convex.cloud
"https://github.com/publicsuffix/list/pull/2772"

dig +short TXT _psl.eu-west-1.convex.site
"https://github.com/publicsuffix/list/pull/2772"

[simon-friedberger]

Since this has regional domains and is probably not for human consumption can you please use new domains and a wildcard entry like *.convex.net?

[gautamg795]

Hi, sorry if the description was misleading — this is indeed for human consumption.
Convex previously gave out funny-name.convex.cloud and funny-name.convex.site URLs for customer content, but at the time we were single-region.
Now that we're supporting multiple regions we've had to include the region in the URL itself for ease of routing requests, but the URLs serve the same purpose. (The old URLs will continue to work for our original/legacy region, but all customers in new regions will only get these prefixed URLs)

[simon-friedberger]

And is using a new domain with a wildcard a problem for some reason? You could also add the wildcard on the old domain, all it would do is block domain cookies which are pretty rare and not recommended anyway these days.

[gautamg795]

Correct, moving to a new domain is not feasible for us. A wildcard on the old domain would break users using the legacy unprefixed URLs -- if they host auth on funny-name.convex.site for example and we have *.convex.site on the PSL, my understanding is the user would be unable to set cookies on their domain.

[simon-friedberger]

I will approve this but will be against adding further regions.

[dnsguru]

@simon-friedberger we are seeing these type of requests more with emerging cloud-hosting or infrastructure providers. Do we want to be explicit in the guidelines about being restrictive about this type of scenario?