Review 2 of 6: Threat model, adversarial input, and prompt injection

Reviewer lens: attackers, assets, attack paths, evasion, injection, UI spoofing, data leakage, and intent hijacking.

Inputs: docs/PRD-original.md (truncated at §7) and docs/DESIGN-DRAFT.md.

Date: 2026-10-03.

Scale used throughout.

• Severity:
• Critical: causes a scam to be shown as Recognized or Likely legitimate, OR leaks OTPs or message content off-device.
• High: reliably evades detection, OR poisons trust persistently, OR silences legitimate messages.
• Medium: partial evasion or limited leak.
• Low: nuisance, or needs prior device compromise.
• Draft handles:
• Yes: the draft's current text closes the hole.
• Partial: the draft has a control, but it leaks.
• No: not addressed.

---

1. System model and trust boundaries

SMS/RCS network ──► Google Messages (GM) ──► NotificationListenerService (sidecar)
   (attacker-controlled                          │  sbn.packageName filter (system-set, unspoofable)
    text, sender ID,                             ▼
    RCS group title,                       normalize → rules → [optional on-device LLM] → decision table
    MMS images)                                  │
                                                 ├─► Room/SQLCipher (per-sender HMAC state, trust list, ledger)
                                                 ├─► our annotation notification  (UI surface #1)
                                                 ├─► in-app history/explanations   (UI surface #2)
                                                 └─► user-initiated intents: smsto:, GM contentIntent, Contacts insert

The trust boundaries are as follows.

• TB1, GM notification → sidecar. Everything inside the notification is attacker-influenced:
• text
• android.title / conversationTitle
• Person names
• message ordering
• edits

Only the following are trustworthy:

• sbn.packageName
• the PendingIntent creator package
• (probably) Person URI schemes that GM populates
• TB2, other apps on the device → sidecar. This covers exported components, intents, overlays, other notification listeners, and shared storage.
• TB3, sidecar → user's eyes. Our UI must never let attacker text look like our verdict.
• TB4, sidecar → off-device. There is no INTERNET permission, but data can still leave through exports, backups, logcat, share intents, dependency manifest merges, and AICore.

2. Assets

3. Attackers

---

4. Findings by attack area

(a) Evasion of deterministic rules

(b) Abusing the context ledger

The draft's safety rule is: "context can raise legitimacy but can never lower scam_risk." That rule is necessary but not sufficient. Decision-table step 5 promotes to Likely legitimate whenever context ≥ 60 and risk < 40, and a scammer can keep risk under 40 without a link.

(c) Poisoning feedback and trust learning

(d) The optional on-device LLM

The draft gets several things right: the model is off by default, it has no tools and no network, its labels come from a fixed vocabulary, spans must be exact substrings, its weight is capped, it cannot remove risk codes, and INJECTION_ATTEMPT is a code. The gaps are below.

(e) UI spoofing: making our notification look like a "Recognized" verdict

(f) "Ask who this is" draft

(g) Storage, export, and the probe app

(h) Intent and PendingIntent hijacking

(i) Additional: availability and fail-safe direction (cuts across a16, d6, Quiet mode)

---

5. Required text-normalization pipeline (normative spec for core)

All rules run on derived views. The original is never mutated. Every view keeps an offset map back to the original (V0), because evidence spans shown to the user must be exact substrings of what GM displayed.

5.0 Input

• Inputs are android.text and each android.messages[i].text, converted with CharSequence.toString(). Spans and styling are discarded, so no URLSpan is ever trusted.
• Cap each message at 4,096 UTF-16 units. If it was over the cap, set the TRUNCATED_BY_SIDECAR flag, which affects completeness.
• Replace lone surrogates with U+FFFD and count them. Count > 0 is a MALFORMED_TEXT risk code.

5.1 Views

Steps. Each step records counts and positions for reason codes.

1. Classify and strip invisibles (V1). Remove and count each class separately.

• Zero-width / joiners: U+200B ZWSP, U+200C ZWNJ, U+200D ZWJ, U+2060 WJ, U+FEFF BOM.
• Exception: keep ZWJ in V1 when it sits between two emoji code points (Extended_Pictographic), since it is a legitimate emoji sequence. Strip it in V2 regardless.
• Other format and filler characters:
• U+00AD soft hyphen
• U+034F CGJ
• U+180E
• U+115F, U+1160, U+3164, U+FFA0 (Hangul fillers)
• U+2800 (braille blank)
• U+2061–U+2064 (invisible operators)
• Bidi controls: U+200E, U+200F, U+061C, U+202A–U+202E, U+2066–U+2069.
• Any of these inside a URL or domain candidate (determined on the pre-strip text by scanning ±64 chars around a dot) → BIDI_IN_URL (tripwire).
• Elsewhere → BIDI_CONTROL (risk, moderate). Legitimate RTL-language SMS may contain LRM/RLM. Treat lone U+200E/F in text with RTL script as benign.
• Unicode tag characters U+E0000–U+E007F → HIDDEN_TEXT (high risk). Decode them in debug builds only, to show what was smuggled.
• Variation selectors U+FE00–U+FE0F and U+E0100–U+E01EF. Keep VS15/VS16 (U+FE0E/U+FE0F) after emoji in V1. Strip all of them in V2. Runs of ≥4 selectors → HIDDEN_TEXT.
• Other Cc controls except \n and \t → strip. \r\n → \n.
• Emit INVISIBLE_CHARS if the total count of stripped non-emoji invisibles is ≥3 in text, or ≥1 inside any token that later becomes a URL or domain candidate.

2. Whitespace normalize (V1). All Zs characters (NBSP, U+2000–U+200A, U+3000, and so on), plus U+2028/U+2029, become ASCII space or \n. Runs of more than 3 blank lines, or more than 200 consecutive spaces, → PADDING (risk; related to a13).
3. NFKC (V1). java.text.Normalizer.Form.NFKC. This folds fullwidth, math-alphanumeric (𝐔𝐒𝐏𝐒), circled, superscript, and ligature forms. If NFKC changed any char outside the emoji ranges → STYLIZED_TEXT (weak risk).
4. IDNA dot and colon equivalents (V1). U+3002 (。), U+FF0E (．), and U+FF61 (｡) → . only when adjacent to alphanumeric runs. NFKC already maps U+FF0E; the other two must be explicit. U+FF1A and U+2236 become :, and U+2044 and U+2215 become /, in the same contexts.
5. Case fold (V2). Full Unicode case folding (UCharacter.foldCase in ICU4J, or lowercase(Locale.ROOT) as a floor).
6. Diacritic strip (V2 only). NFD, then drop Mn (combining marks). The display and V1 keep "José", "Peña", and "mañana" intact.
7. Confusable skeleton (V2).

• Apply the UTS #39 skeleton() mapping using a bundled confusables.txt, pinned to a Unicode version and compiled into a Kotlin table in core. Do not depend on android.icu.text.SpoofChecker; whether it is exposed on Android is unverified, and core must run on the JVM in CI anyway.
• Also compute, per token, mixed-script detection (UTS #39 "single script" / "highly restrictive" profile).
• Latin + Cyrillic/Greek/Armenian in one token → MIXED_SCRIPT_TOKEN (risk).
• In a hostname → LOOKALIKE_DOMAIN (tripwire).

8. Obfuscation folding (V2 only; never applied to hosts).

• Leet map: 0→o, 1→l|i (try both), 3→e, 4→a, 5→s, 7→t, @→a, $→s, |→l. Apply it only inside tokens that contain at least one letter.
• Single-letter collapse: (?:\b\p{L}[ .\-_*·•]){2,}\p{L}\b → join, so "U S P S", "U.S.P.S", and "U-S-P-S" become "usps".
• Repeat squeeze: a char repeated ≥3 times becomes 2 ("verrrrify" → "verrify"). Brand and keyword dictionaries include both squeezed forms.
• V2 is matched against the brand dictionary (brand → registrable domains, short codes, and aliases; versioned and shipped), the action lexicon (pay, verify, code, PIN, login, click, call, reply-Y, gift card, crypto, Zelle, wire), and the injection phrase list.

5.2 URL, domain, and number extraction (runs on V1)

1. Refang into a scratch copy, recording spans. Any refang hit → OBFUSCATED_URL (risk).

• hxxp, hXXp, h**p, h__p → http.
• [.], (.), {.}, [dot], (dot), {dot}, dot (spaced word "dot" between two labels where the right side is a PSL TLD) → ..
• [:] → :, [/] → /, [at], (at) → @.
• label . tld (spaces around a single dot where the right side is a PSL TLD and the left side is ≥2 alphanumerics) → joined.

2. Candidate extraction (linear-time scanner, no backtracking regex):

• (a) scheme://… for http, https, ftp, intent, market, sms, tel, and mailto. A non-http scheme is a code of its own (NONSTANDARD_SCHEME).
• (b) www. prefixed.
• (c) Schemeless label(.label)+.tld(/path)?, where tld is in the bundled Public Suffix List. Require that the left boundary is not alphanumeric (to avoid "e.g." false positives), and that the token has ≥1 letter.
• (d) Bare IPv4/IPv6, and integer/hex/octal IP forms after a scheme (hxxp://3627734734, hxxp://0xd8.0x3a…) → IP_LITERAL_URL (tripwire).
• (e) Email addresses → EMAIL_IN_TEXT (weak).

3. Parse each candidate with a strict WHATWG-style parser:

• Lowercase the host and percent-decode the host.
• Run UTS #46 ToASCII.
• Failure → MALFORMED_HOST (risk).
• Host contains xn-- → also run ToUnicode, then run the step-7 skeleton and mixed-script check. A lookalike of a brand domain → LOOKALIKE_DOMAIN (tripwire).
• Userinfo present (user@host or user:pass@host) → URL_USERINFO (tripwire). Report the real host in the evidence.
• Registrable domain = eTLD+1 via the bundled, versioned PSL.
• All brand comparisons use eTLD+1 only.
• A brand in a subdomain label but not in eTLD+1 → BRAND_IN_SUBDOMAIN (tripwire if the message also claims that brand).
• A brand in the path or query → BRAND_IN_PATH (risk).
• Wrappers and redirectors: a bundled list of wrapper hosts with URL-bearing params, plus generic detection of any query value that parses as a URL. Recurse up to depth 3, and score the innermost URL as well as the wrapper.
• Hosts/patterns: google./url, google./amp/s/, bing.com/ck/a, t.co, l.facebook.com/l.php, lnkd.in, *.safelinks.protection.outlook.com, urldefense.com.
• URL-bearing params: q, u, url, target, redirect, dest, next.
• A wrapper whose inner eTLD+1 ≠ the claimed brand → REDIRECT_WRAPPER (tripwire when a brand is claimed).
• Shorteners: a bundled list → URL_SHORTENER. Shortener + brand claim → tripwire (the destination can't be verified, and we never resolve it).
• TLD risk tiers: a bundled table of high-abuse TLDs (for example .top, .xyz, .icu, .cyou, .sbs, .buzz) → weak risk only, never a tripwire.

4. Cross-message reassembly (a12). Repeat steps 1–3 on the concatenation of the per-sender in-memory window, both with no separator and with a \n separator. Codes found only in the concatenation are tagged SPLIT_ACROSS_MESSAGES.
5. Phone numbers in text. Use libphonenumber findNumbers (leniency VALID) on V1. Toll-free, or a number differing from the sender → CALLBACK_NUMBER. Combined with BRAND_CLAIM → BRAND_CALLBACK_UNVERIFIED (Suspicious floor).
6. OTP / sensitive detectors run on V1 before the trajectory window, persistence, or the LLM queue (g8). Hits are reduced to codes, and the spans are zeroed in memory.

5.3 Display sanitation (for any attacker string we render: sender label, quoted span)

• Use V1 with all bidi controls removed, wrapped in FSI…PDI (U+2068 … U+2069), so it can't reorder the surrounding UI.
• Newlines → ⏎ .
• Cap the sender label at 32 chars and quoted spans at 120 chars.
• Strip leading emoji from sender labels.
• No autoLink, no HTML.
• URLs are shown defanged, with the eTLD+1 bolded.

5.4 Span contract

• Deterministic codes record spans in V1 coordinates and map them back to V0 for display.
• LLM spans are validated against V1 (the text the model was given). They must satisfy d3, and they are mapped back to V0 for display.
• A span that cannot be mapped is dropped.

---

6. Required adversarial golden corpus (additions to the core test corpus)

Each case gets an expected verdict floor or ceiling, not exact scores.

---

7. Changes required to DESIGN-DRAFT (summary for the consolidator)

1. Ledger. Self-identification is a claim. A ledger match never reaches Likely legitimate alone. Any action request nullifies the ledger boost and adds risk. Separate UI label. Expiry is mandatory. Calendar only from events the user created or accepted. (b1–b5)
2. LLM. LLM context labels can't cross a verdict boundary upward. No model prose in the UI. Span minimums and lexical checks. Flood discard. The input is V1 (invisibles stripped). Async, after the deterministic verdict. Disclose AICore. (d1–d8)
3. Manifest gate in CI. No INTERNET or Firebase from merged dependencies. No unexpected exported=true. (d9, h4)
4. Annotation never contains message text. The title is the verdict only. Sender labels are sanitized. Identity only from the contacts lookup URI or a trust E.164 match; never from title strings (this is a spike gate). (e1–e3)
5. Ask-who: a fixed generic template. Hidden for Suspicious and above, short codes, and alphanumeric senders. Uses setPackage(GM). The recipient comes only from the structured sender. Excluded from thread-continuity evidence. (f1–f6, c2)
6. Trust and feedback: non-exported handlers, an in-app confirmation behind a biometric prompt, filterTouchesWhenObscured. Floors and ceilings on every code. Global drift needs ≥5 senders over ≥7 days. History farming is capped below Recognized and reset by trajectory codes. E.164-only trust keys. (c1–c8)
7. Probe: an allowlist serializer, a canary test, SAF export with preview, no logcat of extras, allowBackup=false. (g1–g4)
8. Storage: Keystore-native HMAC key. The display label is stored only when needed. A separate auth-bound key for bodies. Our own OTP detector before any persistence or LLM. A complete delete. (g5–g9)
9. Robustness: a linear-time regex engine, input caps, a per-message time budget, fail-loud in Quiet mode, a fuzzing release gate, and rescoring on edits and updates. (a14, a16, i1)
10. Adopt the §5 normalization pipeline and the §6 adversarial corpus as Phase 0 core deliverables.

Spike items this review adds to PRD §6.2:

• (i) Does the sender Person carry a contacts lookup URI for saved contacts, and only a tel: URI for unknown senders, on Samsung and Pixel?
• (ii) What do RCS group titles and RCS business senders look like in conversationTitle/Person?
• (iii) Does an RCS edit re-post the notification with changed text?
• (iv) Android 15 OTP redaction on Samsung One UI vs. Pixel.
• (v) What is GM's android.text truncation length?
• (vi) PendingIntent.getCreatorPackage() value on GM contentIntents.

← Back to the proposal