Logo

Security & Privacy Whitepaper (Overview)Chapter 8

Chapter 8 Privacy & Zero-Knowledge Design

This chapter clarifies the privacy boundary under FileBolt's zero-knowledge model: where secrets live (client only), what the server observes (minimal metadata), and how navigation/referrer behavior is controlled to avoid leaking key material.

8.1 Zero-knowledge boundary

  • Encryption/decryption and CEK generation happen on the client only.
  • The server handles ciphertext and public parameters and MUST NOT learn CEK.
  • Link sharing is the capability boundary: anyone with the full link (including fragment) can decrypt.

8.2 What the server can see

  • Operational metadata: transferId, chunk counts, sizes, timestamps, token validation events.
  • Minimal delivery evidence for senders (download counts/status) if enabled.
  • MUST NOT include fragments/CEK in logs or analytics; avoid storing raw filenames unless necessary.

8.3 URL fragment & referrer handling

  • CEK material MUST reside in the URL fragment (#), which is not sent to the server in HTTP requests.
  • Pages SHOULD use a strict referrer policy to avoid leaking URLs to third parties.
  • Clients MAY clear the address bar after parsing the fragment to reduce accidental leakage (UX-dependent).

8.4 Sender audit privacy boundary (not visible to recipients)

  • Audit/analytics data about a transfer is visible to the sender only by default.
  • Recipient pages MUST not expose sender-only analytics endpoints or tokens.

8.5 User best practices

  • Do not paste share links into public places; treat the full link as a capability.
  • Avoid opening links on compromised devices or with untrusted extensions.
  • Use passwords/limits when the sender needs additional access control beyond link secrecy.

8.6 Related Claim IDs