ravendrop Share a secret

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.

Public security overview

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.

URL fragments are not sent in ordinary HTTP requests. They can still leak through history, sync, screenshots, forwarding, or the platform where someone pastes the complete link.
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.

03 / Links meet automation

What happens when something other than a person opens the link

Share links get pasted into chat apps, ticket systems, and AI assistants. Most automated readers cannot reach a secret. The one that can is the one a person handed the whole link to.

Cannot reach the secret

Crawlers, link previews, and scanners

  • The key and capability live in the URL fragment, which browsers do not send in HTTP requests. A fetcher receives the page and no key material.
  • Link unfurlers and security scanners that follow the URL get the same static page every visitor gets before any secret is loaded.
  • Fetching a share link does not spend a view. Opening the page only checks the envelope; the view is consumed by an explicit reveal.
  • Referrer-Policy: no-referrer keeps the link out of the request headers of anything the recipient opens next.
Can reach the secret

An assistant given the complete link

  • Pasting the full URL into a chat assistant puts the decryption key into that assistant's context, and usually its logs.
  • A browser-driving agent can press reveal like a person can. That spends a view and decrypts the content.
  • A passphrase delivered through a separate channel still holds. The agent has the link; it does not have the other factor.

ravendrop cannot detect this or undo it. Once a key has been pasted somewhere, the only remedy is to revoke the share and send a new one.

04 / 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.

05 / Evidence

How the design is verified

Continuous verification

Security properties under test

  1. 01Encryption checks cover key derivation, ciphertext integrity, and rejection of incorrect key material.
  2. 02Access capabilities follow a narrowly defined transport and storage boundary.
  3. 03Invalid access context is rejected before any protected view can be consumed.
  4. 04Concurrency, revocation, and policy changes are tested as security behavior—not merely application logic.
Assurance before release

Private verification record

  1. ACryptography and key-lifecycle behavior are reviewed against the published security boundary.
  2. BSupported browsers and devices are validated for compatibility and safe operating characteristics.
  3. CProduction data flow, logging, and infrastructure boundaries receive environment-specific verification.
  4. 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.