- Local gateway core remains the trust anchor.
- Routes, DNS, fallback rules, and policy changes should be visible before apply.
- Named ownership for route policy, DNS policy, and fallback behavior should stay clear before guided changes begin.
- Managed services are optional operational layers, not required traffic owners.
Trust and security
Local control first. Support only with explicit approval and recovery.
The Gateway is designed so route intent, DNS behavior, fallback policy, credentials, support evidence, recovery access, and final approvals stay under operator control.
- Remote access must be explicit, time-limited, revocable, and logged.
- Support bundles should be operator-generated and redacted before export.
- Support should not require default traffic inspection or credential custody.
- Evidence should separate assumptions, observed paths, known leaks, and remaining risks.
- No single gateway can guarantee anonymity by itself.
- Endpoint compromise, browser fingerprinting, logged-in accounts, and payment trails remain outside gateway proof.
- Confirm console, SSH, or local recovery access before route, DNS, firewall, or remote-access changes.
- Keep a known-good rollback target for policy, resolver, and transport state.
- Stop the change window if safe recovery or the final approver is no longer clear.
Decision ownership
Keep route, DNS, fallback, recovery, and support authority named before changes start.
The operator owns route intent and final apply approval.
Support can review policy and validation evidence, but should not become the default route owner for a live environment.
The operator names who controls resolver policy, upstream DNS, and rollback.
Guided changes should stop if resolver authority, rollback ownership, or current DNS state becomes unclear.
Fallback behavior needs a named owner and a visible trigger.
Privacy posture claims depend on whether fallback is disabled, degraded, or allowed, so support should document the operator-approved mode before testing.
Recovery authority stays with the operator before, during, and after the change window.
Console, SSH, or local recovery access should be proven first, with a known-good rollback target for policy, resolver, and transport state.
Support operates inside a bounded, revocable, operator-approved window.
Remote access, evidence scope, and stop conditions should be explicit so support remains advisory or tightly scoped instead of becoming a standing control plane.
Reporting path
Use a scoped evidence path before sharing sensitive details.
- Start with
SECURITY.mdfor vulnerability reporting expectations. - Share minimal initial detail until a secure exchange path is agreed.
- Do not route sensitive security findings through public issues or broad mail threads.
- Use the public evidence checklist to separate route, DNS, fallback, recovery, and privacy posture proof.
- Redact bundle contents before export and keep the diagnostic scope narrow.
- State what was observed, what remains uncertain, and which operator approved the evidence share.
- Use guided support only after route ownership, DNS ownership, fallback authority, and rollback responsibility are named.
- Confirm recovery access before remote help or live policy changes begin.
- Keep remote access explicit, time-limited, revocable, and logged.
Cross-check support bundle redaction, public evidence expectations, and support boundaries before sending diagnostics or opening a live support window.