Encrypted queue architecture for zero-trust home screen widgets

Gruezi HN,

We built SympLog (Android & iOS), an offline-first health tracker with a fully encrypted DB. When users asked for home-screen widgets, we hit a problem: how do you let a widget write data without exposing the encrypted database?

Screen recording of prototype: https://files.catbox.moe/8egcnt.mp4 App info: https://www.symplog.com

The Problem Fast logging matters a lot for symptom tracking. If it takes too many taps, people stop doing it. We got asked multiple times for home-screen widgets, but the apps DB is fully encrypted. Letting a widget read the DB directly would weaken our security model.

Threat Model - Someone glancing at your home screen shouldn't see "Anxiety-severe"... (Shoulder Surfing) - If the phone is seized or stolen while locked, queued events should not be readable without the device credential. - Encrypted queue data shouldn't be trivially readable from ADB backups or cloud backup snapshots.

The Implementation (Android Prototype) To solve this trade-off, we prototyped (not released yet) an uncoupled, encrypted queue architecture that keeps the data footprint minimal and eliminates the need for direct database access. - The widget does not read the app DB. It only writes events to an encrypted queue in app-private storage. - Storage uses EncryptedSharedPreferences + Masterkey (Android Keystore). - The queued data only contains strictly necessary data: event_id, catalogUid, rating, and timestamp/timezone. - When the user opens and unlocks the app, it imports the queued events into the encrypted DB and automatically clears the processed items in the encrypted file. Because the app is offline-only, we don't have to worry about data inconsistency across multiple devices.

Privacy-First Configuration The widget UI itself is still a risk. To mitigate that I implemented a few features: - Users can set custom abbreviations (e.g. mapping symptom "Anxiety" to alias "A5y") to reduce data exposure on the home screen (shoulder surfing). - Users must explicitly enable the widget after acknowledging a privacy warning and can enable / disable the widget. - The widget configuration itself (which contains the user's selected symptoms and aliases) is fully encrypted.

UX Details - A short undo window before the commit to write log to encrypted file appears. - "Undone" and success (checkmark) feedback on commit. - A disabled-state widget (widget not enabled yet) with a deep link to configure. - Standard dark/light mode adaptive coloring.

I'm still iterating on import idempotency (handling edge cases where the app crashes mid-import). I'd love feedback on this architecture, or how others have handled secure data ingestion from "leaky" UI surfaces like OS widgets.

Alternatives We're Considering ESP works for now, but we're evaluating: - Direct Keystore + Cipher encryption with 1 file per event, which simplifies crash recovery and avoids ESP entirely - Encrypted Jetpack DataStore, which should be more future-proof and better suited for structured data.