Status: Gate 3 design record approved 2026-07-26; R0 manifest/backup/cleartext baseline verified; later controls unverified

Reviewed: 2026-07-25

Current evidence: Threat model and controls only. No application, backend, policy, key, build, penetration test, dependency scan, emulator test, or device test exists.

This document defines the MVP security boundary. It is not a certification, vulnerability disclosure policy, incident-response program, or claim that the service is production-ready.

1. Another ordinary Android app cannot read app-private metadata/session/cache through supported platform access.
2. Account B cannot list, read, create under, modify, delete, or operate on account A's catalog or objects.
3. A guessed asset/object ID or path does not bypass account authorization.
4. The client never contains privileged backend credentials or permanent public object access.
5. Interrupted/repeated work converges without overwrite, duplicate visible assets, or false success.
6. Local disappearance cannot cause cloud deletion; cloud deletion cannot cause device deletion.
7. Session, upload capability, personal identifiers, media content, fingerprints, and paths do not enter routine logs or system backup.
8. Exact-original bytes are not parsed for GPS and are never described as E2E encrypted.
9. Destructive server operations are authenticated, idempotent, scoped, and recoverable after partial failure.
10. Compromise/failure is surfaced as blocked/stale/error state rather than silently optimistic status.

The MVP does not protect against:

• a rooted/compromised Android OS or malicious code running inside the app process;
• an attacker using an already-unlocked device/account session;
• screenshots or screen recording by the device user/OS;
• compromise, insider access, or lawful access at the managed backend/operator;
• traffic or data after it reaches an authorized endpoint/operator;
• password reuse/phishing outside the app;
• service availability, disaster recovery, legal hold, or production SLA;
• end-to-end/zero-knowledge encryption.

Android sandbox/device protection, TLS, Supabase authorization, operator controls, and the backend provider remain trusted boundaries.

• Legitimate signed-in Android user.
• Another account using a legitimate client.
• Malicious/modified client with its own or stolen user token.
• Another ordinary Android application.
• Network attacker.
• Backend/operator administrator.
• Developer/test operator.
• Dependency/supply-chain attacker.

Android UI process
  | app-private API boundary
Room/session/cache ---- Android Keystore
  | platform-provider boundary
MediaStore
  | TLS + user JWT
Supabase Auth/Data API/Storage/Functions
  | elevated server-only authority
private schema/objects/auth administration

Each boundary validates identity, ownership, state, and data shape again. UI hiding is never authorization.

• Store structured app data in internal app-private Room/database files.
• Store thumbnails/previews only in bounded app-private cache.
• Never persist a full original as an unbounded staging file.
• Exclude database, session, cache, mappings, queues, fingerprints, and fixture state from Auto Backup/device transfer.
• Clear account-scoped local data/cache on sign-out.
• Treat a corrupt database as uncertainty; require confirmation before reset and never imply remote deletion.

• Disable/bypass default backend-client persistence unless it delegates to the approved vault.
• Serialize only the minimum session material required for refresh.
• Encrypt a versioned envelope using AES-GCM with a non-exportable Android Keystore key.
• Generate a unique random nonce for every write and authenticate envelope metadata as associated data.
• Store ciphertext in noBackupFilesDir; never external/shared storage.
• Do not require biometric unlock because background work needs non-interactive refresh.
• On key invalidation, corrupt ciphertext, or version mismatch, erase local session material and require sign-in.
• Never persist the user's password.

The exact implementation receives focused cryptographic review and unit/device tests. No custom algorithm or hardcoded key is allowed.

• Request only the approved image/exact-original capabilities after contextual user action.
• Do not request all-files, video, fine/background location, camera, microphone, contacts, SMS, calls, or notification permission.
• Keep raw Uri, cursor, ContentResolver, bitmap, and Context types behind Android gateways.
• Use bounded streams; cancellation closes descriptors and network work.
• Never parse/index/log GPS from exact bytes.
• Derived cloud thumbnails remove source metadata.

Allowlisted release logs contain only coarse event/error enums and short-lived random correlation IDs. They exclude:

• filenames, paths, URIs, object keys, MediaStore IDs;
• account identifiers/email;
• fingerprints, EXIF, GPS, image bytes/thumbnails;
• access/refresh tokens, publishable configuration values, signed/resumable URLs;
• raw HTTP headers/bodies or backend exception bodies.

Debug builds follow the same media/credential rule. Network body logging is disabled.

• HTTPS/TLS only; release network security rejects cleartext.
• The client receives the project URL and publishable key through local build configuration, not source literals.
• Publishable keys are not treated as authorization; every private operation requires a user JWT and server/RLS check.
• Test and future production projects use separate keys, schemas/buckets, accounts, quotas, and operator access.
• No service-role, database password, management token, Edge Function secret, or signing key enters the client or repository.

