Skip to content

Update content domain in the domain separation RFC #27

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pyropy merged 3 commits into from
Sep 1, 2026
Merged

Update content domain in the domain separation RFC #27

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
15ac0da
Update content domain in the domain separation RFC
pyropy Aug 21, 2026
beaebd1
Merge branch 'main' into fix/user-domain-separation-domain
bajtos Sep 1, 2026
55e0678
final tweaks
bajtos Sep 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 3 additions & 8 deletions rfcs/2026-07-user-data-domain-separation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Status: Experimental

Regional provider S3 endpoints currently live at `<region>.s3.fil.one` — the same registrable domain as our "front of house" properties: the console at `app.fil.one` and the website at `www.fil.one`.

These endpoints serve untrusted, user-controlled content: uploaded objects, presigned URLs, and (in future) potentially browsable/static content. This is a problem because domain reputation systems operate at *registrable domain* granularity, not subdomain:
These endpoints serve untrusted, user-controlled content: uploaded objects, presigned URLs, and (in future) potentially browsable/static content. This is a problem because domain reputation systems operate at _registrable domain_ granularity, not subdomain:

- **Blocking blast radius.** A single user uploading illegal content or hosting phishing pages via any regional provider can get `fil.one` flagged by Google Safe Browsing, ISP/national DNS blocklists, and corporate proxies. This would take down the console, website, docs and company support email in one shot — for all regions.
- **Independent operators.** Each region is run by an independent entity with its own abuse handling and response times. Fil One cannot guarantee how quickly any given region remediates abuse, yet today all regions and Fil One itself share fate through the one domain.
Expand All @@ -28,9 +28,9 @@ This is a well-established pattern: AWS serves user data from `amazonaws.com`, n

## Design

1. **Register a dedicated data domain** — proposed: `filone.com`. Regional S3 endpoints become `<region>.s3.filone.com` (e.g. `eu-west-1.s3.filone.com`).
1. **Register a dedicated data domain** — adopted: `filonecontent.com`. Regional S3 endpoints become `s3.<region>.filonecontent.com` (e.g. `s3.eu-west-1.filonecontent.com`).
2. **Nothing but user data lives on this domain.** No console, no marketing pages, no email. Publish a null MX and restrictive SPF/DMARC records so the domain cannot be used to send mail.
3. **Add the domain to the [Public Suffix List](https://publicsuffix.org/).** With `filone.com` (or `s3.filone.com`) listed as a public suffix, browsers treat each subdomain as an independent site — cookies cannot be scoped across subdomains, and reputation systems that respect the PSL (including Safe Browsing) can flag an individual subdomain rather than the whole domain.
3. **Add the domain to the [Public Suffix List](https://publicsuffix.org/).** With `filonecontent.com` listed as a public suffix, browsers treat each subdomain as an independent site — cookies cannot be scoped across subdomains, and reputation systems that respect the PSL (including Safe Browsing) can flag an individual subdomain rather than the whole domain.
4. **Migration.** Presigned URLs sign the `Host` header, so existing `*.s3.fil.one` URLs cannot be redirected (a redirect changes the host and breaks the SigV4 signature). Regional providers serve **both** domains during a deprecation window at least as long as the maximum presigned URL expiry, with `fil.one` endpoints removed thereafter. Console, docs and SDK-generated endpoint URLs switch to the new domain immediately.

## Alternatives Considered
Expand All @@ -39,11 +39,6 @@ This is a well-established pattern: AWS serves user data from `amazonaws.com`, n
- **PSL entry on `s3.fil.one` without a new domain.** Helps cookie isolation, but many blocklists and filters key on the registrable domain regardless, so `fil.one` remains exposed.
- **A separate domain per regional operator.** Maximum isolation between regions, but fragments the product experience, complicates SDK/endpoint configuration, and multiplies domain operations overhead. Could be a future refinement on top of this proposal.

## Open Questions

- Is `filone.com` the right domain?
- PSL scope: list `filone.com` itself or `s3.filone.com`?

## Evaluation Criteria

- A reputation incident on the data domain (simulated or real) has zero impact on `fil.one` availability, search listing, or email deliverability.
Expand Down