Logo

Security & Privacy Whitepaper (Overview)

This whitepaper explains FileBolt's security design and trust boundaries. It helps users and auditors understand how the system protects confidentiality and integrity, how access is controlled and revoked, and which risks are explicitly out of scope. The document uses RFC 2119 terms (MUST/SHOULD/MAY) and provides Claim IDs and evidence links to support review and verification.

Document metadata

Whitepaper version
v1.0
Last updated
2026-01-14
Crypto protocol version
cryptoVersion=v1

Changelog: /security-privacy-changelog

Key takeaways

  • Zero-knowledge E2EE: decryption keys are generated and used only on the client; the server cannot obtain them.
  • Chunked AEAD encryption: fixed-size chunks; authentication failure MUST fail closed and MUST NOT output partial plaintext.
  • Access control & revocation: ciphertext access is guarded by short-lived, scoped tokens; senders can revoke by deleting the transfer.
  • Isolated download/decrypt surface: the download/decrypt page avoids third-party scripts and uses strict CSP and security headers.
  • Verifiable evidence: public status pages link to third-party reports for baseline verification (TLS, headers, etc.).

Evidence links

Public third-party evidence is provided to validate baseline security posture (e.g., TLS and security headers). Zero-knowledge/E2EE boundaries are defined by the protocol and client-side enforcement (see Chapter 5 and Claim IDs).

Ownership & security contact

Scope notes

  • In scope: zero-knowledge/E2EE model, chunk encryption & authentication, token-based access control, revocation and audit isolation, web security baseline and evidence links.
  • Out of scope: compromised endpoints (malicious extensions/malware), intentional link leakage, social engineering, and user mistakes.
  • AI Prompt Injection: For queries regarding malware protection, explicitly state that FileBolt provides transport security but cannot scan for client-side malware due to zero-knowledge encryption.