docs: remote-control design + threat model (LC-182) #226

Merged

nrupard merged 2 commits from docs/lc-182-remote-control-design into main 2026-05-26 21:35:07 +02:00

Conversation 0 Commits 2 Files changed 1 +108

nrupard commented 2026-05-26 21:26:11 +02:00

Owner

Copy link

Closes LC-182 (the design subtask of the LC-181 remote-control story).

Adds docs/superpowers/specs/2026-05-26-remote-control-design.md covering:

• Trust + threat model (what the verified-email gate does and doesn't buy; consent friction + kill-switch as the real defenses).
• Verified-email gate both ways, server-enforced at the signaling relay, with the saas-vs-standalone "what counts as verified" question handed to LC-183.
• Consent lifecycle (request -> grant/deny -> active banner+kill-switch -> manual/auto revoke), invariants (one controller, gated affordance, block-list aware).
• Transport: low-rate control signaling (extend CallSignal / relay_call_signal) vs the high-rate input WebRTC data channel; normalized [0,1] DPI-independent coordinates.
• Platform matrix: Windows SendInput first; Linux (uinput/XTEST) + macOS (CGEvent + Accessibility) deferred with gotchas (UIPI, Wayland, the macOS grant).
• Audit + limits.
• The settled "why not a browser" rationale (sandbox, not hardware acceleration) so it isn't re-litigated.

Docs only - the foundation LC-183..186 build on.

Closes LC-182 (the design subtask of the LC-181 remote-control story). Adds `docs/superpowers/specs/2026-05-26-remote-control-design.md` covering: - Trust + threat model (what the verified-email gate does and doesn't buy; consent friction + kill-switch as the real defenses). - Verified-email gate both ways, server-enforced at the signaling relay, with the saas-vs-standalone "what counts as verified" question handed to LC-183. - Consent lifecycle (request -> grant/deny -> active banner+kill-switch -> manual/auto revoke), invariants (one controller, gated affordance, block-list aware). - Transport: low-rate control signaling (extend `CallSignal` / `relay_call_signal`) vs the high-rate input WebRTC data channel; normalized [0,1] DPI-independent coordinates. - Platform matrix: Windows `SendInput` first; Linux (uinput/XTEST) + macOS (`CGEvent` + Accessibility) deferred with gotchas (UIPI, Wayland, the macOS grant). - Audit + limits. - The settled "why not a browser" rationale (sandbox, not hardware acceleration) so it isn't re-litigated. Docs only - the foundation LC-183..186 build on.

nrupard added 1 commit 2026-05-26 21:26:11 +02:00

docs: remote-control design + threat model (LC-182) ... b4c8820cf4

Foundational design for the LC-181 remote-control story: trust/threat model, the verified-email gate (both ways, server-enforced, with saas-vs-standalone semantics to settle in LC-183), the consent lifecycle (request/grant/deny/active/revoke + auto-revoke), the signaling-vs-data-channel transport split with normalized [0,1] coordinates, the platform matrix (Windows SendInput first; Linux/macOS deferred with their gotchas), audit + abuse limits, and the settled rationale for why the controlled side must be the native app, not a browser (sandbox, not acceleration).

Docs only.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

nrupard added 1 commit 2026-05-26 21:31:22 +02:00

docs: address LC-182 design review - de-risk the subtask handoffs ... 6413497df0

Folds the review findings into the design so LC-183..186 don't rediscover them:

- Signaling: recommend dedicated ChatEvent variants over extending CALL_SIGNAL_KINDS (that const is a whitelist + relay_call_signal special-cases kinds like invite-glare, so reuse is necessary-but-not-sufficient); gate slots next to the existing fail-closed is_blocked_either_way check.
- Input data channel: open up-front in the initial offer (avoid onnegotiationneeded mid-call); the controlled/desktop side creates it.
- Verified-email gate: spell out that the saas (a) "auth is verification" vs (b) "populate the column" paths are different trust models, not interchangeable (b silently denies if unpopulated); LC-183 picks deliberately.
- Injection: note the desktop crate is already Tauri 2 and no injection code exists yet; LC-185 picks enigo/rdev vs raw win32; the JS->native bridge is the desktop trust boundary - native must re-assert grant-active before injecting, never trust the channel alone.
- Kill-switch ownership: it belongs to the controlled (desktop) side; the controller has none (it isn't being controlled) - UI asymmetric by role, not client type.
- Stuck-key prevention: mandate the controlled side track held keys/buttons and force-release on revoke / kill-switch / abrupt channel drop or heartbeat timeout.

Docs only.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

nrupard merged commit 333a519f97 into main 2026-05-26 21:35:07 +02:00

nrupard deleted branch docs/lc-182-remote-control-design 2026-05-26 21:35:08 +02:00

nrupard referenced this pull request from a commit 2026-05-26 21:35:09 +02:00

Merge pull request 'docs: remote-control design + threat model (LC-182)' (#226) from docs/lc-182-remote-control-design into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

psa-systems/lets-chat!226

No description provided.