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?
The problem: Fast logging matters for symptom tracking — too many taps and people stop. But our DB is fully encrypted, so letting a widget read it directly would weaken the security model.
The solution: An encrypted queue architecture. The widget never touches the main DB. It writes events (just event_id, catalogUid, rating, timestamp) to an encrypted queue using EncryptedSharedPreferences + Android Keystore. When the user opens and unlocks the app, it imports and clears the queue.
Threat model: Shoulder surfing (someone sees your screen), phone seizure while locked, and ADB/cloud backup extraction. Users can set aliases (e.g. "Anxiety" → "A5y") to obscure what's displayed. The widget must be explicitly enabled after a privacy warning, and its config is fully encrypted.
UX: Undo window before commit, checkmark on success, disabled-state with deep link to configure, dark/light mode.
Still iterating on: Import idempotency (crash during import). Also evaluating alternatives to ESP — direct Keystore+Cipher with one file per event, or encrypted Jetpack DataStore.
I'd love feedback on this architecture, or how others have handled secure data ingestion from "leaky" UI surfaces like OS widgets.
1 comments
[deleted]·
Show HN: Encrypted queue architecture for zero-trust home screen widgets · HackerTrans
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?
Prototype demo: https://files.catbox.moe/8egcnt.mp4
App info: https://www.symplog.com
The problem: Fast logging matters for symptom tracking — too many taps and people stop. But our DB is fully encrypted, so letting a widget read it directly would weaken the security model.
The solution: An encrypted queue architecture. The widget never touches the main DB. It writes events (just event_id, catalogUid, rating, timestamp) to an encrypted queue using EncryptedSharedPreferences + Android Keystore. When the user opens and unlocks the app, it imports and clears the queue.
Threat model: Shoulder surfing (someone sees your screen), phone seizure while locked, and ADB/cloud backup extraction. Users can set aliases (e.g. "Anxiety" → "A5y") to obscure what's displayed. The widget must be explicitly enabled after a privacy warning, and its config is fully encrypted.
UX: Undo window before commit, checkmark on success, disabled-state with deep link to configure, dark/light mode.
Still iterating on: Import idempotency (crash during import). Also evaluating alternatives to ESP — direct Keystore+Cipher with one file per event, or encrypted Jetpack DataStore.
I'd love feedback on this architecture, or how others have handled secure data ingestion from "leaky" UI surfaces like OS widgets.