Available now
A person can send an encrypted file to another person without creating an account. The sender prepares the package in the browser, receives a one-time link, and shares that link through their own channel.
- Anonymous one-time sends: 50 MB total, 5 files, 80 encrypted parts, one download, and a 24-hour maximum expiry by default.
- Anonymous default expiry: 6 hours unless the sender chooses a shorter or longer allowed window.
- Anonymous file policy: high-risk executable, script, installer, and active-content extensions are blocked before upload.
No sender history or audit trail
Anonymous sends should not appear in a sender dashboard because there is no sender account. They should not promise durable audit history, verified recipient identity, or recoverable management controls. Limited operational and abuse-prevention records may still exist so the service can protect itself and users.
Short-lived limits
Anonymous transfers use conservative defaults: small package sizes, short expiration windows, one-time download access, and cleanup for abandoned encrypted uploads. Signed-in transfers remain the path for larger files, repeat recipients, revocation management, recovery, and recordkeeping.
Encryption and one-time link
The browser should encrypt the file before upload and place the recipient unlock material in a one-time link or fragment-based flow so raw keys are not sent through normal server requests. The server should enforce expiry, download grants, and cleanup without needing readable file contents.
File validation
Anonymous uploads should be checked before encryption wherever possible. The first phase should include blocked high-risk extensions, MIME and extension mismatch warnings, archive-size heuristics, script and macro risk warnings, filename normalization, and clear limits for executable or active-content files.
Human checks and abuse controls
Anonymous sharing should include human verification, abuse scoring, reputation checks, per-IP quotas, upload throttles, and suspicious-download challenges before increasing anonymous upload and download capacity.
Before raising limits
The product should keep clear UI warnings, documented limits, edge enforcement, browser-side validation, cleanup jobs, operational metrics, and an abuse response path before raising anonymous limits. A narrow live flow is safer than a broad no-login upload service.
