Two origins

Fermium hosts content other people wrote, some of it made by agents, some of it meant only for one company. The design assumes every document is hostile and every link will be forwarded. The first line of defense is the browser's own same-origin policy.

The split

A request for /d/, /x/ or /w/ on the app host is redirected to the content host. A request for anything outside that list on the content host is a 404 (on a custom domain the bare root redirects to the wiki). This is enforced at the outermost layer of the server, before any route runs.

Everything on the content surface follows the same rule about user content: /x/ only redirects to /d/; the wiki's pages are neutral pages Fermium renders, and an HTML document shown inside the wiki is loaded in a sandboxed frame from its own /d/ address rather than inlined. Uploaded icons are validated on upload and served with the same sandbox policy as any published file.

Why a separate registrable domain

If a published page ran on the same origin as the app, its JavaScript could read the app's cookies and call the API as whoever is viewing. A sandbox header alone would prevent that, but a header can be missed; the hostname split makes the model hold even then.

A separate registrable domain, rather than a subdomain of fermium.app, matters for three more reasons:

• Reputation systems (Safe Browsing, mail filters, corporate proxies) score a registrable domain as one site. Abuse on the content domain does not taint the app, sign-in emails or the marketing site. GitHub, Google and Anthropic use the same pattern with githubusercontent.com, googleusercontent.com and claudeusercontent.com.
• Cookies and browser site isolation are scoped per registrable domain. SameSite, Domain= cookies and storage partitioning treat fermium.app and fermiumusercontent.app as unrelated sites.
• A phishing page under a hostname that ends in the product's own domain is more convincing than one under a generic content domain.

Cookies never cross

The app session cookie is host-only on fermium.app, HttpOnly, Secure, SameSite=Lax, and prefixed __Host- so a browser refuses to accept it from anywhere else. The content host has its own short-lived viewer cookie with the same properties. When a Restricted document needs proof that the reader signed in, the app host issues a one-time code that expires in 60 seconds; the content host redeems it and sets its own cookie. No cookie is ever readable from both sides. Details in Sign-in.

Custom domains behave like the content host

A verified customer hostname is treated exactly as fermiumusercontent.app, restricted further to that one workspace's documents. It never serves the app or sign-in, so your company's cookies on yourcompany.com are not exposed to published pages either, provided you use a subdomain rather than the apex; the server enforces that.

Requests that change state

State-changing calls to /api/..., /auth/... and the OAuth authorize endpoint are rejected when the request's Origin header is present and is not https://fermium.app. Together with SameSite=Lax this blocks cross-site request forgery. The credential-less OAuth endpoints (metadata, register, token, revoke) are intentionally open to any origin so browser-based MCP clients can drive the flow.

Search engines

Every page on the shared content host is served with noindex, nofollow, as a header and as a meta tag, and its /robots.txt disallows everything. That does not change. The one exception is opt-in: a workspace on a paid plan can mark its wiki indexable on an active custom domain. Even then only wiki pages of unlisted documents a person placed in the wiki become indexable, on that domain, with a sitemap; /d/ and /x/ stay disallowed and gated documents never carry indexing metadata.

What this does not do

The split does not make a document private. An unlisted link is readable by anyone who has it. Keep anything that must not travel Restricted, or protect it with a password; see Access.