Our security architecture, in plain English

Every cloud provider has a security page. Most of them are the same three sentences about AES-256 and "industry-leading practices." Here's ours, written for someone who wants to understand what's actually happening to their files, not pass a procurement checklist.

Encryption at rest, AES-256

Every file you upload is encrypted with AES-256 before being written to storage. AES-256 is the same algorithm that protects U.S. government Top Secret data — a sufficiently strong attacker would need longer than the age of the universe to brute-force a single file.

Each file gets its own encryption key. The keys are stored separately from the files. Compromising one without the other gets the attacker nothing.

TLS 1.2+ in transit

Every request between your device and our servers is wrapped in TLS 1.2 or higher, with HSTS forcing HTTPS-only access. The certificate chain rolls automatically — no manual renewals, no expired-cert outages.

Row Level Security: the database itself enforces access

Most apps check "is this user allowed to read this file?" in application code. That works until someone forgets to add the check to one route. We use database-engine Row Level Security so the database itself refuses to return rows that belong to other users — regardless of what the application asks for.

This is defense in depth. Even if an attacker found a SQL injection or a missing permission check, RLS still returns zero rows.

Authentication: TOTP MFA + biometric app lock

• Passwords are hashed with bcrypt — never stored or logged in plaintext.
• Two-factor authentication via TOTP (compatible with 1Password, Authy, Google Authenticator). No SMS — SMS 2FA is vulnerable to SIM swap.
• iOS app lock with Face ID / Touch ID, plus a PIN fallback. Sessions invalidate everywhere when an account locks.

Share links can't be brute-forced

Password-protected share links use bcrypt (not SHA-256) and lock out after 5 failed attempts in 15 minutes. The link IDs themselves are 128-bit random — unguessable. We wrote a separate post on that architecture; the short version is: nobody is grinding through a dictionary against your share link in a weekend.

Soft delete, then hard delete

When you delete a file, it goes to Trash and stays there for 30 days (you can purge sooner from the UI). After 30 days a background job permanently removes both the database row and the underlying storage object. The hard-delete pipeline is idempotent — orphaned blobs get swept on a daily reconciliation pass.

Account deletion removes all user data within 30 days, satisfying both GDPR and CCPA requirements.

No AI training on customer files

Your files are not part of any training dataset. Not now, not under a future model upgrade, not "anonymized for research." This is contractual — see Section 3 of the Privacy Policy.

CSAM scanning on public links

Public share links — links visible to people outside your account — are scanned for CSAM before being made accessible. This is required by 18 U.S.C. §2258A and the scan happens against image hashes, not file content. Private files in your drive are not scanned.

What happens if we get breached

Honest answer: any company that promises "this can't happen" is lying. What we can promise is the response:

• Detection: we monitor failed-auth rates, anomalous storage access patterns, and database query anomalies.
• Containment: encryption keys can be rotated workspace-by-workspace without re-encrypting files (we re-wrap the per-file keys).
• Notification: affected users get email within 72 hours of confirmed unauthorized access, per GDPR Article 33.

What we deliberately don't do

• We don't read your files. The encryption keys are scoped per-file and per-user.
• We don't sell metadata. There's no internal "data products" team.
• We don't run third-party ad SDKs. The only analytics is Google Analytics 4, page views only.

Cloud storage that respects users isn't a complicated formula. It's a pile of small "no" decisions accumulating into a coherent product.