share Privacy policy
Effective 22 October 2026 · DeltaBreen Limited (the operator of Share by DeltaBreen), a company registered in Ireland with company number 826627 and VAT number IE4835019QH, of Gorey, Co. Wexford, Ireland · contact@deltabreen.eu · Terms · Refunds · Privacy · Data processing agreement
This policy explains what DeltaBreen Limited collects when you use Share by DeltaBreen, why, and what we do with it. We are the controller for account and billing data. For the content people send through the service, the account holder is the controller and we are a processor that, by design, cannot read it.
1. What we cannot see
Files, filenames, text secrets and form answers are encrypted in your browser before they reach us, with a key that stays in the link, or is locked to your workspace's key, which only the encryption passwords of the people given access open. When a link is kept for your team, we store its key only in that locked form. We store ciphertext only and hold no key that opens it. We cannot read, scan, index or recover this content, and we cannot hand it to anyone else in readable form. There are exceptions, each something the sender chooses and marked where it is chosen, and the security page lists them all: request pages marked readable by the API or your assistant, for which the service holds the key in a sealed form; a link you ask us to email or post to Slack with its key, which crosses our server once to be sent and is neither stored nor logged by us; and ID checks, whose result reaches us readable from the identity provider and is locked to the asking workspace's key as soon as it arrives.
2. What we collect and why
| Data | Why | Kept |
|---|---|---|
| Email address, sign-in codes (hashed), session tokens, and which version of the terms you accepted and when | To open and secure your account (contract) | Until you delete the account, when the address is replaced by a placeholder; codes 24 hours |
| The bot check on the sign-in form and on public file requests (Cloudflare Turnstile): Cloudflare sees your IP address and browser signals to tell a person from a script | To prevent abuse (legitimate interest) | Nothing kept by us |
| Checking a certificate on the verify page: your browser asks a public DNS service (Cloudflare's, or Google's if that does not answer) for the records that list our signing keys. It sees your IP address and the name asked for, never the certificate or your documents | So anyone can check our keys without relying on our servers (legitimate interest) | Nothing kept by us |
| Two-step sign-in, where you turn it on: the authenticator's key in sealed form and one-way hashes of your recovery codes | To secure your account (contract) | Until you turn it off or delete the account |
| Your workspace: its name, members, roles and invitations (the invited address), branding and logo, web addresses of its own, rules, and the settings of services it connects (a mail server, storage, Slack, a company login provider), with their passwords and tokens in sealed form; for company login, the provider's identifier for each person | To run team workspaces as their owner set them up (contract) | Until removed, or with the account that owns the workspace |
| API keys (a hash of each), connected assistants, command-line sign-ins and connected websites: their names, what they may do, hashed tokens and a website's address | To let your servers, assistants and website act for your workspace (contract) | Until revoked; an expired or revoked connection's tokens 30 days more |
| Share records: sizes, expiry, status, timestamps, an optional label you chose to show us, encrypted metadata | To store, serve and delete your shares (contract) | Until expiry plus retention of the record for 90 days |
| Encryption keys in locked form: each person's key pair, its private half locked in their browser with their encryption password; the workspace's keys, locked to each person given access and to the recovery code; and the keys of links kept for the team, locked to the workspace's key. We cannot open any of them | So a team opens what it received and the links it sent, on any device (contract) | Until the person or workspace is deleted; a link's copy ends with its share |
| Receipts: when a link was opened, clicked, downloaded or replied to, a coarse browser family, and a one-way hash of the visitor's IP address | So senders can see what happened to what they sent (contract, legitimate interest) | With the share record |
| Recipient email addresses, when a sender asks us to email a link or names recipients, and when each confirmed their address with a code | To send the link and attribute receipts (contract) | With the share record |
| Real IP addresses of visitors to a share, and the country each came from, only where its sender turned that on; the page says so | The sender's legal or evidential need (the sender's legitimate interest as controller) | Addresses encrypted at rest; deleted with the share |
| File request settings as written, including form questions and the names of the items a checklist asks for; the addresses a request was emailed to, what each has sent by item, and the reminders sent | To show the request to senders, see what arrived and remind people (contract) | With the request |
| Signed delivery statements (Pro and above): when a share was sent, and when each person it names was sent their link, confirmed their address, opened it and downloaded it, with their address; a real IP address only where the share records them. Encrypted at rest; a fingerprint of a batch of statements, from which nothing can be read, goes to an independent timestamp service | So senders can prove delivery with a certificate anyone can check (contract; the sender's legitimate interest in evidence) | With the share record |
| Signature requests: the signers' email addresses and order; when each was invited, confirmed their address, opened the document, signed or declined, and reminders sent; each signer's IP address and browser with their signature, encrypted at rest; and signed statements of these steps. The document, where its fields sit, what each person entered and any reason for declining are encrypted with the document's key, which we never have. A request an AI assistant or your own code prepared waits unsent, with its signers' addresses, its name, the note for the invitations and what prepared it, and emails nobody until you send it | To run the request and give the sender and the signers a completion certificate (contract; the sender's legitimate interest in evidence) | The document until the request ends, and for 14 days after everyone has signed; the records with the document's record, 90 days after it is deleted; a prepared request that is not sent, with its document, 7 days after it was prepared |
| ID checks: the address of the person checked and what was asked; the result (name, date of birth, nationality, the document's details, how each check went, possible sanctions and politically exposed person matches, the address on a proof of address) and, only where the workspace keeps a copy, pictures of the document and the selfie, all locked to the workspace's key as soon as they reach us; the consent the person gave, and when | For the workspace that asked, as its processor; the explicit consent the person gives for their face, which is biometric data, is collected on its behalf | Until the workspace deletes the check or the account; Didit deletes its copy, face data included, once the result is locked away |
| Contacts and templates your workspace saves: names and email addresses, each contact's choices (such as always confirming their email), and saved settings with any note for the email, as written. A client or matter you add to what you send is encrypted with your workspace's key, which we never have | So your team can reuse addresses and settings, and find what it sent (contract) | Until your workspace deletes them, or with the account that owns the workspace |
| Request-page audit: visits, codes used, uploads and answers, hashed IPs | To let the page owner control access (contract) | 400 days, or with the page if deleted sooner |
| Workspace audit log: who did what in an account, through which door, with a hashed IP | Security and accountability (legitimate interest; contract on Business and Enterprise) | 400 days |
| Billing: plan, subscription status, trial dates, transaction totals and identifiers from Paddle | To run your subscription and our accounts (contract, legal obligation) | 7 years after the last transaction, as tax law requires |
| Usage and rate-limit counters, hashed IPs | To enforce plan limits and prevent abuse (legitimate interest) | Counters monthly; a rate window until it ends, a week at most |
| Operational logs and metrics: route, status, timing, request id; never link contents or keys | To run and secure the service (legitimate interest) | Logs 30 days; metrics 15 days |
| Emails we send: the address, only until our email provider has accepted the email (then its first letter and domain), the subject and the kind of email, never the body | To know what was sent and whether it arrived (legitimate interest) | One to two months; monthly counts after that |
| Notices to our own team in Slack: a new account, and each change support makes to an account from a support conversation, each with the address shortened to its first letter and domain; never a word anyone wrote | To run the service (legitimate interest) | As long as the team's message history |
| Support conversations: what you write to us and attach, our replies, your address and your plan, kept in Help by DeltaBreen, our own helpdesk, in the EU. When you write while signed in, support sees your account's details beside the conversation, read when they open it and kept by neither Help nor us, and a change support then makes to your account is in your workspace's activity log | To help you (contract) | 1 year after the conversation is closed |
| Abuse reports: the link reported (never its key), what the reporter wrote, their name and email if they gave them, a one-way hash of their IP address, and our decision | To act on reports of illegal content, as the EU Digital Services Act requires (legal obligation) | 400 days after the decision |
We do not use advertising, tracking pixels or analytics scripts, and we do not sell or rent your data or share it with anyone for their own purposes. We do not use your content or metadata to train machine-learning or AI models, and we use it only to provide, secure and bill the service and to meet our legal obligations. IP addresses are stored as truncated one-way hashes unless a sender explicitly enabled address recording for a share, which the recipient is told on the page. A workspace is shown such a hash only as a numbered place ("Place 2"), so that two visits from one network can be told apart; the number is kept beside the hash until no record holds it.
3. Where data is and who else sees it
Encrypted files on paid plans are stored with OVHcloud in Germany. If OVHcloud fails we may send new uploads to Cloudflare R2, in EU jurisdiction, instead; each file stays where it was first stored until it is deleted. Encrypted files on the Free plan are stored on servers we operate in the EU. When you upload or download a file, your browser connects straight to where it is stored, which sees your IP address and browser as any server you connect to does. The API and database run on servers in the EU. An ID check is carried out by Didit, in Spain, on its own page: Didit sees the person's document and face, and we never see the camera. Sub-processors we use, and where they process data, are listed in the data processing agreement; where a sub-processor is outside the EU we rely on an adequacy decision, the EU–US Data Privacy Framework, or Standard Contractual Clauses. Paddle sells the paid plans and is a controller in its own right of the payment details you give it; we never receive a card number. We disclose data to authorities only under a lawful order, and only what we hold, which for content is ciphertext.
4. Your rights
Under the GDPR you can ask for access to, correction of, deletion of, or a copy in a common format of the data we hold about you, ask us to restrict how we use it, object to processing based on legitimate interest, and complain to a supervisory authority: the one where you live, or in Ireland the Data Protection Commission. Most of this you can do yourself: the dashboard shows your shares and receipts, settings show your account, and deleting a share or your account removes the data within the retention periods above. For anything else, email contact@deltabreen.eu; we answer within one month. Note that we cannot decrypt content on request, including yours.
An email address is all you must give us to open an account; without one we cannot open it. Limits and protections against abuse (a limit reached, a bot check, a request paused after a burst of uploads) are applied automatically and only hold back an action until it is tried again or someone looks. We take no decision about you by automated means alone that has a legal or similarly significant effect: suspending or closing an account, and removing content, are decided by a person.
5. Recipients and senders
If someone sent you a link, they are the controller of what they sent and of the receipt they receive about your visit; we process it for them. The page tells you what the sender chose to record. If you sent someone a request page, the same applies in reverse. Email addresses typed by senders are used only to deliver the message and attribute the receipt. The page a link opens shows the email address of the account that sent it, so recipients can tell a real link from an imitation; senders are told so before they send.
If a workspace asked you to take an ID check, it is the controller of your data and decides why it needs the check and how long it keeps the result; we process it for that workspace, and Didit carries out the check on its own page. Before anything starts you are told who asked, what they will get and who does the check, and asked for your explicit consent, including for the use of your face, which is biometric data. The result reaches us once in readable form, because no browser of the workspace's is there to receive it, and is locked to the workspace's key the moment it arrives; we keep no readable copy and cannot read it again. Didit deletes what it holds, your face data included, once the result is locked away. To see, correct or delete what the workspace holds about you, ask the workspace; we help it answer.
6. Services you connect
If your workspace connects Slack, a mail server, storage or a company login provider of its own, or you connect an AI assistant, the command-line tool or your website, what you send through them is handled by those services under your own agreement with them. We pass them only what the connection needs: for example a link you post to Slack, an email your mail server sends for you, or the list of your shares an assistant asks for. They are not our sub-processors.
7. Security
Content is encrypted with AES-256-GCM in the browser with keys we never hold in a form we can use. Secrets the service must hold (SMTP passwords, storage credentials, server-readable keys) are sealed under a server key kept outside the database. Transport is TLS only. Access to production is limited to the operator, over a private network, with every administrative action logged. If a breach affects personal data we hold we will notify the Data Protection Commission within 72 hours and affected users without undue delay.
8. Cookies and local storage
The app keeps a session token and, on the device you uploaded from, the keys to your own shares in browser storage so the dashboard can show filenames and re-copy links, along with small working records such as an unfinished upload or your language. Nothing is set for tracking. The payment page loads Paddle's checkout, the bot check on the sign-in form and on public file requests loads Cloudflare Turnstile, and the support page, on an address of its own, loads the form of Help by DeltaBreen, our own helpdesk, each in a page of its own. The first two may store what they need to take a payment or tell a person from a script; Help stores nothing in your browser; and nothing else on the site loads code from anyone but us. Clearing site data removes all of it; links already copied keep working.
9. Aggregated data
We may create and keep aggregated or anonymised statistics — such as totals of shares, storage, error rates or capacity trends — that do not identify anyone, and use them to run, secure and improve the service. Because these cannot be linked back to a person, we may keep and use them without time limit.
10. Children
The service is not directed at children, and accounts are for people aged 18 or over. We do not knowingly collect personal data from a child under 16; if you believe a child has given us data, contact us and we will delete it.
11. Changes
We may update this policy as the service changes. We post changes here with a new effective date and, for a material change, tell account holders by email or in the app before it takes effect.