# Independent Plan Review — Remozio (round-1-plan.md)

Plan-only review of the document as presented. No source, platform, or implementation claims were verified. I assessed internal consistency, security boundaries against the stated in-scope attacker (malicious unprivileged caller), command binding, biometric/credential release, UI race handling, recovery flows, and remote-coding UX preservation.

**Items considered and deliberately not flagged** (already explicit feasibility gates, not defects): single-biometric credential release (§7 spike), secure-field targeting vs. synthetic typing (§9 gate), sudoers policy integration (§8 gate), descriptor-based execution (§8 spike), Android background delivery (§5 validation task), macOS service-management API selection (§3 spike), Flux licensing (§4). These are correctly scheduled with user-decision fallbacks.

## Finding 1 — Medium: Mac transport identity key custody is unspecified (§2, §3, §5)

**Defect:** §2 states "Mac authorization keys and enrolled phone public keys live in root-controlled storage," while §3 places "phone transport" in the unprivileged per-user agent. E2E encryption with pinned device identities (§5) requires a Mac-side long-term identity private key wherever the channel terminates. The plan never says which key that is or who may read it, and never states the residual impact of agent compromise.

**Failure scenario:** If the agent terminates the E2E channel with a key readable by same-user processes, an in-scope malicious unprivileged process can extract it and impersonate the Mac to the phone remotely: present crafted request screens (phishing the user into approving attacker-chosen details submitted in parallel through the real frontend), harvest request-detail confidentiality, and selectively drop/delay requests. The service's independent signature verification prevents *execution forgery*, but the plan neither states that bound nor rules out the phishing/confidentiality path.

**Minimal correction:** Add one paragraph to §2/§3 defining the key split (root-held: phone trust anchors, enrollment material; agent-held or service-terminated: transport identity) and an explicit residual-impact statement for agent compromise (no approval forgery due to §3 independent verification; confidentiality/availability/phishing exposure with mitigation). **No UX impact** — no added confirmations, biometrics, or restrictions.

## Finding 2 — Medium: Phone-side escaping rules do not extend to UI-adapter strings (§8 vs. §9)

**Defect:** §8 mandates unambiguous rendering of newlines, control characters, bidi controls, empty arguments, and non-UTF-8 bytes — but only for command fields. §9 says "treat app-provided UI text as untrusted display data" without requiring the same rendering discipline for adapter-captured strings shown on the phone.

**Failure scenario:** A malicious unprivileged process controls its own executable name/path and its connection destinations. A process path containing newlines or bidi overrides appears in a Little Snitch request's "executable/process identity, destination host/IP" fields and could inject visually convincing fake lines into the phone detail view (e.g., a forged "benign" destination line), defeating the full-details display guarantee for the adapter where the in-scope attacker has the most control over displayed strings.

**Minimal correction:** One sentence in §9: the §8 unambiguous-escaping and raw-access rules apply to *all* phone-rendered fields, including adapter-captured UI strings, process names, hosts, and item names. **No UX impact** — rendering change only; no added steps.

## Finding 3 — Low: Phone signing-key granularity contradicts account binding (§5, §6, §7)

**Defect:** §7 specifies a "per-Mac EC P-256 signing key"; §5 binds the phone key "to the Mac account"; §6's envelope carries an "account binding." On a Mac with two enrolled administrator accounts (explicitly supported by §3's policy language), a single per-Mac key makes the account binding ambiguous — the service cannot distinguish which account a signature authorizes, and §10's "wrong key/Mac/account rejected" test has no defined semantics.

**Failure scenario:** Two accounts on one Mac pair the same phone. With per-Mac keys, an approval intended for account A's request is cryptographically indistinguishable from one for account B, weakening the account-binding check the envelope claims to provide.

**Minimal correction:** Define key granularity as per (Mac identity, account) pair in §7, with the phone key ID in §6 scoped accordingly. **No UX impact** — one biometric per approval either way; re-pairing flow unchanged.

## Verification limits

This review validates plan coherence only. It cannot confirm that Android Keystore, BiometricPrompt.CryptoObject, Accessibility APIs, or macOS service-management APIs behave as assumed — those remain §10 stage-1 evidence gates. Convergence on this plan would not imply platform feasibility is proven or the design is secure in implementation.

**SUBSTANTIVE FINDINGS REMAIN**