Logo

Security & Privacy Whitepaper (Overview)Chapter 12

Chapter 12: Third-Party Verifiable Evidence & Status Page

Beyond our internal design claims, FileBolt provides publicly reproducible third-party evidence (Evidence) to verify visible security properties (such as TLS configuration, security header policies, etc.). This chapter defines evidence types, applicable scope, entry links, and principles for mapping evidence to Claim IDs.

12.0 Summary

  • SHOULD: Provide public, reproducible third-party evidence links to verify visible security baselines (TLS, headers, etc.).
  • MUST: Evidence links point only to authoritative sources, never to screenshots or secondary reposts.
  • MUST: Explicitly define the scope of evidence: external scans cannot directly verify full Zero-Knowledge/E2EE implementation details.
  • SHOULD: Use the Status Page to aggregate evidence links, while Claim Evidence fields should point directly to the original third-party source.

12.1 Evidence Types & Scope

12.1.1 What Can Be Verified

Third-party evidence typically verifies:

  • Transport Layer Configuration: TLS versions, certificate chains, cipher suites, HSTS, etc. (dependent on scanner capabilities).
  • HTTP Security Policies: Existence and basic configuration of headers like CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.
  • Publicly Visible Web Surface: Common misconfigurations, exposed endpoints, and baseline security scores.

12.1.2 What Cannot Be Directly Verified

Third-party evidence typically cannot directly verify:

  • Zero-Knowledge Correctness: E.g., "Server cannot access CEK," client-side encryption flows, and key derivation details.
  • Internal Operations & Access Control: E.g., internal permissions, key management workflows, log sanitization, and access auditing.
  • Absolute Security: Scans only cover their specific rule sets and visible surfaces; they do not replace continuous security engineering and incident response.

Therefore, this whitepaper distinguishes between "visible security baselines" and "protocol/implementation boundaries": Visible baselines are verifiable via Evidence; Zero-Knowledge/E2EE boundaries are governed by protocol specifications and client constraints (see Chapter 5 and related sections).

12.2 Status Page as Aggregation Hub

FileBolt uses /status as the aggregation hub for evidence links. It does not replace the third-party reports themselves but provides unified navigation for users and auditors to perform repeated verification.

  • MUST: Evidence links on the status page point to authoritative third-party sources (reproducible).
  • SHOULD: The status page may indicate "Last Checked Date/Timestamp," but should not present this as a permanent, immutable conclusion.
  • SHOULD: If specific paths (e.g., download/decryption pages) employ stricter headers, path-level evidence may be provided on the status page (if supported by third-party tools).

12.3 TLS Configuration Evidence

TLS evidence verifies HTTPS configuration, protocol versions, certificate chains, and visible attributes. Examples include:

Note: TLS evidence reflects visible configuration at the "time of scan"; it does not prove end-to-end content boundaries nor whether the server can access the CEK.

12.4 Security Headers Evidence

Security header evidence verifies the existence and configuration of baseline policies like CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, etc.

Recommendation: If download/decryption pages (e.g., /transfer, /d/**) use stricter policies, internal documentation should note "Critical paths are stricter," and where feasible, tools supporting specific path scans should be selected as supplementary evidence.

12.5 Comprehensive Best Practice Scans

Comprehensive scans cover broader best practice checks (e.g., HTTP configuration, common weaknesses, caching & security policy combinations). These provide auxiliary verification for site baselines but are not equivalent to protocol implementation audits.

12.6 Mapping Principles: Evidence & Claim IDs

  • MUST: Every verifiable claim (Claim) has a unique ID and stable anchor in the Master List of Claim IDs.
  • MUST: The Evidence field of a Claim points only to authoritative sources (third-party report pages or official reproducible pages) and MUST NOT point to screenshots, summaries, or non-authoritative reposts.
  • SHOULD: The Status Page may serve as a "navigation collection" for Evidence, but the primary Evidence field of a Claim should point to the original third-party source whenever possible.
  • MUST: Claim wording must align with the scope of the evidence, avoiding overstating "visible baselines" as "absolute security guarantees."

Master List of Claim IDs (Sole Authority): /security-privacy-appendix-claim-ids

12.7 Temporality & Normative Language

Third-party scan results change over time (due to scanner rule updates, site configuration changes, certificate rotation, etc.). References to Evidence should use "verifiable but not absolute" phrasing.

  • SHOULD: Record the "Last Verified Date/Time" (if applicable) on the status page or documentation and allow users to perform repeat verification.
  • MUST: Avoid "permanent/absolute" wording; use language matching the evidence scope, such as "Scan indicates enabled/compliant."
  • SHOULD: When critical security policies change (e.g., CSP tightening, TLS updates), record this in the Changelog and link relevant Claim IDs.

12.8 Related Claim IDs (Reserved)

This chapter covers "Third-Party Evidence & Mapping Principles." Corresponding Claim IDs are maintained in the Appendix: Master List of Claim IDs as the sole authoritative source.