add t3.storage.dev, t3.storageapi.dev for tigrisdata.com

[bocao-tigris]

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)

• Cloudflare
• Let's Encrypt
• MAKE SURE UPDATE THE FOLLOWING LIST WITH YOUR LIMITATIONS! REMOVE ENTRIES WHICH DO NOT APPLY AS WELL AS REMOVING 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, 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.
  secops@tigrisdata.com

Abuse Contact:

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

  URL where abuse contact or abuse reporting form can be found:
  abuse@tigrisdata.com

---

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

Organization Website: https://www.tigrisdata.com/

Tigris Data, Inc. operates a globally distributed object storage platform compatible with the Amazon S3 API.
The service provides public bucket endpoints under dedicated subdomains that are assigned to independent customers.
This submission is made by an engineer responsible for the storage platform’s domain architecture and web security model.

Reason for PSL Inclusion

Tigris operates a multi-tenant object storage platform where each immediate subdomain under t3.storage.dev and t3.storageapi.dev (for example .t3.storage.dev) is assigned to a different customer.

Customers are mutually untrusted organizations and individuals and can serve arbitrary web-accessible content from these subdomains, including static websites and application assets.

Without a Public Suffix List entry at t3.storage.dev, browsers would compute the registrable domain as t3.storage.dev. This could allow one tenant to set cookies scoped to the parent domain and potentially interfere with other tenants’ applications hosted on sibling subdomains.

Adding these domains to the Public Suffix List ensures correct site boundary computation in browsers and aligns cookie security behavior with the platform’s ownership model.

Number of users this request is being made to serve:

~100,000 customers

DNS Verification

dig +short TXT _psl.t3.storage.dev
"https://github.com/publicsuffix/list/pull/2818"

dig +short TXT _psl.t3.storageapi.dev
"https://github.com/publicsuffix/list/pull/2818"

[pencilnav]

@bocao-tigris Are you sure you want that wildcard?

For example if *.storage.dev is added into the PSL, then foo.storage.devand bar.storage.devwill be treated as an eTLD. Browsers will then treat example.bar.storage.devand example.foo.storage.devas individual eTLD+1 and do separation based on that.

[pencilnav]

Without PSL inclusion, a security incident, abuse report, certificate revocation, or browser/network blocklist entry targeting one customer's subdomain can cascade and impact all other unrelated customers sharing the same parent domain. PSL inclusion ensures that each customer's subdomain is treated as an independent registrable domain, so that actions taken against one subdomain do not affect others

Per PSL Guidelines, this is a non-acceptance:

We do not accept entries that have the objective of getting around limitations that have been put in place by a vendor to protect internet users. The PSL is not a 'workaround', and Pull Requests that appear to be doing this should expect to be declined.

Please note:

The #PRIVATE section comes from the public (irony noted). There should zero trust or security assumptions made about these entries.

https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion

[bocao-tigris]

@bocao-tigris Are you sure you want that wildcard?

For example if *.storage.dev is added into the PSL, then foo.storage.devand bar.storage.devwill be treated as an eTLD. Browsers will then treat example.bar.storage.devand example.foo.storage.devas individual eTLD+1 and do separation based on that.

Thank you for pointing out the misunderstanding regarding wildcard entries.

Let me clarify the hosting model and intended Public Suffix boundary.

We operate a multi-tenant object storage platform under storage.dev.
Each immediate subdomain under t3.storage.dev (for example .t3.storage.dev) is assigned to a different customer.

Customers are mutually untrusted parties and can serve arbitrary web-accessible content from these subdomains, including static websites and application assets.

Without a Public Suffix List entry at t3.storage.dev, browsers compute the registrable domain as t3.storage.dev. This would allow one tenant to set cookies scoped to the parent domain and potentially interfere with other tenants’ applications hosted on sibling subdomains.

Adding t3.storage.dev to the Public Suffix List would ensure that each customer subdomain is treated as an independent site boundary by browsers, aligning browser security behavior with the platform’s ownership and trust model.

I've also updated the entry to t3.storage.dev and t3.storageapi.dev

[pencilnav]

Question (upon some simple checks):

• How does this work exactly? (please give examples that we can validate)

• What isoracle.storage.dev oracle.storageapi.devand why isn't it added?

• Is this domain used solely for object storage or does it host websites and/or other services? (im confused by your comment)

• I am seeing a low amount of certificates on CT logs. This is likely due to your company using a wildcard record for *.t3.storage.dev and *.storage.dev. Can you briefly explain why the first one has a A record to 138.174.138.43(A US Department of Defense IP) and the second one connected to a single Oracle Cloud VM IP (192.9.156.79, according to oracle's docs?

• Please provide the user counts per entry, and some evidence (that can be validated by me or other people here) on the amount of users that will get a subdomain from these two submitted entries. (note that the subdomain itself should be active)

@bocao-tigris

[ovaistariq]

Hi @pencilnav let me explain.

We provide a S3-compatible object storage service which means we provide the same features as S3 and follow the same conventions. https://t3.storage.dev is the S3-compatible endpoint that is used to access the object storage service.

Furthermore, virtual host style URLs are the default way of referencing objects in a bucket. In a virtual-hosted–style URI, the bucket name is part of the domain name in the URL. Virtual-hosted–style URLs use the following format: https://bucket-name.t3.storage.dev/key-name. Every bucket is accessed/used this way through the AWS S3 sdk.

Here are some live URLs of buckets:

• test-public-bucket
• s3torch-benchmark-1

With regards to the IP addresses, you probably meant 137.174.138.43 which is an Equinix IP. Our service runs on a hybrid-cloud deployment, we use Equinix for much of workload and also use Oracle Cloud for some. This is why you see both Equinix-owned IP, as well as Oracle Cloud IP.

[pencilnav]

@ovaistariq Please answer all of the questions.

[ovaistariq]

Thanks for the follow-up. Addressing each question:

User counts:

We have millions of active buckets across t3.storage.dev and t3.storageapi.dev. These are our primary public-facing endpoints for customer bucket access. This concerns all our customers, which is a large number. I would not be able to disclose the exact number of customers.

Active subdomain evidence (verifiable):

• https://test-public-bucket.t3.storage.dev/bucket-global.png

You can validate this resolves and serves content.

oracle.storage.dev / oracle.storageapi.dev:

These are internal infrastructure domains.

IP address concern

t3.storage.dev does not resolve to 138.174.138.43. It resolves to 137.174.138.43 which is an Equinix IP, not a DoD address. The reason for presence of Oracle IP is because we are deployed across Equinix and Oracle Cloud.

[ovaistariq]

The _psl records were pointing to the older PR. I have fixed them now.

::~/Downloads
$ dig +short TXT _psl.t3.storage.dev
"https://github.com/publicsuffix/list/pull/2818"

::~/Downloads
$ dig +short TXT _psl.t3.storageapi.dev
"https://github.com/publicsuffix/list/pull/2818"

Could you please re-run the CI job.

[pencilnav]

Related: #2632

[bocao-tigris]

@pencilnav Is there anything else you need from us to accept the PR?

[pencilnav]

@bocao-tigris Your domain needs to be renewed.

HTTP Redirects to an abuse reporting page or company site with abuse report contact should also be implemented for https://storage.dev and https://storageapi.dev for easier abuse report.

[bocao-tigris]

thanks, we're working on that