Privacy by architecture, not by promise.

When you drop a file into the upload area, the first thing the page does is generate a fresh 256-bit symmetric key using your browser's crypto.getRandomValues() call. This is a cryptographic random source backed by the operating system's entropy pool — the same source that generates TLS session keys for every HTTPS connection you make.

The key never leaves the browser. We have no network call that could carry it out, and no JavaScript path that sends it to our servers.

// In your browser, before any upload begins:
const fileKey = await crypto.subtle.generateKey({
  name: "AES-GCM",
  length: 256
}, true, ["encrypt", "decrypt"]);

// This key now exists only in JavaScript memory.
// It is not transmitted to Nullsend. Not now, not ever.

We split each file into 4 MB chunks and encrypt them one at a time. Each chunk gets a fresh 96-bit initialisation vector (IV) generated the same way as the key. The chunks are encrypted with AES-256 in GCM mode (Galois/Counter Mode), which is the standard authenticated cipher used in TLS, SSH, and virtually every modern protocol that handles real data.

Why authenticated encryption matters: GCM doesn't just hide the plaintext; it also produces a 128-bit authentication tag with each chunk. When your recipient decrypts, the browser verifies the tag and refuses to produce output if the ciphertext was tampered with. An attacker who modified bytes on our storage layer would cause decryption to fail, not produce garbled output.

Filenames are encrypted with the same key into a separate metadata blob, so even the names of your files aren't visible to us.

// For each 4 MB chunk:
const iv = crypto.getRandomValues(new Uint8Array(12));

const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  fileKey,
  chunkPlaintext
);

// Upload ciphertext + iv to storage.
// Plaintext is discarded from memory.

The encrypted chunks stream directly from your browser to S3-compatible object storage in Amsterdam, using presigned URLs that our backend issues but never sees the data of. We use multipart upload so that a 5 GB transfer doesn't have to start over if the network blips on chunk 12.

What our backend sees: the size of each ciphertext chunk, the order they arrive in, your tenant ID, when the transfer was created, when it should expire. What we don't see: any plaintext, the filename, the file key, your recipient's identity (only their email if you chose to use our delivery option).

Storage is in the European Union — specifically, our object storage provider's EU-Central region, in Amsterdam. Ciphertext doesn't leave the EEA.

The share URL we hand back looks like this:

https://acme.nullsend.io/d/a7b2c91d#k=jK4r...base64KeyHere...Qx9

The part after the # is the URL fragment. Fragments are a web standard that browsers never include in HTTP requests. When your recipient clicks the link, their browser asks our servers for the transfer at /d/a7b2c91d — but the #k=... part stays in the browser's address bar and is read directly by the page's JavaScript to perform decryption locally.

We log requests for transfer IDs. We never see the keys, because the keys are in fragments, and fragments don't travel over the network to us. This isn't a policy — it's how every browser since the 1990s has worked. Verify it: RFC 3986, section 3.5.

If a password was set on the transfer, the URL has #p=1 instead of the key, and the recipient is prompted for the password. The password is stretched with Argon2id (memory-hard, slow on purpose) into a wrapping key that unwraps a server-stored, encrypted copy of the file key. We still never see the password or the file key — only the encrypted form, which is useless without the password.

Every transfer has an expiry timestamp. Our deletion worker runs every 15 minutes, finds expired transfers, and deletes the ciphertext objects from storage plus the metadata row from the database. The deletion is logged with a transfer ID and timestamp — no content, no recipient details, just an audit trail that the deletion happened.

Tenants can set the account-wide default expiry within their plan's ceiling (7, 30, or 90 days), and a sender can override it per transfer. There's also an option to force-expire one hour after first download — useful for genuinely one-time deliveries.

All production system access requires hardware MFA (Yubikey or equivalent). No SSH passwords, no static credentials in code or environment files. Database access is via short-lived tokens scoped to specific operations. Production data is never accessible to support staff for debugging — when troubleshooting requires data access, it goes through a tenant-consented session token that's logged, time-limited, and auditable.

The server-side keys we use for non-file metadata (tenant email lists, SMTP credentials) are rotated quarterly. They're stored in a dedicated key management service, not in the application database. Per-tenant keys are derived using HKDF from a master key plus tenant UUID, so a tenant-level key compromise doesn't extend to other tenants.

We don't store, rotate, or escrow per-transfer file keys — we never have them in the first place. There's nothing to rotate.

Before public launch, Nullsend will commission an independent web application penetration test from a UK or EU-based testing firm (chosen so data accessed during testing stays in the EEA). The summary report will be available to Enterprise customers under NDA.

Nullsend maintains a documented incident response plan covering detection, containment, eradication, recovery, and notification. In the event of a personal data breach, notification to the relevant supervisory authority (ICO for UK customers, the lead supervisory authority for EU customers) is sent within 72 hours per GDPR Article 33. Affected tenants are notified directly within the same window.

Transfer ciphertext is stored in multi-AZ object storage with built-in durability of 99.999999999% per object (eleven nines). Metadata is backed up nightly and retained for 30 days. We do not back up plaintext anywhere, ever — there is no plaintext to back up.