What ZipPigeon handles
ZipPigeon needs some delivery details to work: account emails, recipient emails, timestamps, file sizes, transfer status, download counts, audit events, IP addresses, user agents, and abuse-prevention signals.
Security
How ZipPigeon protects your files
See how ZipPigeon protects files before upload, what the service still handles, and where the current limits are.
What stays out of reach
File contents are encrypted in the browser before upload. Raw file keys, private account keys, recovery codes, and secure-link URL fragments should not be sent to the server during normal use.
Technical security details
The current browser envelope uses chunked XChaCha20-Poly1305 for file data, encrypted manifests, Ed25519 manifest signatures, random payload keys, and recipient-specific key envelopes. Password-protected private-key bundles use Argon2id parameters from the shared crypto format.
How account sharing works
Account recipients have public keys for encrypted sharing and signatures. Browser-created account shares can tie the recipient, key fingerprint, encrypted key envelope, upload, and expiration into a signed grant. Recipient key substitution and key transparency remain important future hardening areas.
How secure links work
Secure links are useful for quick guest access. They are bearer access: anyone with the full active link may be able to open the transfer. Link unlock material is carried in the URL fragment during normal use, so the server should not receive that fragment in ordinary HTTP requests.
Apple Shortcut boundary
The current iOS Shortcut convenience path is server-assisted: shared Shortcut input may be fetched, transformed, or staged by ZipPigeon before the signed-in browser approves and encrypts the final transfer. Use browser upload for the strict client-side-encryption path until Shortcut-side encryption ships.
Revocation and deletion limits
Revocation, expiration, and archive stop future service-mediated access. They cannot recall files already downloaded and decrypted. Archived transfers attempt encrypted-object deletion, and operational records or backups may remain for security, reliability, or abuse-response needs.
Metadata boundaries
Encryption protects file contents, not every surrounding detail. Metadata can include account email, recipient routing, timestamps, file size, title, transfer state, download counts, IP address, user agent, and audit events. Keep secrets out of filenames, notes, and recipient labels.
Abuse scanning boundary
A strict unreadable-file model limits server-side content scanning. Anonymous sends use blocked high-risk extensions and browser-side checks before encryption; deeper malware analysis would require an explicit privacy tradeoff.
Audit status
ZipPigeon has security smoke tests and documented crypto design notes. It should not be described as SOC 2, HIPAA, ISO 27001, or independently audited until those assessments are completed for the deployed service.
Still on the roadmap
ZipPigeon does not yet include public key transparency, hardware security modules, enterprise SSO enforcement, custom enterprise branding, bring-your-own storage or database, data residency guarantees, formal compliance attestations, customer-managed keys, or post-quantum recipient key wrapping.
Vulnerability reports
Send security reports to security@zippigeon.com with affected routes, reproduction steps, impact, and synthetic evidence where possible.
Send the file. Keep control of the link.
Use ZipPigeon when a file needs to reach the right person without becoming another attachment or shared folder to clean up later.
Open signed-in sender