Review 3 of 6 — Privacy, data minimization, least privilege

Reviewer lens: what the sidecar stores, who could read it, and whether each permission and dependency is the minimum needed.

Inputs: docs/PRD-original.md, docs/DESIGN-DRAFT.md (2026-10-03).

Verdict: the direction is right: no INTERNET, no bodies by default, Person-uri contact inference, OTP redaction.

But the draft has five real holes, and each one would quietly break a privacy claim the PRD makes:

1. The HMAC sender key is mostly theater as drafted. The same row also stores a cleartext "display label", which for an unknown sender is the number (android.title). The smsto: action needs the number anyway. (§2)
2. "No INTERNET permission" holds only until the first Google dependency is added. ML Kit GenAI brings telemetry, and it hands message text to AICore, which is a separate process that does have network access. Nothing in the draft verifies the merged manifest. (§5)
3. Our own annotation notification re-leaks what Android 15 just redacted. Every other notification listener can read it (watch bridges, Pushbullet-style apps, launchers). So can the lock screen and dumpsys notification. (§7)
4. "Delete everything" leaves data behind. It misses WAL/journal files, WorkManager's own unencrypted DB, the probe exports, our posted notifications, and Messages notifications we snoozed. Snoozed notifications would be lost, which breaks the PRD's "reversible" principle. (§4)
5. Backups are not addressed. On Android 12+, allowBackup="false" alone does not stop device-to-device transfer. (§3)

---

1. Threat model (who are we protecting the data from?)

The design needs to state this explicitly. Each control below should map to one of these rows. Otherwise "encrypt everything" becomes cargo cult.

Out of scope: a compromised OS, and a malicious Google Messages (it already has everything).

---

2. Sender keys: is HMAC(number) meaningful?

Short answer: it is weak as pseudonymization, useful as an index, and good for crypto-shredding. Only that last one is worth claiming.

• Enumerability. The NANP space is under 10^10, and realistically a few billion live numbers. With the key in hand, a laptop brute-forces HMAC-SHA256 over all US numbers in minutes. So an HMAC protects nothing against anyone who has both the DB and the key. If both live in the app sandbox (a key in SharedPreferences or in the DB), the HMAC is decoration.
• It does help if the key is a non-exportable Android Keystore HMAC key (KeyProperties.KEY_ALGORITHM_HMAC_SHA256, StrongBox if available). Then each HMAC needs an on-device Keystore call, which is roughly milliseconds in the TEE. Enumerating the space means running code as our app on this device for weeks, and an attacker who can do that can simply read new notifications. So it raises the bar for offline attacks on an exfiltrated DB (T4) or export (T5), and nothing more.
• The draft undoes it anyway. The per-sender row stores a "display label". For unknown senders, Google Messages' android.title is the formatted number. "Ask who this is" (smsto:<number>) and the PendingIntent fallback both need the cleartext number. So the number is in the DB regardless.

Recommendation.

• Keep sender_key = HMAC_keystore(E.164-normalized number) as the lookup key.
• Store the number and display label in a separate column, encrypted under the DB key (SQLCipher already covers it).
• Be honest in the UI and design doc: "numbers are stored encrypted; the sender ID is a keyed hash so exports and logs never contain numbers."
• The real benefit: deleting the Keystore HMAC key unlinks all past history from future messages, even if a stale DB copy survives (crypto-shredding).
• Normalize with libphonenumber, which runs offline on bundled metadata, using the SIM/locale region as the default region. Handle short codes and alphanumeric sender IDs (e.g. "AMAZON") as their own key namespaces (sc:12345, alpha:AMAZON). If normalization is wrong, one person splits into two "unknown" senders, and the trajectory feature silently fails.
• Never put sender_key, numbers or names in logs, notification tags/IDs, WorkManager inputs, or file names.

---

3. Encryption at rest and backups

3.1 Current state of the libraries (verified 2026-10-03)

