# Review of Remozio plan, revision 17

## Finding 1: Push-gateway recipient mapping has no named authority (Low–Medium)

**References:**
- §15 "Bind and rotate registration tokens"
- §15 "Recipients and first-valid-decision resolution"
- §16 "Cloud management authority" (credential table)
- §16 "Keep push separate from the live proxy"
- §16 "Cloudflare Tunnel endpoint" (uninstall and repair)

**Defect.** The plan has three requirements for the notification gateway:
- It must "enforce its enrolled recipient mapping."
- Revocation must stop future pushes.
- Uninstall and repair must rotate or revoke the Mac's gateway access server-side.

The revision 17 credential table assigns every other cloud-side authority to a holder, but none of these three. The Mac push-submission credential only "send[s] opaque wakes to its enrolled recipient mapping." Gateway policy belongs to "its operator." That leaves open who may add or remove a phone registration for a given Mac, or revoke that Mac's submission credential. The §15 phrase "authenticated registration" does not say whose authentication the gateway checks.

**Failure scenarios:**
- **Phone-authenticated mapping.** If the phone's own registration authenticates mapping changes, a revoked phone can re-register or keep its token. It keeps receiving wake metadata for that Mac. This contradicts "Revocation stops future pushes."
- **Transport-credential mapping.** If mapping changes ride on the transport-held push-submission credential, a compromised transport account can redirect wakes. The credential separation that revision 17 introduced collapses.
- **Operator-only mapping.** If only the gateway operator can change mappings, then enrollment, revocation and uninstall each need manual operator action. The plan does not disclose or consult on that extra step.

Wake payloads are opaque, so no approval authority is exposed. The concrete harms are:
- Wake-timing leakage to revoked devices.
- Misdirected or spam wakes.
- An unenforceable revocation and uninstall promise.

**Minimal correction.**
1. Add a table row for recipient-mapping authority.
2. Have mapping additions and removals, and Mac submission-credential rotation and revocation, authorized by the root authority or the setup controller. Use the existing administrator-authorized enrollment, revocation, repair and uninstall operations, under a distinct signed purpose.
3. Require the phone's token registration to be bound to that Mac-signed enrollment record.
4. State whether the user operates the gateway or it is a hosted service. If operator action is ever required during normal lifecycle operations, record it as a consultation item.

This correction adds no approval steps, biometrics or manual steps.

## Assessed without further findings

- **Key separation and scope classification.** I checked biometric, decision, transport, management, Access and push credentials. The Little Snitch one-time exception stays confined to Little Snitch and is enforced by both verifiers. The update-scheduling purpose cannot alter floors or supply artifacts.
- **Relay resistance.** Payloads are encrypted end to end and requests are authority-signed. Access is additive, not a substitute for Remozio authorization.
- **Negotiation downgrade and replay.** Negotiation transcripts are bound, signatures are domain-separated, and requests are never re-encoded into weaker schemas.
- **Update path.** The protected-placement and anti-rollback invariant is enforced outside the candidate binary. Floor commits are transactional, the quiescence rule does not kill work, the resubmission rule prevents replay, and the setup controller is included in the release manifest.
- **Earlier invariants against later sections.** These hold against expiry handling, the restart matrix, audit atomicity, presence routing and push lifetime.

Items that are correctly scheduled rather than defects:
- Descriptor-based execution.
- Sudoers compatibility.
- Single-biometric credential release.
- Local command approval.
- Cloudflare credential scoping.
- Pre-login key custody.

Each is a defined feasibility gate with a failure and consultation path. The idle interval and audit retention duration are deferred preferences and were not treated as findings.

## Remaining limits

These are platform facts that only implementation work can establish:
- Whether an old signed build can be isolated from current receiving keys.
- Whether macOS service management can be updated without renewed authorization.
- Actual Accessibility behaviour of 1Password and Little Snitch.
- FCM reliability under Doze.
- Access service-token behaviour in background delivery.

SUBSTANTIVE FINDINGS REMAIN