PsiDriveWeb Crypto creates the key and authenticated encrypted chunks before upload.
What PsiDrive protects—and where your choices still matter.
PsiDrive encrypts file content in the browser, keeps the transfer key out of backend storage, and applies short retention to guest transfers. This page explains those controls without treating any system as absolutely secure.
AES-256-GCMAuthenticated chunksPrivate R2 storageShort-lived upload URLs
The transfer boundary.
The sender's browser generates a random AES-256-GCM key, encrypts the filename and file chunks, and uploads ciphertext. The complete share link places the key after the # character. Browsers do not include that fragment in normal HTTP requests, so the API receives the transfer token but not the key from the link.
The service stores encrypted objects and the metadata required to deliver and expire them.
The recipient browser reads the complete link, verifies each chunk, and reconstructs the file.
Assets, actors, and trust boundaries.
The primary assets are the plaintext file, encrypted filename, transfer key, optional password, complete share link, account credentials, and encrypted R2 objects. The design assumes Cloudflare can serve the application code and ciphertext correctly, while the sender and recipient devices are trusted to handle plaintext.
| Actor or system | Can normally observe | Should not receive |
|---|---|---|
| Sender device | Plaintext, generated key, complete link | Nothing beyond what the sender selects |
| PsiDrive API and storage | Transfer metadata, ciphertext, quotas, expiry state | The URL-fragment encryption key |
| Recipient device | Complete link and decrypted file | Other users' transfers |
| Person given the complete link | Everything necessary to attempt that transfer | Access after expiry or deletion |
Important: the complete transfer URL is a bearer secret. Key separation protects against the backend storing the key; it does not protect a link that is copied to the wrong person, captured by malware, or exposed through an unsafe communication channel.
Application and infrastructure safeguards.
Production responses use a Content Security Policy, frame denial, MIME-sniffing protection, referrer controls, and restricted browser permissions.
Turnstile validation, request-size limits, method restrictions, quotas, and Cloudflare rate controls reduce automated abuse and unexpected cost.
Passwords use salted PBKDF2-SHA256 hashes with an upgraded work factor. OTP and session flows are handled by the API rather than exposed in file links.
Threats the design does not remove.
- Malware, malicious extensions, or a compromised browser may see plaintext before encryption or after decryption.
- Someone who obtains the complete share link may be able to decrypt the file while the transfer remains active.
- Traffic analysis can reveal that a transfer occurred, its approximate size, and timing even when contents remain encrypted.
- A service compromise that changes the delivered application code could target future users; browser encryption is not a substitute for trustworthy code delivery.
- Optional transfer passwords add authorization but do not repair a leaked link or compromised endpoint.
PsiDrive has not claimed an independent security audit or a regulated-data certification. Do not use the current service for information that requires a specific contractual or compliance framework.
Security reporting.
Review the responsible-disclosure policy, then use the dedicated security report form or email security@psidrive.com. The public security.txt lists both monitored intake paths.
Do not submit passwords, OTPs, encryption keys, complete transfer URLs, private file content, or destructive proof-of-concept payloads. Start with a minimal description and an email address if follow-up is required.