• Jetpack Security (androidx.security:security-crypto) is deprecated. "Deprecated all APIs in favour of existing platform APIs and direct use of Android Keystore". This landed in 1.1.0-alpha07 (Apr 2025) and beta01 (Jun 2025). 1.1.0 stable (2025-07-30) is the final, deprecated release. Do not use EncryptedSharedPreferences / MasterKey. Source: https://developer.android.com/jetpack/androidx/releases/security
• SQLCipher: use net.zetetic:sqlcipher-android (4.x, with the SupportOpenHelperFactory for Room). The legacy net.zetetic:android-database-sqlcipher artifact is deprecated. (Reviewer did not re-verify the current version number; pin it at scaffold time.)

3.2 Recommended design

• Baseline (free). App-private storage under file-based encryption (credential-encrypted storage). It already protects data at rest before the first unlock. Do not make the listener directBootAware: we want nothing written before first unlock.
• DB. Room + SQLCipher.
• The passphrase is 32 random bytes, wrapped with a Keystore AES-256-GCM key (StrongBox when present), and the wrapped blob is stored in a plain file in noBackupFilesDir.
• Do not set setUnlockedDeviceRequired(true) on the DB key. The listener must write while the phone is locked, so that flag would break ingestion. This is the main reason SQLCipher only buys partial T4 protection (AFU state).
• Retained message bodies (opt-in only): use a write-only envelope.
• Encrypt each retained excerpt to an asymmetric Keystore key pair. The listener encrypts with the public key, which works while locked.
• The private key has setUnlockedDeviceRequired(true), plus optional setUserAuthenticationRequired.
• The result: bodies are unreadable on a locked or seized-AFU phone, and readable only when Byron opens Review.
• Cheap to build, and it is the only place SQLCipher's limitation really matters.
• Small settings (toggles, thresholds) can live in plain DataStore. Anything about a person (expected-sender ledger, trust list) goes in the encrypted DB.
• Honest scope. If bodies are off (the default), the DB holds verdict history, codes, trust labels and the context ledger. The context ledger is the most sensitive item: "Dentist Thursday" is health data. That alone justifies SQLCipher.

3.3 Backups: must exclude everything

