# Security and privacy

Pairing grants a role in a session. It does not grant every capability of the computer or every private view in a game.

## Keep authority separate

Player, host, spectator and reconnect credentials serve different purposes. A player QR contains only join authority. A host token must stay with the authorized game process. Resume tickets rotate after use and are bound to their endpoint/session.

The companion's owner actions require a locally authenticated owner. A remote phone cannot enable its own mouse and keyboard access. Match the phone's identity/code before approving it; approval is revoked when its connection changes.

## Release stale controls

Clients neutralize held input on blur, backgrounding or disconnect. Servers reject stale sequences and neutralize silent input. Native helpers add an independent release path on shutdown/watchdog. These layers must be tested together, because a connected socket can become silent without closing immediately.

## Protect private game information

Keep private roles, answers and clues separate from public state. Send each private view only to its player. Do not rely on CSS blur, a hidden button or a UI condition to protect data that was already broadcast.

Player names and event payloads are untrusted. Render text as text, validate actions against the game phase, and enforce message, rate and attempt limits.

## Transport

Use HTTPS/WSS for internet traffic. Local browser HTTP exists to keep base controls useful on a LAN; it is not equivalent to an encrypted internet connection. The native pinned-TLS companion route is being completed before production remote system control is enabled.

Never bypass certificate errors or disable global security settings to make pairing appear successful. A route that cannot satisfy its security requirements must fail clearly or use a permitted alternative.

## Purchases and secrets

Only the vendor's verified receipt path may grant paid hosted resources. A local preview flag or client-supplied Pro boolean cannot do so. Do not send store receipts to arbitrary developer endpoints.

Public repositories contain source, placeholders and public verification material only. They must not contain private keys, store/service credentials, real receipts, production environment files, customer data or private hosted-server/website code. Hooks and CI scan staged content/history; they supplement review and repository access controls.