Secure View

Problem

Most file-sharing tools assume the recipient ends up with a copy. For sensitive documents, that's often exactly what you don't want: people should be able to view something without easily walking away with it, and every access should be logged. That's not something you can bolt onto a normal file-sharing app after the fact. It has to be the starting point.

My role

I built this end to end: the FastAPI API, auth and data model on Supabase, encrypted object storage on Cloudflare R2, the encryption scheme itself, audit logging, and a native Android client with the platform-level protections needed to make view-only actually mean something.

Architecture

Clients authenticate against the API. Files are encrypted server-side with an envelope-encryption scheme before they land in Cloudflare R2, so the object storage only ever holds ciphertext. Keys and metadata live behind Supabase and Postgres, with row-level security where it matters. The Android client renders content for viewing only, using FLAG_SECURE to block screenshots and basic root detection to reduce tampering risk, while the server logs every access for an audit trail.

Technical highlights

• Server-side envelope encryption, so object storage never holds plaintext.
• A native Android client built around FLAG_SECURE and root detection for genuinely view-only sharing.
• Audit logging on every access, so sharing isn't a black box after the fact.
• Clear separation of concerns across FastAPI, Supabase, and R2: API logic, auth and access policy, and encrypted storage each stay in their own lane.