# Remozio plan review: revision 16

This review covers the whole plan, sections 1–18. It pays particular attention to the revision 16 changes: tunnel and push credential custody, on-disk replacement as activation, and transparent waiting at the update boundary. It also checks how those changes interact with earlier invariants.

## Finding 1 (Low–Medium): custody of the Cloudflare management credential is unspecified

**Where:**
- §16 "Cloudflare Tunnel endpoint", the "Repair supports rotating and revoking each credential…" and "Uninstall revokes remote tunnel and gateway access" paragraphs
- §16 "Feasibility gate: background Access authentication", "Provision credentials through the authorized pairing flow…"
- §16 "Access and Remozio have different authority", "Cloudflare account API credentials never belong in the Android app"

**Problem:** Revision 16 now promises several remote operations:
- server-side revocation and rotation of the tunnel credential;
- uninstall-time revocation;
- per-phone Access service tokens issued during pairing.

Each of these needs a Cloudflare account/API credential with tunnel or Access management rights. The plan only says where that credential must not live (the Android app). It does not say where it does live, what scope it has, or who may invoke it.

The §3 "transport-key custody" rule, which §16 applies, covers the tunnel run-token and push-submission credential. It does not cover this broader credential.

**Failure scenario:** An implementation could store an account-scoped API token with the transport account or in a user-readable config, to make pairing and uninstall work. Anyone who read or misused it could:
- rewrite tunnel ingress to publish other local services, contradicting "Expose only the Remozio protocol endpoint";
- mint Access service tokens;
- weaken the Access policy.

Remozio's end-to-end approval integrity would survive. The unintended network exposure would not, and the "server-side revocation" claim would rest on an undefined authority.

**Correction:**
- Name the component that holds the management credential. Require least-privilege scope, limited to this tunnel's Access app and service tokens where Cloudflare permits it.
- Apply root/admin-only custody. Invoke the credential only from the already-admin-authorized enrollment, repair, and uninstall flows.
- Keep it out of the transport account.
- Constrain ingress to the Remozio hostname only.
- Add same-user read/misuse attempts and ingress-modification attempts to the §16 transport acceptance cases.

**UX impact:** None, if the credential is held under protected custody and used inside the existing admin-authorized flows. If instead the chosen design has the user supply the credential at each enrollment or repair, that adds a manual step and needs user consultation.

## Assessed without findings

- **Rev 16 update-boundary resubmission (§17 "Automatic activation and optional drain"):** safe as written. Resubmission is gated on an authenticated, submission-bound no-admission result; unknown or lost results fall back to reconciliation or reported uncertainty; a fresh capture and decision are required. The residual risk is UX only: a connection interrupted mid-replacement surfaces as uncertainty rather than a transparent wait. That is an implementation-tuning concern, not a defect.
- **On-disk replacement treated as activation:** consistent with §3 protected placement and with the §17 quiescence, floor-commit, and restart-matrix rules.
- **Decision-key update-scheduling purpose:** it can affect only availability and cannot supply artifacts or floors. It is consistent with the key separation in §6 and §7.
- **Consistency checks:** scope classification (§1, §6, §9), multi-phone first-valid consumption, revocation serialization, presence routing and handoff, push/relay privacy, and negotiation/downgrade handling (§18) are consistent with the earlier invariants. Allow-once is not widened beyond Little Snitch.
- **Remaining uncertainties are scheduled feasibility gates with failure and consultation paths, not planning defects.** These are:
  - privileged install and anti-rollback placement
  - generation-bound receiving keys
  - pre-login key custody
  - single-biometric credential release
  - 1Password and Little Snitch fixtures
  - descriptor-based exec and sudoers policy
  - local command approval
  - background Access authentication

**Deferred preferences, not findings:** the idle threshold and retention duration.

**Implementation limits:** none of the platform assumptions are verified here. Correctness still depends on:
- real-device and real-macOS evidence from the stated gates;
- conformance tests against the cross-language vectors;
- independent implementation review.

**SUBSTANTIVE FINDINGS REMAIN**