The short version

Dropshare encrypts every file in your browser before it ever reaches our servers. We don’t hold the keys, we don’t read the contents, and we delete the encrypted blob after 24 hours. For most GDPR purposes, there simply isn’t much personal data for us to process on your behalf.

What GDPR actually asks of a file-sharing service

The General Data Protection Regulation is, at heart, a law about accountability. Whoever decides why and how personal data is processed has to be able to explain it, protect it, and honour the rights of the people it belongs to. For a traditional file-sharing service, that gets complicated quickly: the provider can usually see your files, keeps them indefinitely, links them to an account, and often layers analytics on top. Each of those decisions becomes a thing you and your Data Protection Officer have to account for.

Dropshare was designed the other way round. Instead of adding privacy features on top of a service that sees everything, we tried to build a service that sees as little as technically possible. Files are encrypted with AES-256-GCM in your browser using a key generated locally. That key is placed in the URL fragment — the part after the # — which browsers never send to servers. What reaches us is an opaque encrypted blob, a size, and a timestamp. After twenty-four hours, that blob is gone.

The practical consequence is that a lot of GDPR’s machinery, which exists to keep providers honest about data they can read, doesn’t really apply to data we can’t.

How the data-subject rights play out in practice

When someone exercises their Article 15 right of access, a normal provider has to trawl through logs, profiles, file contents and metadata. With Dropshare there is no account, no profile, no record of who uploaded what. The only copy of the decrypted file lives on your device and on whatever device you chose to share the link with. Rectification (Article 16) and portability (Article 20) work the same way — the file is yours, edited and exported by you, not by us.

Erasure (Article 17) is where the architecture is most obviously helpful. Encrypted objects are deleted automatically after twenty-four hours, and because we never had the key, even the backup copies that might briefly exist in storage are cryptographically unreadable. There is no deletion workflow to trust because there is no long-term retention to undo.

The right to object (Article 21) and the right to restrict processing (Article 18) are likewise simple: stop using the service and nothing of yours remains with us beyond that 24-hour window.

Our role under the Regulation

If you are a controller uploading personal data belonging to your users, customers, or patients, we act as a processor for the limited technical operations involved in storing and transmitting the encrypted blob. Because we have no access to the plaintext, our processing is narrow by design. The lawful basis you rely on toward your own data subjects is your decision; our job is to make sure the infrastructure underneath doesn’t quietly widen the scope of that processing.

We keep the minimum technical data that a working service requires: the encrypted file itself, the upload timestamp needed to expire it, and request-level information such as IP addresses, which are used for rate limiting and abuse prevention and are not tied to any user profile. We do not run analytics on user behaviour, we do not set tracking cookies, and we do not sell, rent or share data with advertisers, because there is no usable data to share.

Transfers, hosting and jurisdiction

Cross-border transfers are a perennial GDPR headache, largely because ordinary personal data moving from the EU to a third country may lose the protection of the Regulation. Strongly encrypted data, where the recipient has no means of decryption, is widely treated as a very different kind of material — the risk to the data subject is governed by the maths, not by the jurisdiction of the server. That doesn’t make the legal conversation disappear, but it does make it much shorter. The infrastructure that holds encrypted blobs is just that: infrastructure.

Where Dropshare is not the right tool

We want to be honest about the limits. Dropshare is built for transient sharing, not for archival storage, long-term collaboration, or regulated record-keeping where you are required to retain documents and audit trails for years. If your obligations demand that kind of retention, you will need a system designed around it, and Dropshare can at most be a secure transport layer alongside it. Similarly, because we cannot see the content, we cannot moderate it; that responsibility stays with you as the uploader.

Using Dropshare in a compliant workflow

For most teams, adopting Dropshare as part of a GDPR-aware workflow looks like this: you upload a file, hand the resulting URL to the intended recipient through a channel you already trust, and let the link expire. There is no account to provision, no DPA annex listing sub-processors who see plaintext, and no backlog of old files quietly accumulating. If your organisation requires a written data-processing agreement for the narrow role we play, we’re happy to provide one — but in most cases the technical description above is what your DPO actually wants to read.


Questions about using Dropshare in a regulated European context? The Privacy Policy and Terms cover the specifics, and you can always start with a real file at dropsha.re.