share Built so we cannot read your files.
Encryption happens in your browser before anything is uploaded, and the key travels only inside the link you send. This page explains exactly what that means, including the few places where it does not apply.
What our servers see
Enough to deliver the file and show you its activity. Nothing that opens it.
| The encrypted file and its size | Stored | |
| When a link was created, opened and downloaded | Stored | |
| Addresses you choose to email a link to | Stored | |
| A label you add, if you add one | Stored | |
| What a file request asks for: its form questions and the names on its checklist | Stored | |
| The file name, type or contents | Never reaches us | |
| The key in the link, after the # | Never reaches us | |
| A share or secret password, or any hash of it | Never reaches us | |
| What people send you through your file requests | Never reaches us |
How the encryption works
Standard, well-reviewed building blocks, run by the browser's own Web Crypto and libsodium.
Files
A random 256-bit key per share. AES-256-GCM in 4 MiB chunks, each bound to its position and to whether it is the last, so a chunk cannot be dropped, reordered or swapped. The name and type are encrypted separately; several files sent as one link travel as one stream, with their names and sizes in an encrypted list. Previews (a gallery for several files, one picture for a single photo or video) are made in the sender's browser and encrypted with the same key. On plans with full activity, the recipient's browser tells us which files it downloaded by their number in that list, so we learn how many were downloaded, never their names. Files shared into the installed app from Android's share menu stay on the phone until they are encrypted, like any other files you pick, with one exception listed below.
The link
The key is written after the #. Browsers never send that part of a web address to a server, and our pages set no-referrer so it does not leak to other sites either. A QR code of a link is drawn in your browser from the link itself. Expiry reminders never contain the link: we never had it, so a reminder can only tell the recipient which email to look for. When a link is kept for your team, its key reaches us only locked to your workspace's key, which we cannot open.
Passwords
Argon2id (64 MiB, three passes) and HKDF turn the password and the link key into a key that wraps the file key. We never receive the password or a hash of it.
File requests
What people send is encrypted to your workspace's public key (X25519). Only a browser unlocked with the encryption password of someone with access, or with the encryption recovery code, opens it.
Your workspace's key
Each person chooses an encryption password, which locks a key pair of their own in their browser (Argon2id, 64 MiB, three passes). The workspace's key is locked to the key of each person with access and to the owner's encryption recovery code. What people send you, and the key of each link kept for your team, are locked to it. We store only the locked copies and never receive a password. The password is what holds them: someone who stole our database and guessed a weak one would open what that person can open, so choose a long one.
Checked keys
A browser, or the command-line tool, locks a link's key or asks for replies to the workspace's key only after it opened that key once with the person's password and checked that it matches, and it remembers it. A key swapped on our servers is refused, so it would capture nothing. Upload links carry the workspace's key after the #, as file requests do.
People you name
A share can open only for the people you name, each after entering a code sent to their own address, so a forwarded link opens nothing. People you name can also reply with files through their own link: the reply is encrypted in their browser to the key your browser put inside the share's encrypted details, so we cannot swap it.
Delivery certificates
Your browser works out each file's fingerprint as it encrypts it, keeps it inside the encrypted details, and gives us only a commitment to the list of files that we cannot check any file against. Each step of a delivery to a person you name is a statement our server signs, and once a minute a timestamp service stamps a digest of the minute's statements: it receives that digest and nothing else. A certificate made in your browser can be checked by anyone on the verify page, without us. The keys we sign with are also listed in our DNS records, which are kept apart from our servers, and the verify page checks them there too.
Signature requests
The PDF is encrypted in the sender's browser and uploaded once, with where each person signs sealed under the same key. A signer's browser opens it with the key in their invitation, rebuilds the document from the original and the signatures before theirs, checks it is exactly what the last signer signed, and sends back only what they entered, encrypted, with a commitment to the signed copy. We see who was asked, in what order and when each step happened, never the document or a signature. The completion certificate is checked on the verify page like a delivery certificate.
Secrets
A secret is encrypted the same way and deleted on the last allowed opening. People you name must confirm their email address with a code first.
AI assistants and the command-line tool
The command-line tool encrypts on your machine with the same code as the browser. Your AI assistant gets a link without the key, never the file or the value.
Where the key, or a file, can pass through
All but the last are something you choose, and each of those is marked in the app when you choose it.
- Emailing a link from the app. The full link crosses our server once to be mailed and is never stored or logged. Or send the key separately: the email carries the link without its key, the recipient's page asks for the key, and you give it to them another way, so no mailbox or Slack ever holds it. A Business workspace can require that.
- Posting a link to Slack. The link, key included, ends up in Slack, just as an emailed link ends up in a mailbox.
- Form requests set to “readable by the API and AI assistants”. Answers are encrypted to a key our server holds, so the API can return them. The request tells people so.
- ID checks. Didit, which runs the check, sends its result to our server, where it is read once and locked to your workspace's key the moment it arrives. We keep no readable copy, and Didit then deletes the session. Assistants and the API see only whether a check passed.
- Sharing into the Android app after its site data was cleared. Files shared from Android's share menu normally stay on the phone until they are encrypted. If the app's site data was cleared and the app has not been opened since, Android sends the files to our server instead. The server answers at once without keeping, logging or passing them on, and the app asks you to share again. Opening the app once puts it right.
Where data lives
Everything stays in the EU. Encrypted files on paid plans are stored with OVHcloud in Germany, with Cloudflare R2 under EU jurisdiction held in reserve, and Free plan files on servers we operate in the EU. The API and database run on servers in the EU too. Enterprise workspaces can keep files in their own S3-compatible bucket.
| Sub-processor | Purpose | Location |
|---|---|---|
| OVH Hosting Limited (OVHcloud) | Object storage for encrypted files on paid plans, which your browser uploads to and downloads from directly | Germany (EU) |
| Cloudflare, Inc. | Edge network, firewall, DNS and TLS for the service and customer domains; the bot check on sign-in and on public file requests (Turnstile); object storage (R2, EU jurisdiction) for encrypted files on paid plans, used instead of OVHcloud when we switch new uploads to it | EU data storage; global edge |
| Paddle.com Market Ltd | Merchant of record: checkout, invoicing, VAT, refunds | United Kingdom |
| Scaleway SAS (Transactional Email) | Transactional email: sign-in and confirmation codes, the links and file requests people ask us to email, reminders, receipts and notices | France (EU) |
| Hetzner Online GmbH | Hosting of the API and database, and object storage for encrypted Free plan files (a storage service we run on Hetzner servers) | Germany / Finland (EU) |
| Slack Technologies, LLC | Notices to our own team: new accounts and the changes support makes to accounts, with email addresses shortened to their first letter and domain | United States |
| Didit Identity Spain, S.L. (Didit) | ID checks: checking an identity document, a selfie, sanctions and politically exposed persons lists, and a proof of address, for the workspace that asked | Spain (EU) |
The full terms are in the data processing agreement and the privacy policy.
Operations
Transport
TLS everywhere, HSTS, and a strict Content Security Policy with no third-party scripts on download, secret and request pages.
Access
Production is reachable by the operator only, over a private network, and every administrative action is written to a log. The operator console requires two-step sign-in.
Your account
Sign-in is a code sent by email or, once you turn on two-step sign-in, the code from any authenticator app instead, so someone who gets into your mailbox cannot get into Share by DeltaBreen. Workspaces on Studio and above can require it of everyone. The app's setup code is stored encrypted and only read to check a code. Business workspaces can also sign their people in through their own company login (single sign-on over OpenID Connect); it confirms who someone is and never sees a file or a key. The one account that signs in with a password is a review account we make for an app directory's reviewers, at a random address of ours: its password has at least sixteen characters, is kept only as an Argon2id hash, opens no file or key, and ten wrong ones in a day pause it. We switch it off when the review is done, which signs it out everywhere.
Deletion
Files are deleted when a link expires, reaches its download limit or is deleted, with storage lifecycle rules as a backstop.
Malware and abuse
We cannot see files, so we cannot scan them for viruses. Instead every recipient page names the account that sent the link, warns before a program, a macro document or a web page is opened (judged in the browser from the decrypted name), and carries a Report abuse link. A person reviews every report; nothing is removed automatically.
Status
Every part of the service is checked once a minute. The status page shows how each part is doing now and its uptime over the last 90 days.
Found a problem?
Email contact@deltabreen.eu with the details and steps to reproduce. To report a link that carries malware or anything illegal, use the report form.