# Remozio plan review: revision 5

**Scope:** This review covers only the plan text. I did not inspect source, run tests, or verify any platform behavior. I evaluated the plan against the review instructions and the round-4 disposition.

## Result

I found no concrete planning defects that require a correction. I also found no unselected product policy that the plan treats as decided.

## What was assessed

- **Round-4 disposition:** Revision 5 implements both accepted items.
  - **F1, target timeouts (§9):** The plan captures each dialog's observable deadline and default effect as semantic data. The passage of time does not invalidate a request. It distinguishes an observed target timeout from a disappearance with unknown cause. It does not shorten Remozio's approval window or change target defaults.
  - **F2, multi-phone revocation (§5):** Revocation removes only the selected phone's authority. Other enrolled phones keep pending requests. A request is cancelled only when no authorized phone remains. Revocation is serialized with decision consumption and covered by acceptance tests.
  - **Sudoers clarification (§8):** This remains a feasibility gate that ends with a user choice. No policy is chosen silently.
  - I found no scenario that reopens these dispositions.
- **Biometric policy and scope classification (§1, §6, §9):**
  - The action table matches the user's confirmed choices. Cancel, deny-once and allow-once need no biometrics. Every reusable rule needs biometrics, including Forever, Deny Forever, and timed or session rules.
  - Allow-once without biometrics is limited to Little Snitch. Both the root service and the GUI adapter reject decision-key authority for commands, 1Password, credentials and enrollment.
  - Classification comes from retained action semantics and the adapter's validated compatibility contract. It never comes from button labels, caller labels, or a phone's claim that biometrics are unnecessary.
  - "Current request" is defined concretely. Later connection attempts, and attempts arriving while an alert is open, are tested so they cannot inherit a once-decision.
- **Key separation (§3, §6, §7):**
  - The plan keeps these keys distinct: Mac authority, transport, adapter receiving, phone biometric, phone decision, and phone credential keys.
  - Key purpose is checked against enrollment records, not against what the message claims.
  - A decision key cannot replace biometric or credential authority.
  - The pre-login transport-key fallback is explicitly excluded for authority and credential keys.
- **Relay resistance (§3, §5, §6):**
  - Payloads are end-to-end encrypted between the root authority and the phone.
  - Requests are signed by the authority, and credentials are encrypted to a certified adapter key.
  - A relay or transport key cannot mint decisions, including one-time decisions.
  - Push payloads carry only opaque wake identifiers.
- **Malicious unprivileged caller (§2, §3, §8, §9):**
  - The caller's identity comes from the audit token and trusted OS queries, not from caller-supplied PIDs or labels.
  - Frontend signatures are not treated as consent.
  - Live code identity is checked on every privileged XPC request, and code injection and bundle modification are tested.
  - Only the originating caller/session, an enrolled phone, or the local administrator may cancel a request.
  - Requests are rate-limited, and batches are never auto-approved.
  - The plan documents the gap where other automation already holds Accessibility or Automation grants over the target.
- **Command binding (§8):**
  - The plan captures the full argv, working directory, target UID/GID and groups, environment, and stdin classification.
  - Uncaptured stdin is disclosed rather than prebuffered.
  - Oversized requests return Request too large without truncation.
  - Requester-exited outcomes distinguish "no child started" from "started or unknown."
  - The executable-entry race is a gate with a required semantic contract and a user-consultation path. No silent relocation or allowlist is introduced.
- **Android biometrics and credentials (§7):**
  - Signing uses a CryptoObject bound to the immutable selected request, with no grace period.
  - The single-authentication credential-release question is a feasibility spike. It leads to consultation if a second prompt or weaker protection would be needed.
  - Pairing is preserved after biometric changes where the OS and key policy allow it, which matches the user's preference.
  - Recovery goes through an independently authenticated administrator session within the retained pairing record.
- **UI race handling (§6, §9):**
  - Dispatch uses a one-time ledger permit that is consumed before any dialog mutation.
  - A missing acknowledgment or adapter death produces an unknown result, never a retry.
  - Late adapters cannot act, and refresh requests are labeled when a default may have been modified.
  - Deny and Cancel receive the same revalidation as Allow.
- **Remote coding UX (§1, §5, §8):**
  - Commands work without a GUI login or while the GUI session is locked.
  - The plan measures harness timeouts instead of shortening the approval window.
  - Offline state, queueing, and reconciliation are visible to the user.
  - Manual sudo remains available as a fallback.
- **Flux borrowing (§4):** The plan uses Flux as a design reference only until its license is resolved.

## Remaining tentative UX choices (tracked, not defects)

These are open decisions that the plan already records as provisional or consultation items:

- The provisional five-minute request expiry.
- Whether to add an encrypted relay or push wake.
- An optional detached or resumable command mode.
- The sudoers-policy integration versus a Remozio-administered policy.
- The outcome of the executable-entry race gate.
- Accepting software-only keystores or biometric fallback.
- Changes to 1Password credential delivery if only synthetic typing is possible.
- Little Snitch behavior if true one-time scope proves unavailable.

## Non-blocking clarification (not a finding)

§6 lists the fields of the authority-signed request, but that list does not name the certified credential-recipient binding for unlock requests. §3 and the acceptance test "credential recipient substitution fails" already imply that binding. Naming it among the §6 request fields would make the protocol spec self-contained. This does not affect UX.

## Implementation verification limits

Convergence on this plan does not establish any of the following. Each needs real-device or real-host evidence during the feasibility gates and later stages:

- Whether Android Keystore preserves keys across biometric enrollment changes.
- Whether a single CryptoObject authentication can release a credential.
- Whether pre-login keychain or LaunchDaemon key custody works.
- Whether descriptor-based execution is available on macOS.
- Whether Little Snitch's one-time effect is truly limited to the captured request.
- Whether 1Password exposes its accessibility structure and a directly targetable secure field.
- Whether Doze and background-delivery behavior is reliable on real devices.
- Whether sudoers compatibility is achievable.

**NO SUBSTANTIVE FINDINGS**