How AnonDrop protects your data
Written for the person who has to sign off on us. Everything below describes what the platform actually does today: how files are encrypted and stored, how the API is authenticated, what we keep, and what we are able to hand over if somebody asks.
Encryption and the key hierarchy
All files are encrypted on our servers. Key management and decryption are handled server-side, through a hierarchy of seeds in which each layer only ever unlocks the next one.
- Your user key seed is sent to the server, which derives a public key from it.
- That public key addresses your user-specific database, which holds your encrypted file key seeds.
- Each file key seed resolves to a public key that decrypts a file's metadata and the list of its chunks.
- The chunk list carries a further set of seeds, and those resolve to the public keys that decrypt the actual encrypted chunks at their storage addresses.
The practical consequence is that possession of one layer does not grant the layers above it. A file key seed opens that file and nothing else; it does not reveal the user key seed it came from, and it does not reveal any other file.
The same design also constrains us. Because we never hold the user key seeds, we have no way of linking a specific file back to a specific user. That is deliberate, and it is why our answers in the data requests section below are as short as they are.
The derivation steps are documented in full, with runnable code, on the recreate decryption key page.
How files are stored
A file is encrypted first, then split into chunks, and the chunks are distributed across storage nodes rather than being written to any single place.
On top of that we run erasure coding in a 14+4 configuration: the encrypted file is encoded into 14 data fragments plus 4 parity fragments, 18 in total, held on 18 different storage nodes. Any 14 of those 18 rebuild the original, so four nodes can fail simultaneously with no data loss, and a download completes from the surviving fragments while the missing ones rebuild.
Because the encryption happens before the fragmentation, a single node holds an encrypted fragment of an encrypted file and nothing more. An attacker would need to compromise at least 14 separate drives before they even had enough data to attempt to break the encryption. The mechanics are laid out on the erasure coding page.
Your bytes are stored and served back untouched. We never re-encode, repack or rewrite what you send us, so what comes back out is byte-for-byte what went in.
Malware scanning without human review
All uploaded files are scanned for malicious content. The process is automated and does not involve human review of your files, and the contents of your files are not stored or logged during it. Files identified as malicious are removed.
Scanning is a safety control for the platform, not a content review: nobody at AnonDrop opens your data to look at it.
Network privacy and logging
We have a strict no-log policy. We do not log IP addresses, user agents, or any other personally identifiable information. We do not use cookies or any other tracking technologies.
The site operates through proxy services, so client IP addresses are not exposed. That is a structural protection rather than a policy one: the address never reaches a place where it could be retained.
Usage figures shown to paid accounts are counters and nothing more, holding bytes stored, bytes transferred and request totals. Key activity is recorded only to the day, never as a request log. There is no per-request record behind the numbers to subpoena, export or leak.
Controls on the paid API surfaces
Pro and Business add an S3-compatible API, access keys, private objects and webhooks. Each of those brought a specific control with it.
Access key secrets are encrypted at rest and shown once
When a key is minted, the secret is displayed a single time, at that moment. What we store is an encrypted form of it, sealed with a purpose-specific key and authenticated so that a tampered record can never yield a usable secret. The plaintext is never displayed again; a lost secret is replaced by revoking the key and minting a new one.
Requests are authenticated with AWS Signature Version 4
Your secret never travels in a request. Each call carries a signature computed from a signing key that is itself chained through the date, the region and the service, so the material that goes over the wire is scoped to a single day and a single region and service pair even if it is captured. Both the header and presigned forms are supported, and a mismatch is refused with a standard S3 error that reveals nothing about why.
Keys are scoped, and revocation is immediate
A key can be restricted to named buckets and marked read-only, so a key handed to a build agent cannot delete anything or touch a bucket it was not given. Revoking a key stops it resolving, so the next request signed with it is refused.
Presigned links expire
A presigned URL carries its own validity window and is bounded twice: the requested lifetime may not exceed seven days, and the link is refused outright once its start time plus that lifetime is in the past. There is no way to mint a presigned link that never expires.
Per-object passwords are stored as PBKDF2 hashes
When you put a password on an object, we keep a salted PBKDF2-HMAC-SHA256 hash of it, stretched over 120,000 iterations, with a fresh random salt per object. The password itself is never written down, so it cannot be read back out of storage by anyone, ourselves included.
Webhook deliveries are Ed25519 signed
Every event we POST to an endpoint you register carries an Ed25519 signature over the canonical JSON of the payload, sent in an X-AnonDrop-Signature header alongside the public key and algorithm used. The body posted is exactly the canonical JSON that was signed, byte for byte, so your receiver verifies it without re-serialising anything. Webhooks are signed with a key used for webhooks and nothing else, published at /webhookpubkey, with worked verification examples in Python and Node on the developer documentation. Checkout callbacks are signed with a separate key published at /checkoutpubkey, so neither key can vouch for the other's messages and a signed event can never be presented as a signed payment.
Per-plan request limits
Every account has a per-minute request allowance, so no single key can exhaust the API for everybody else. Exceeding it returns a standard slow-down response rather than disabling the key.
What we can and cannot provide
Because we store no personally identifying information about site visitors, there is very little we could produce even if we wanted to. Being precise about that is more useful to an evaluator than a promise.
What we can do
- Remove content on a valid notice, and lock the file key so the link stops resolving. The content policy and DMCA page sets out what a notice must contain.
- Confirm whether a given link is still live or has been taken down.
- Act on reports of the content categories our content policy prohibits.
What we cannot do
- Produce a per-request history of who fetched what. Usage is metered as counters only, so there is no request log to export.
- Identify the person behind an upload. Your user key seed is the only thing that links you to your files, and we do not hold it.
- Tie files together by owner, or block a user across their uploads. Our privacy-by-design architecture removes that ability along with the data it would need.
- Decrypt a file for a third party who does not hold the corresponding key seed.
- Hand over billing identity. There is no card on file, no billing address and no name attached to a plan.
These limits are the same ones stated in our Terms of Service and Privacy Policy, and they apply to everyone equally.
Responsible disclosure
If you have found a vulnerability, we want to hear about it before anyone else does. Write to [email protected] with enough detail to reproduce the issue: the endpoint or page, the request, what you expected and what happened instead. A proof of concept helps.
- Please give us a reasonable window to ship a fix before publishing.
- Test against data you own. Do not access, modify or retain other people's files, and stop at the point where a finding is demonstrated.
- No denial of service, no spam, no social engineering of anyone, and no automated scanning heavy enough to degrade the service for other users.
- Reports made in good faith under these terms are welcome, and we will tell you what we did about them.
Security questions that are not vulnerability reports are welcome at the same address.
Related reading: erasure coding, the key derivation chain, privacy policy and the FAQ.