E2EE fundamentals
End-to-end means the service is not an endpoint.
Encryption is not automatically end-to-end encryption. The decisive question is who can obtain the content key. In Sharebox, the sender and intended recipient control the secret needed to recover the raw file key; storage and delivery providers do not.
Encryption happens at the endpoint
Plaintext is encrypted in the sender browser before any file bytes reach Sharebox or R2.
Keys stay outside storage
R2 stores ciphertext. Supabase stores a wrapped file key, not the raw file key or transferable secret.
The secret is separated
The URL fragment containing the transfer secret is created in the sender browser and is not included in the request sent to Sharebox or Resend.
Decryption happens at the endpoint
The recipient browser unwraps the file key and decrypts authenticated chunks locally.
Encryption at rest is not enough
Traditional cloud encryption often protects disks using keys controlled by the provider. That is valuable against stolen hardware, but the provider can still invoke those keys and process plaintext.
E2EE changes the trust boundary. The infrastructure transports and stores encrypted material, but it lacks the endpoint secret required to turn that material back into content.
What E2EE does not solve
E2EE does not make an unsafe file harmless, protect an already-compromised endpoint, prevent a recipient from redistributing plaintext, hide all traffic metadata, or recover a lost transfer secret. Honest security includes these limitations.