# Independent review — Remozio plan, revision 17

Scope reviewed: complete plan including post-revision-5 additions (§12 audit, §13 expiry, §14 presence routing, §15 push, §16 LAN/relay + cloud management, §17 identity/Sparkle/updates, §18 protocol evolution), plus the round-10 disposition. Plan-only review; no testing or source inspection claimed.

The round-10 correction (§16 administrative setup controller) is adequately integrated: it appears in the §3 component inventory, follows §3/§17 placement and generation rules, is credential-separated per the table, has typed resource-bound operations with post-mutation verification, and has matching acceptance tests. I found no unresolved scenario there and do not challenge that disposition.

## Findings

### 1. Low — §12 audit event schema conflicts with §12 sensitive-data exclusions

"Event schema" requires each event to record "selected action and scope." "Sensitive data exclusions" forbids persisting "destinations," "item names," and "UI text." For a Little Snitch decision, the bound scope inherently includes the destination host/IP, port, and duration; for a 1Password access decision the action references an item. As written, an implementer must either store the full bound scope (violating the exclusion rules and risking failure of the "seeded secrets never occur in the journal" acceptance case) or store only an action label (failing the acceptance case requiring the log to distinguish "one-time and reusable decisions"). Failure scenario: two engineers read the same section and produce either a privacy violation or an acceptance failure.

Minimal correction: define audit-record scope granularity explicitly — record action kind and scope *class* (once / until-quit / session / forever; host / domain / any) plus the structured reason codes, and state that the full bound scope values exist only in the memory-resident signed request and are never journaled, mirroring the existing "detail view explains that full request contents were not retained" language. No UX impact; no consultation needed.

### 2. Low — §14 manual routing override has no remote recovery path and can silently strand the core scenario

"Manual modes override automatic presence detection until the user changes the mode," the mode "persist[s] across app restart," and the override is only *visible* in Android device status — there is no phone-side control. Failure scenario: the user selects "At my Mac," then leaves. All requests are kept local indefinitely; command callers see only the routing reason locally, the phone shows the stuck override but cannot act, and remote approval — the product's central use case — is dead until physical return. The §14 degraded-detection fallback ("route to the phone" on unavailable presence data) does not apply because the manual mode is not a detection failure.

Minimal correction: either (a) allow an enrolled phone to set routing mode using the already-established authenticated device-control pattern (a further narrowly-scoped decision-key purpose, like §17 update scheduling — an override grants no authorization and a malicious mode change is availability-only), or (b) bound manual override lifetime and revert to Automatic. This *adds* remote capability and adds no confirmation, biometric, or manual step, so it does not trigger the §1 consultation categories; alternatively record it as an explicit pending user decision. Severity is low because it is a UX completeness gap, not a security boundary defect.

### 3. Low — §15 gateway recipient-mapping and revocation propagation trust chain unspecified

The gateway must "enforce its enrolled recipient mapping," and "revocation stops future pushes and authenticated fetches for that phone," but the plan never states which credential authenticates the Mac↔phone mapping at the gateway or how revocation propagates to it. If mapping updates are authenticated only by the Mac push-submission credential (held by the dedicated transport account per the §16 table), compromise of that credential could rebind recipient mappings. Impact is limited — wakes are opaque and fetches still require enrolled-phone authentication, so this leaks only delivery timing metadata, not request content or authority — but the §16 acceptance tests exercise credential substitution on the Mac side only, not gateway-side mapping integrity.

Minimal correction: specify that enrollment, replacement, and revocation of the gateway recipient mapping are authenticated by the Mac authority key (matching the phone-side authenticated registration), define revocation propagation to the gateway, and state explicitly that Mac-side revocation remains authoritative for fetches even before gateway propagation completes (parallel to the §16 Access-revocation rule for phones). Add a gateway-mapping acceptance case. No UX impact.

## Tentative UX choices (declared pending; not findings)

The 30-second idle interval, the ~60-second 1Password lifetime estimate, and audit retention duration are explicitly deferred product preferences with validation paths; per the review instructions I raise no finding on them. The 1Password estimate is correctly scoped as per-prompt-type validation work, not a guarantee.

## Assessed boundaries (summary)

- **Scope classification and key separation**: §1/§6/§9 are internally coherent — reusable rules (including temporary/session and Deny Forever) require the biometric key at both verifiers; once-decisions are confined to the captured alert set with second-attempt validation; the decision key's purposes are closed and §17 scheduling controls are correctly excluded from target-action authority. The confirmed biometric-free Little Snitch allow-once is not widened anywhere.
- **Replay/downgrade resistance**: §18's last-known authenticated capability records prevent a network attacker from forcing weaker contract selection by suppressing v2 phones; §17 floor commit, external anti-rollback at activation, and "never resubmit on unknown admission" close the obvious update-window races. Unproven elements (protected placement, generation-isolated key access, atomic execution, single-biometric credential release, noninteractive Access auth) are all defined feasibility gates with failure/consultation paths, not unexamined assumptions.
- **Cross-section consistency**: §12/§6 journal-consumption atomicity, §13/§17 age preservation across recapture, §5/§14 multi-phone delivery qualifiers, and §16/§17 controller custody are consistent; the contradictions I found are limited to findings 1–3 above.

## Conclusion

SUBSTANTIVE FINDINGS REMAIN — three low-severity, actionable planning defects (§12 audit-schema/exclusion conflict; §14 stranded manual override; §15 gateway mapping trust chain). None requires a UX-worsening correction, none removes an adapter from scope, and none invalidates the feasibility-gate structure; all three are specifiable within the existing design vocabulary.