Security model
Private Drive performs encryption and decryption on the customer device. Cloak stores ciphertext and cannot recover content without the customer's key material. Cloak Object instead terminates normal S3 requests at the gateway and encrypts objects before they reach the private storage layer.
These models protect against different threats. Private Drive reduces what a compromised service or compelled operator can reveal about file contents. Object gateway encryption limits exposure at the storage layer but does not protect plaintext from the gateway itself.
Control boundaries
- TLS for browser, client, and S3 traffic in transit
- Session cookies that page scripts can't read, sent only over HTTPS, and expire within 30 days
- Random 16-digit account numbers instead of names, email addresses, or reusable passwords
- Per-account authentication rate limits and separately protected administrator access
- Scoped Object credentials, one-time secret display, and revocation
- Randomized storage-layer identifiers and encryption before physical storage
What encryption does not solve
- A stolen account number, unlocked device, recovery key, API key, or share link can authorize access
- Malware on your device can read files before encryption or after decryption
- Traffic timing, approximate object size, billing, and request metadata may still exist
- Recipients can copy shared data before a link is revoked
- Availability failures and software defects can still cause interruption or data loss
Customer checklist
Report a vulnerability
Email [email protected] with the affected hostname or component, steps to reproduce, expected impact, and a safe proof of concept. Cloak's email is handled by a third-party provider that can read plaintext message content, so encrypt anything sensitive with the public key at cloak.uno/pgp.txt before sending. We aim to acknowledge reports within three business days and provide a substantive status update within ten business days; these are targets, not a bounty or payment promise.
Research safe harbor
Good-faith research is authorized when it stays within accounts and data you control, avoids privacy violations and service disruption, uses the minimum data necessary to prove the issue, and gives us a reasonable chance to remediate before publication. Do not use phishing, denial of service, physical intrusion, employee targeting, automated high-volume scanning, or access to another person's data.
We will not pursue legal action against research that follows these rules. This safe harbor cannot authorize conduct against third-party systems or excuse violations of applicable law.
Security disclosures
Security claims on this page are limited to the controls and boundaries described here. Audit reports, penetration-test summaries, and remediation notes are published with their scope, date, assessor, exclusions, and resolution status.