Security architecture

Security Architecture

PrivShare is designed so that plaintext share contents and private decryption keys are not sent to the PrivShare server during normal share creation and retrieval.

Normal Share Flow

Encryption happens before upload. Decryption happens after authorized ciphertext retrieval.

SENDER
  |
  | plaintext
  v
+----------------+
| Browser Crypto |
| Web Crypto API |
+-------+--------+
        |
        | ciphertext
        v
+----------------+
| PrivShare      |
| server         |
+-------+--------+
        |
        | stores ciphertext
        | and approved metadata
        v
Database / encrypted blob storage

DECRYPTION KEY
  |
  v
URL fragment
#key=...
  |
  v
RECIPIENT
  |
  v
Browser decrypts

Server Boundary

The server is still trusted for availability, lifecycle enforcement, metadata handling, and JavaScript delivery. It should not need plaintext share contents to perform those jobs.

Plaintext share secrets, plaintext files, plaintext share passwords, and private decryption keys are not sent to the server in implemented share workflows.

Server receives ciphertext

The share APIs receive ciphertext, IVs, lifecycle settings, protection metadata, kind, owner ID when signed in, and approved operational metadata.

Server does not receive fragment keys

Fragment-key share links carry the private decryption key after #key=. URL fragments are not sent in HTTP requests.

Storage is not plaintext storage

The database stores encrypted payloads. Private S3 storage is used for encrypted file blobs only.

Recipient emails are keyless

Recipient notification emails contain /s/[id] links only. They do not include URL fragments, passwords, plaintext, signed file URLs, or wrapped-key metadata.

Service-Visible Metadata

Not all metadata is encrypted. Anything service-visible must be treated as non-secret.

Lifecycle state, expiration, burn-after-reading setting, share kind, timestamps, and owner ID where applicable.
Dashboard labels, folder names, and tag names for owned shares. These are disclosed metadata and must not contain secrets.
Encrypted file object keys used internally for private S3 ciphertext storage and cleanup.
Safe owner analytics event types and timestamps, without read, viewed, or decrypted receipt claims.

Protection And Limits

The architecture is useful because it is specific about both sides of the boundary.

Designed To Help With

Database compromise exposing stored share rows without the full fragment URL or password.
Database administrators reading stored share payloads without browser-held keys.
Network interception that sees TLS-protected traffic plus already encrypted share payloads.
Recipient email provider access to notification messages, because emails carry keyless links only.

Not Designed To Solve

A full fragment URL is a decryption capability.
A recipient can copy, screenshot, forward, or exfiltrate decrypted plaintext.
Compromised sender or recipient devices are outside the app boundary.
Malicious browser extensions may access page contents depending on their permissions.
Browser memory, OS swap, translation tools, accessibility tooling, and clipboard behavior cannot be fully controlled by the app.
A malicious or compromised PrivShare deployment could serve modified JavaScript.

Keep reading

Explore the rest of the security documentation

Every security page links to the others so you can move through the full model without using the browser back button.

Back to security overview