docs: add a Certifications & Trust page (FIL-895) - #28
Conversation
The website's Compliance LP tells procurement reviewers to "check docs.fil.one for current status" and no such page existed — a reader following that instruction landed on a docs site covering only encryption, authentication, and API keys. New security/compliance.mdx states the status plainly, using the same wording as the website's ComplianceLandingPage.tsx so the two surfaces cannot drift: no SOC 2 Type II, no ISO 27001, no third-party attestation of any kind, both actively pursued. Adds the shared-responsibility split (which determines what any future certification could actually cover), what a procurement team can request today, and an explicit list of what Fil One does not claim. Kept independent of the Data Deletion page (FIL-894) so the two can be reviewed and merged in either order — deletion/account-closure semantics are referenced via the FAQ and Trial & Billing pages, which exist on main today. Worth retargeting those links at Data Deletion once both have landed.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Same treatment as the Data Deletion page. The old version led with what Fil One lacks and stated the no-attestation fact twice, then closed on a four-item "what Fil One explicitly does not claim" list. Every fact was accurate but the page read as a disclosure notice rather than a compliance posture. Restructured: - Certification status now leads with the work in progress (SOC 2 Type II and ISO 27001 actively pursued), then states plainly that neither is held and there is no third-party attestation. Stated once, not twice. Dropped the self-deprecating "rather than leaving you to guess from this page's revision date". - New "Controls in place today" table, promoted near the top: authentication, multi-factor, access-key scoping, encryption, WORM retention. This is the substance a procurement reviewer is looking for and it was previously buried in a single dense bullet halfway down. - Shared responsibility kept (it is what determines what any future certification covers), with the key-custody and cipher consequences folded into one prose paragraph instead of two negative bullets. - "Who to ask" split out so the routing is findable. - The four "does not claim" bullets consolidated to two scope statements: proof-of-storage is a network property, and named regulations are use cases rather than certifications. No fact dropped. Also removed every em dash from the page and its mirror sections per the house style, using commas, colons and parentheses instead.
Prompted by comparing against Wasabi's compliance docs, which turn out to
document their Compliance mode WORM feature and name no certifications or
regulations at all. That is a different genre from this page, and the
comparison surfaced a naming collision we have and Wasabi does not.
1. Renamed the page. "Compliance" already names a specific Object Lock
retention mode in Fil One ("Compliance mode binds every caller, including
the account owner"), so a docs reader searching for "compliance" hit two
unrelated things: a retention mode under Storage and a certifications page
under Security. "Certifications & Trust" removes the collision and is the
more accurate title, since the page covers certification status, shared
responsibility and scope of claims rather than any compliance feature.
2. Added a disambiguation callout pointing WORM/immutability readers at
Object Lock.
3. New "Demonstrating a control is in force" section, borrowed from Wasabi's
"Checking for Immutability" idea. Auditors want evidence rather than a
statement that a feature exists, and this was the one genuinely useful
thing the page lacked. Lists what a customer can produce themselves:
GetObjectRetention, GetBucketObjectLockConfiguration, GetObjectLegalHold
and GetBucketVersioning, plus a reproducible 403 on deleting a retained
object. Region-scoped honestly (GetObjectLegalHold is confirmed in
us-east-1 only) and notes the reads need selectable key permissions.
No redirect needed: the old /security/compliance URL never shipped, since
this page has only ever existed on this branch.
filipagr
changed the title
Updated after comparing against Wasabi's compliance docsWorth recording what that comparison showed, because it changed the page. Wasabi's compliance section is not about certifications at all. The landing page is a stub; the real content is sub-pages documenting their Compliance mode feature (bucket-level WORM immutability). They name zero certifications and zero regulations in their docs, describing the technical capability instead and keeping trust material off the docs site entirely. That precedent doesn't override FIL-895, since the reason this page exists is that our own website tells reviewers "check docs.fil.one for current status." But it surfaced a collision we have and Wasabi doesn't, plus one thing worth borrowing. 1. Renamed: Compliance & Certifications → Certifications & Trust
So a reader searching "compliance" in our docs hit two unrelated things, and the sidebar showed Object Lock under Storage next to a "Compliance & Certifications" page under Security. The new title removes the ambiguity and is more accurate anyway: the page is about certification status, shared responsibility and scope of claims, not about a compliance feature. File moved to 2. Disambiguation calloutA note near the top sends WORM/immutability/legal-hold readers to Object Lock. 3. New section: "Demonstrating a control is in force"Borrowed from Wasabi's "Checking for Immutability". Auditors want evidence, not an assertion that a feature exists, and this was the one genuinely useful thing the page lacked. It lists what a customer can produce themselves:
Plus the point that a failed delete is itself reproducible evidence ( Still open from earlier: whether that Google Doc is the intended source for this page. I built from this issue's description and have not seen it. |
1 participant
Closes the FIL-895 dangling pointer. Independent of the FIL-894 Data Deletion PR (#27) — targets
maindirectly, builds standalone, and the two can merge in either order.Why
ComplianceLandingPage.tsxon the website tells procurement reviewers to "check docs.fil.one for current status" — and no such page existed. Anyone following that instruction landed on a docs site covering only encryption, authentication, and API keys.New
docs/security/compliance.mdx:ComplianceLandingPage.tsx:275rather than paraphrasing, so the two surfaces can't drift: no SOC 2 Type II, no ISO 27001, no third-party attestation of any kind, both actively pursued.Please sanity-check two things
security@fil.one— taken from the issue text; I have not verified the mailbox exists. It appears three times.Independence note
Kept deliberately free of links to the Data Deletion page from #27 — with
onBrokenLinks: "throw", linking to a page that doesn't exist onmainyet would fail the build if this merged first. Deletion and account-closure semantics are referenced via the FAQ and Trial & Billing pages instead. Once both PRs have landed, those links are worth retargeting at Data Deletion — happy to do that as a one-line follow-up.Verification
npm run buildsucceeds againstmainllms.txtandllms-full.txtsecurity/data-deletion, so this stands aloneWhichever of #27 and this merges second will hit a trivial adjacent-line conflict (both add one line to the Security block in
sidebars.jsand a section to the same spot in the mirrors).🤖 Generated with Claude Code