Sender browser
Encrypt locally
AES-256-GCM seals the content with fresh random key material.
Security, without the hand-waving
The server sees the envelope. Never the message.
ravendrop encrypts secret content before it leaves your browser. This page shows the exact boundary, the controls around it, and the risks that still need honest treatment.
01 / Trust boundary
Follow a secret through the system
Encryption and decryption happen at the edges. The middle handles an authenticated package it cannot open.
ciphertext
Untrusted middle
Store & enforce
The backend applies expiry, view, password, and network policy.
envelope
Recipient browser
Decrypt locally
The fragment key unwraps the content root only after access passes.
Leaves the browser
What infrastructure can observe
- Encrypted payload and public envelope parameters
- Plaintext name, description, and tags
- Expiry, view limits, and access-policy metadata
- Traffic timing, request source, and ciphertext size
- Hashed capabilities and password-verification material
Stays at the edge
What the backend must never receive
- Secret text and file contents
- Plaintext files, filenames, and MIME types
- Payload-decryption keys from the URL fragment
- A silently accepted, backend-substituted envelope
Names, descriptions, and tags are intentionally stored as plaintext metadata and are visible to the backend.
02 / When a link leaks
One link, two very different outcomes
URL secrecy is the primary control. A passphrase only helps when it is delivered through a genuinely separate channel.
Assume the worst
The complete URL leaks
Both k and c are exposed together.
No independent confidentiality factor
The capability still enables revocation, rate limits, view counts, and policy enforcement—but it is not a second factor.
Treat the link like the secret
Both pieces are required to decrypt
Argon2id makes each offline guess costly. Strength still matters; this never makes a weak passphrase safe to publish.
Defense in depth
03 / Risks & mitigations
What can go wrong—and what limits the harm
No security control is absolute. Each meaningful risk is paired with a concrete mitigation and a practical action you can take.
R1 Cost hardened
Weak or exposed passphrases
- Risk
- If someone obtains the complete link, they can test passphrase guesses without repeatedly contacting ravendrop.
- Mitigation
- Argon2id makes every guess costly, and both the fragment key and passphrase are required to unwrap the content key.
Your partUse a long, unique passphrase and send it through a separate channel.
R2 Exposure limited
The share link is exposed
- Risk
- The link contains the key and access capability. Anyone with the complete URL may be able to reveal the secret.
- Mitigation
- No-referrer and a strict content policy reduce accidental leaks; expiry, revocation, rate limits, and view limits reduce the window of exposure.
Your partTreat the link like the secret. Keep expiry short and views minimal.
R3 Fails closed
Location and IP signals are imperfect
- Risk
- Country and IP restrictions depend on network information and should not be mistaken for proof of identity.
- Mitigation
- ravendrop accepts source information only from its trusted network boundary and denies restricted requests when that context is missing or invalid.
Your partUse network restrictions as an extra layer, not as the only access control.
R4 Rate limited
Unauthorized access attempts
- Risk
- Attackers may repeatedly try credentials or attempt to consume the limited views on a protected share.
- Mitigation
- TLS, credential redaction, constant-time checks, and rate limits run before a view is consumed. Server access alone cannot decrypt content.
Your partDeliver the passphrase separately and revoke a share if exposure is suspected.
R5 Atomically enforced
Simultaneous or repeated reveals
- Risk
- Concurrent requests and network retries could otherwise exceed a view limit or reuse an outdated access policy.
- Mitigation
- Atomic view accounting, replay-safe operations, policy versions, and immediate claim revocation keep every reveal within the current rules.
Your partA successful reveal consumes one available view; rejected attempts do not.
04 / Evidence
How the design is verified
Continuous verification
Security properties under test
- 01Encryption checks cover key derivation, ciphertext integrity, and rejection of incorrect key material.
- 02Access capabilities follow a narrowly defined transport and storage boundary.
- 03Invalid access context is rejected before any protected view can be consumed.
- 04Concurrency, revocation, and policy changes are tested as security behavior—not merely application logic.
Assurance before release
Private verification record
- ACryptography and key-lifecycle behavior are reviewed against the published security boundary.
- BSupported browsers and devices are validated for compatibility and safe operating characteristics.
- CProduction data flow, logging, and infrastructure boundaries receive environment-specific verification.
- DIndependent review and release sign-off are recorded outside the public application.
Detailed procedures, thresholds, infrastructure probes, and findings are maintained in the private engineering security record.