• Set android:allowBackup="false".
• Also set android:dataExtractionRules="@xml/data_extraction_rules" (API 31+). Exclude every domain (root, file, database, sharedpref, external) under both <cloud-backup> and <device-transfer>. For apps targeting 12+, allowBackup=false still permits device-to-device migration.
• Set android:fullBackupContent="@xml/backup_rules", excluding all, for API ≤30.
• Keystore keys never migrate, so a restored DB would be unreadable anyway. That is defense in depth, not the control.
• Samsung Smart Switch: verify on Byron's device that the app's data is not carried over. Add this to the spike checklist (§6.2 #9 already covers Samsung).
• Apply the same rules to the probe APK.

---

4. "Delete everything": define it precisely

The draft says "drop the DB plus rotate the HMAC key". Rotate is the wrong verb: delete it. Because flash storage doesn't securely erase, the real erasure mechanism is crypto-shredding. The full sequence, in order:

1. Un-snooze every Google Messages notification we snoozed (Quiet-unknowns mode). If we skip this, deleting our data hides the user's messages, which breaks "reversible actions". Also always snooze with a finite duration, so an uninstall or crash can't strand notifications.
2. cancelAll() our own posted notifications.
3. Cancel all WorkManager work and delete WorkManager's DB. It is a separate, unencrypted SQLite DB (androidx.work.workdb) that persists Data inputs. Rule: never pass message text, numbers or names as WorkManager input. Pass only an opaque row ID.
4. Close Room, then delete the DB and the -wal, -shm and -journal files.
5. Delete the Keystore aliases: DB-wrap key, HMAC key, body-envelope key pair. This step is the actual erasure. Steps 3–4 just reclaim space.
6. Clear filesDir, noBackupFilesDir, cacheDir, DataStore files, and any local crash ring buffer.
7. Delete probe/diagnostic exports we created (SAF URIs we hold persisted permission for). Tell the user that copies they shared elsewhere are out of reach.
8. Drop in-memory caches (sender cache, held contentIntent PendingIntents).
9. Show what we cannot delete: messages in Google Messages, drafts we opened in Messages, contacts the user added, Google Messages' own block/report state.

Note: this is distinct from "revoke Notification Access", which should be offered alongside. Add an instrumentation test: populate everything, delete, then assert that the app's data dir contains only freshly created empty files.

---

5. The no-INTERNET guarantee: make it a build check, not a sentence

The claim is good, but nothing enforces it yet. A manifest-enforced guarantee only holds if the merged manifest is checked on every build.

• CI gate. After assembleRelease, run apkanalyzer manifest permissions app-release.apk (or aapt2 dump permissions). Fail the build unless the set equals an explicit allowlist, e.g.:
• POST_NOTIFICATIONS
• RECEIVE_BOOT_COMPLETED (if needed for the heartbeat)
• our own DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION (auto-added by AndroidX)

The service itself is protected by BIND_NOTIFICATION_LISTENER_SERVICE; that is a permission= attribute, not a uses-permission. Deny explicitly: INTERNET, ACCESS_NETWORK_STATE, READ_CONTACTS, READ_CALENDAR (until §10), READ_SMS, RECEIVE_SMS, SEND_SMS, QUERY_ALL_PACKAGES, BIND_ACCESSIBILITY_SERVICE, READ_PHONE_STATE.

• Dependency deny-list gate on ./gradlew :app:dependencies --configuration releaseRuntimeClasspath:
• any com.google.firebase:*
• com.google.android.datatransport:*
• play-services-measurement*
• okhttp, ktor-client, cronet
• any crash reporter (Sentry, Crashlytics, Bugsnag, ACRA's HTTP sender)
• Runtime check on the device: adb shell dumpsys package <pkg> | grep -A30 "requested permissions".
• ML Kit GenAI / Gemini Nano breaks the guarantee in two ways:

1. Telemetry. ML Kit's own disclosure says the GenAI APIs send device info, performance metrics, API configuration, event types, error codes and configured languages to Google. It also uses Firebase Remote Config and Firebase Installations. Source: https://developers.google.com/ml-kit/android-data-disclosure. Expect the merged manifest to gain INTERNET + ACCESS_NETWORK_STATE from transitive deps (to verify at scaffold time). We could strip them with tools:node="remove", but whether inference survives that is untested, and the disclosure gives no opt-out.
2. AICore is a separate system process with its own network access. Even if our APK has no INTERNET, message text crosses an IPC boundary into a Google component. The guarantee would rest on Google's statement that ML Kit "does not send input data", not on our manifest. That is a different, weaker guarantee, and the UI must say so.

Recommendation: keep the LLM out of v1 entirely, as the deterministic engine must stand alone anyway. If it is added later, ship it as a separate build flavor, ideally a separate opt-in APK talking to the core over a signature-protected bound service. The core APK keeps a provable zero-network manifest, and the transparency screen states which build is installed. Prefer a fully local runtime (llama.cpp / a GGUF model loaded through SAF) over AICore if a manifest-provable guarantee is wanted. Check MediaPipe LLM Inference for telemetry before choosing it.

• No INTERNET ≠ no egress. Name the residual channels:
• Implicit intents. The smsto: draft is user-confirmed and fine, but never fire ACTION_VIEW on URLs from messages; the PRD already forbids auto-open.
• Share sheets.
• The clipboard. Avoid copy actions; if one exists, set ClipDescription.EXTRA_IS_SENSITIVE.
• Our notifications, which other listeners can read (§7).

Code rule: the only outbound intent carrying message-derived data is the user-tapped smsto:, and it carries a fixed template, never quoted message text.

---

6. Logcat, crash reporting, screenshots, dumps

• Logcat.
• Release builds strip Log.v/d/i via R8 -assumenosideeffects. Use a logging wrapper whose release variant drops all args except a static event code.
• Never log StatusBarNotification.toString(), Notification.extras, Bundle.toString() or Person. These dump titles and text.
• Watch exception messages: IllegalArgumentException("bad URL: $url") puts content into the stack trace. Lint rule: exception messages must be constants.
• Since Android 13, ordinary apps can't read other apps' logs without user consent, but adb logcat, bug reports and OEM log collectors (Samsung's diagnostic upload) still can.
• Crash reporting. None (no network, so it can't phone home anyway). Keep a local ring buffer of scrubbed crash signatures (exception class + top frames, no messages), exportable only by a manual user action.
• FLAG_SECURE on the History, Review, Sender-detail and Context-ledger screens. This blocks recents thumbnails, screenshots and screen-share leakage. Optional biometric gate (BiometricPrompt, device credential allowed) on opening History/Review (T3).
• Release builds are not debuggable. A debuggable build lets adb shell run-as read the DB. The probe APK can be debuggable, but its data must stay structural-only (§8).

---

7. Our own notifications (lock screen, watches, other listeners)

The sidecar posts derived content, such as "Likely scam from +1 415… — asks for a code". Android 15's OTP/sensitive redaction doesn't apply to our content. Every other notification listener on the device, paired watches, and the lock screen see it.

• Visibility:
• VISIBILITY_PRIVATE with a setPublicVersion() that says only "Message checked", showing no verdict, no sender and no number.
• VISIBILITY_SECRET for anything touching OTP/financial/health detectors, and for "Likely scam" (the verdict itself is sensitive: it says a scam targeted you).
• Channel-level lockscreenVisibility should match, because the user can override per-channel.
• Content minimization. Our annotation shows the verdict + up to 2 reason labels from the fixed vocabulary. Never quote message text, never show the full number (the original Messages notification already shows who it's from). Show "asks for a code", not the code; "link to lookalike domain", not the URL.
• setLocalOnly(true), so annotations don't bridge to Wear OS / Galaxy Watch.
• Notification IDs/tags come from an opaque counter, not sender_key or the number. Tags appear in dumpsys notification.
• PendingIntent extras carry only an opaque row ID. Use FLAG_IMMUTABLE and explicit component intents.
• Sensitive-content flag. Mark notifications sensitive where the platform supports it. On Android 15+, check whether apps can mark their own notifications sensitive for listener redaction. (Unverified whether there is a public API for this; at least use SECRET.)

---

8. Phase 0 probe: the export file is a real leak vector

The draft says the probe "logs structure, never message text". Structure still leaks:

Probe rules:

• Filter by package as the first statement in onNotificationPosted, before touching extras. Notification Access grants every app's notifications, and the probe must not even parse the others.
• Use an allowlist serializer, not "dump keys and redact values". Unknown future keys are emitted as {key, type} only.
• Export via SAF ACTION_CREATE_DOCUMENT to a user-chosen location, never to shared Downloads automatically. Show a pre-export preview screen.
• Same backup exclusions; data auto-deletes after 14 days.
• Uninstall the probe and revoke its Notification Access after the spike. Put this in the spike checklist.
• Before Byron pastes an export into any chat or agent, the export header should state "contains no message text, names or numbers", and a unit test must prove it against fixtures that contain text, names and numbers (golden "canary strings" that must never appear in output).

---

9. Retention, and third-party data

• Senders didn't consent. Their number, a "Not legit" label, and a scam verdict about them are personal data about a third party. For Byron's personal use, GDPR's household exemption (Art. 2(2)(c)) applies, and CCPA covers businesses, not individuals, so the legal exposure is minor.
• If ever distributed (Play Store, friends, a LinkedIn demo build), it changes:
• Google Play's policy on Notification Listener use requires a prominent disclosure and a Data safety form.
• Labels about third parties need TTLs.
• Shipping a pre-seeded "known scam numbers" list makes it a data controller problem.

Design for that now; it costs nothing.

• Retention defaults (proposed; all user-visible on the "What's stored" screen):
• Per-sender history: last 10 verdicts, only for senders seen in the last 90 days.
• Unrecognized senders the user never acted on: purge after 30 days. This is the bulk of third-party data, and most of it is noise.
• User-set trust labels ("Trusted", "Not legit"): kept until removed, with a yearly "still accurate?" prompt optional.
• Context-ledger entries must have an expiry; the default is 14 days, and the max is 1 year for standing entries like "my building".
• Opt-in bodies: the draft says 7 days. Suggest 48 h default, max 7 days, only for non-Recognized messages, using the §3.2 envelope.
• A daily purge job (WorkManager, no inputs).
• Evidence pointers. The draft says every code "points at evidence: the matched span, URL". Stored spans are message content.
• Store spans only in memory for the live annotation.
• Persist only the reason code + a static template string.
• For URLs, persist the registrable domain (eTLD+1) + flags (punycode, lookalike, mismatch), never the full URL. Full URLs carry tracking IDs and password-reset/login tokens.
• OTP/financial/health detectors run before anything is persisted, as the draft says. Also apply them before the LLM if it is ever enabled, and before our own notification text is composed.

---

10. Permissions: READ_CONTACTS and READ_CALENDAR

• READ_CONTACTS: don't request it in v1. If the spike confirms that Google Messages sets Person.uri to a content://com.android.contacts/...lookup URI for saved contacts and tel: for others, that scheme is the "in contacts" signal, with no permission needed. Do not treat Person.name as evidence. Messages may show business names or caller-ID names for non-contacts. If the spike shows URIs are absent (Samsung? RCS business?), the fallback is READ_CONTACTS used only for a single-number ContactsContract.PhoneLookup per message: never enumerate, never cache contact data, persist only a boolean. "Add to Contacts" uses ACTION_INSERT and needs no permission. Note: READ_CONTACTS is all-or-nothing and covers every contact's emails, notes and addresses, a big grant for one boolean.
• READ_CALENDAR: defer to v1.x and keep it opt-in. It exposes every calendar, including work calendars, attendee names and emails (more third-party data), and meeting notes. If added:
• query only the next 7 days at match time
• read only TITLE, EVENT_LOCATION, DTSTART
• keep the match transient and persist only the reason code CALENDAR_MATCH
• let the user pick which calendars
• never copy events into the ledger

The manual expected-senders ledger delivers most of the value without it.

• Notification Access is the heavyweight permission. It grants all apps' notifications plus the ability to cancel/snooze any of them. Least privilege at the code level:
• a package allowlist checked first
• a single NotificationGate class that is the only code allowed to call snoozeNotification / cancelNotification, and it asserts the package is Google Messages
• unit tests for it
• Listener scope reality: a personal-profile listener doesn't see work-profile notifications. State this in the feasibility report (§6.2 #10).

---

11. Proposed data inventory (the "What's stored" screen should render this table live)

---

12. Concrete changes to DESIGN-DRAFT

1. §G Storage: replace "SQLCipher or Keystore-wrapped key" with "Room + net.zetetic:sqlcipher-android, passphrase wrapped by a Keystore AES-GCM key; no security-crypto (deprecated 2025)". Add the asymmetric envelope for opt-in bodies.
2. §G Storage: reword the HMAC claim. Say the number is stored encrypted, and the HMAC is the export/log-safe key whose deletion unlinks history.
3. §G Storage: "Delete everything" = the 9-step sequence in §4. "Rotate" → "delete".
4. §G Storage: persist reason codes + eTLD+1 only; spans in memory only.
5. New §G.1 Backups: allowBackup=false + dataExtractionRules excluding cloud and device-transfer + fullBackupContent.
6. §G no-INTERNET line: add the CI merged-manifest permission allowlist and dependency deny-list as Phase 0 deliverables, in the core CI job.
7. §F LLM: state that ML Kit GenAI/AICore is incompatible with the manifest guarantee. Move it to a separate optional flavor/APK, or use a fully local runtime. v1 = no LLM.
8. §E Annotate: add the notification visibility / public version / setLocalOnly / no-quoting rules from §7. Make snoozes finite, and un-snooze on delete/uninstall-prep.
9. §H Probe: allowlist serializer, package filter first, SAF export with preview, canary-string test, uninstall-after-spike step.
10. §C: do not rely on Android 15 OTP redaction as "free" protection. It is performed by Android System Intelligence on Pixel-class builds, so verify it on Byron's Samsung. It covers OTPs only, not bank balances or health messages, so our own detectors remain mandatory.
11. §B: the context ledger needs mandatory expiry. READ_CALENDAR deferred to v1.x, transient-match only.
12. New §G.2 Logging: R8 log stripping, constant exception messages, FLAG_SECURE, non-debuggable release, no crash reporter.

Sources

• Jetpack Security release notes (deprecation): https://developer.android.com/jetpack/androidx/releases/security
• ML Kit Android data disclosure (GenAI telemetry): https://developers.google.com/ml-kit/android-data-disclosure
• Android 15 sensitive notifications for untrusted listeners: https://www.androidauthority.com/android-15-sensitive-notifications-3416414
• Android 16 lock-screen OTP redaction: https://www.androidauthority.com/android-16-sensitive-notifications-lock-screen-3501564

← Back to the proposal