• Enable RLS on every exposed table before grants/default privileges.
• Grant only required operations to authenticated users.
• Prefer authenticated functions that derive user identity from JWT instead of accepting a trusted owner parameter.
• Use unique account-scoped constraints for logical assets and operation idempotency.
• Normal catalog queries return verified state only.
• Exclusions and destructive operations are account-scoped and non-public.
• Function search path, role, and SECURITY INVOKER/DEFINER choice receive explicit migration review; elevated functions expose only fixed validated operations.

• One private bucket for originals/thumbnails in the MVP test design.
• Random server-issued IDs form paths under the authenticated user prefix.
• Client may create/select only within its prefix and only through required operations.
• Normal original upload is create-only; no x-upsert.
• Client DELETE/UPDATE is denied unless a later minimal policy is proven. Destructive cleanup uses authenticated server code.
• Authenticated downloads or short-lived signed access only; never permanent public objects.

• Canonical identity is computed before claim using a bounded accessible stream.
• Claim is idempotent and account-scoped; it returns existing verified state or a random reservation.
• Reservation/path/session is durable locally before upload reliance.
• Representation hash and byte count are computed during actual upload.
• Source snapshot stability is checked before finalize.
• Finalize validates JWT owner, reservation, object path, Storage presence, and byte size.
• Local Backed up follows successful remote finalize and atomic Room commit.
• Expired TUS URL reuses the semantic reservation/path; path conflict queries state rather than overwriting.

The current design does not claim a server-computed cryptographic checksum. Gate 4 records the actual provider guarantees and must update the claim if stronger verification is unavailable.

• Per-item deletion and account deletion use random operation IDs plus account-scoped idempotency keys.
• The server validates current user and target ownership on every retry.
• Per-item deletion removes representations/thumbnail/catalog and creates the canonical exclusion.
• Account deletion enumerates/removes only the authenticated account prefix/rows, records stage progress, then removes Auth identity last.
• Partial failure remains queryable and retryable.
• Operator reset is separately scoped to a disposable test project/account and refuses production identifiers.

• Apply backend object-size and per-account quota before production-like testing.
• One client upload per account limits accidental concurrency/cost.
• Auth and destructive actions require bounded retry/rate control.
• 403/RLS failure is not blindly retried; it fails closed for operator review.
• Quota failure remains visibly not backed up and resumes only after explicit revalidation.
• WorkManager/backoff prevents tight network retry loops.
• The MVP makes no availability, durability, disaster-recovery, or legal-retention guarantee beyond verified provider/project behavior.

• Use the smallest approved dependency set and official repositories.
• Pin versions in the version catalog and wrapper; add dependency groups one at a time.
• Enable dependency locking/checksum verification during Gate 4 if compatible with the scaffold.
• Review primary release notes and security advisories before upgrades and artifact handoff.
• Keep Gradle/local configuration, IDE files, keystores, env files, backend dumps, and generated credentials out of source.
• Inspect the final manifest, network config, resources, BuildConfig/generated constants, and APK strings for secrets/endpoints.
• Do not run unreviewed code-generation/install scripts with backend or signing credentials.

The proposed community supabase-kt client remains replaceable behind contracts. Direct Ktor TUS/REST is the first storage-client fallback; Firebase requires a separate owner decision.

• Disposable project and operator authority confirmed.
• RLS/storage policies reviewed before test data.
• Client contains publishable config only.
• Two non-personal accounts exist outside source control.
• Safe fixture/reference validation passes.
• Network body/credential logging disabled.

• Full two-account negative matrix passes.
• Interrupted/duplicate upload produces one verified asset.
• Reserved/orphan state is private and cleaned/reconciled.
• Session vault and backup exclusion pass.
• Manifest contains no unapproved capability.
• No unbounded media buffer/staging path exists.

• All TESTING.md security/release checks pass or gaps are disclosed.
• Dependency/advisory and artifact secret scans pass.
• Per-item/account deletion partial-failure tests pass.
• Cleartext remains disabled.
• Screenshots/fixtures/logs are privacy-reviewed.
• Signing type and distribution risk are accurately described.

• Professional security/privacy review proportional to risk.
• Production operator access controls, MFA, secret rotation, backup/disaster recovery, monitoring, alerting, incident response, retention, and deletion procedures.
• Public vulnerability-reporting/security contact.
• Current Play/platform/provider compliance review.

No public security contact or disclosure program exists because the repository/service is not released. Do not place vulnerability details, tokens, private media, or exploit data in public issues. The owner must define a private contact and response policy before public distribution.

The owner approved Gate 3 on 2026-07-26, accepting this threat boundary and required controls as implementation constraints. This does not claim the controls exist, authorize a production backend or real personal media, approve secrets/signing handling, or constitute a completed security review.