What SlothBox is, and why it exists.

SlothBox is an EU-hosted, end-to-end encrypted file transfer service. Drop a file, get a link, send the link, your recipient downloads. The bit that's different: the server cannot decrypt anything you upload — the architecture itself prevents it, not a marketing promise.

Why this, and why now

WeTransfer scans your file and keeps a copy. Dropbox Transfer reads your content and runs through US infrastructure (Schrems II problem for EU users). ProtonDrive is end-to-end encrypted but paid, account-only, and has no quick-share for unauthenticated recipients. There is no good European, open-source, end-to-end encrypted file transfer with cryptographic delivery receipts. SlothBox aims at that gap.

Who built it

Hi — I'm Philip Sloth, a sole-proprietor developer based in Denmark. I build software where the security guarantees come from the architecture rather than a marketing page. SlothBox is one of two open-source reference builds I run alongside client work — the other is SlothCV, a free CV builder with similar trust-as-architecture discipline.

When this is the right tool

If the file is sensitive enough that you don't want WeTransfer keeping a copy on US infrastructure for seven days — but you also don't want to onboard the recipient onto a paid Proton account just to receive one document — SlothBox sits between the two extremes. Encrypted in your browser, EU-only data path, no recipient signup, gone after delivery.

If you're sharing a holiday-photo album with family, or a marketing-deck draft with the whole team, or anything where the recipients want a permanent shareable link they can come back to next month — SlothBox is the wrong tool. Use Dropbox, Google Drive, or whatever your workflow is built on. The encryption discipline here costs you the convenience of a permanent URL, and that trade only pays off when the file is actually sensitive.

What you give up

Every architectural decision trades something. SlothBox runs on one ARM virtual machine in Falkenstein, Germany — not a global edge network — so a one-gigabyte download from a Tokyo client takes longer than the same file from WeTransfer. Files have an expiry; there is no permanent shareable link. The recipient needs the complete URL including the part after “#”, which means a chat client that strips fragments breaks the share. And the v0.2 line has not been independently audited yet — the underlying primitives (libsodium, age) have, but the SlothBox glue around them is gated on external cryptographer review before any “production-grade” wording lands. Until v1.0, treat this as the working file-transfer tool it is: stable, hardened against URL-leak races, open source — but with the audit-pending caveat surfaced everywhere it matters.

Status

The v0.2 line closed the URL-leak race conditions called out in the v0.1 warning (per-share password, sender-revoke tokens, single-use chunk tokens). The cryptographic primitives (libsodium, age) are battle-tested upstream, but the SlothBox integration code has not yet been independently audited — external cryptographer review and a third-party pen test gate v1.0 before any high-stakes-secrets framing.

Why “sloth”

Sloth is my surname. I'm Philip Sloth — solo developer, the only contributor on this repo. The product carries my name because I'm the one accountable when the integration code is wrong. No corporation to point at, no team to share blame with. That's the whole brand.

Built on a single ARM Linux VM in an EU jurisdiction, with eight other people's open-source projects holding it up. See /security for the threat model.