0038: Remote control is given, never taken

Status: accepted. The short code is superseded by 0043: the host gives control with one click while sharing a screen. Since 0046, whoever shares, host or guest, gives control of their own screen, with the same protections.

Context

Whoever controls the keyboard can do anything the host can: open a terminal, read files and keys, change settings. Remote-control tools are a common route for scams. Signaling passes through Cloudflare, which could in principle swap a guest for someone else. And the operating systems protect less than they appear to:

• In the spikes, macOS's secure input (password fields) still let injected keys through.
• On Windows, injected input counts as the host's own activity.

Decision

• Off by default. Guests watch and talk. A guest asks for control; only the host can give it, to one guest at a time.
• Short code.
  • Before control can be given, host and guest compare a code out loud. It's derived from both peers' DTLS certificate fingerprints and the invite token.
  • Before each connection, the side that will answer commits to its certificate (a hash of its fingerprint) through signaling, and only then receives the offer; the offering side refuses an answer whose certificate doesn't match. Someone in the middle has to pick a certificate for one side before seeing the other's, so they can't search for a pair whose six-digit codes match. Offers nobody asked for are ignored, and every fingerprint in a description must be the same.
  • A new connection (a reconnect) gives a new code: its confirmation is cleared and control comes back to the host.
  • Different codes mean someone is in the middle. The host should end the session.
  • The dialog asks the host to confirm the codes match.
• The host always wins. Any input from the host's own mouse or keyboard takes control back at once.
  • macOS: guest events are posted at the session level (kCGSessionEventTap), so the HID "seconds since last event" counters only move for real hardware. Pair stops the guest when they drop.
  • Windows: injected input resets GetLastInputInfo, so Pair runs low-level mouse and keyboard hooks. It treats an event as the host's when it isn't flagged LLMHF_INJECTED/LLKHF_INJECTED and doesn't carry Pair's dwExtraInfo tag.
• Places a guest's keys never reach:
  • macOS: while secure input is on (IsSecureEventInputEnabled), Pair drops guest keys itself.
  • Windows: windows running as administrator, which UIPI blocks silently. Pair detects them through the foreground process's token and says "This window runs as administrator; only you can use it".
  • Apps the host lists, by default password managers, Keychain Access and System Settings. Clicks and keys aimed at them are dropped.
  • System shortcuts that end or switch the session (⌘Q, ⌘Tab, Win+L…) are never forwarded.
• How guests type: as text, so keyboard layouts don't matter.
  • On Windows, a character on the host's layout is sent as that layout's keys (VkKeyScanExW). Only characters the layout lacks go as KEYEVENTF_UNICODE; the new Notepad turns some of those into spaces.
  • Shortcuts go as key codes.
  • Positions go as fractions of the shared display.
• Visible while it lasts: a cyan frame around the shared screen and a banner on the host's screen ("Ana Lima has control. Move your mouse or touch a key to take it back."). The guest's cursor carries their name.
• No unattended access, ever. Control ends when the session ends, or after the guest is idle for a while. Control events travel only on the encrypted data channel. There's no clipboard or file transfer in v1.

Consequences

• Scams and slips: a scam still needs the host to give control after a warning, a code check and a visible frame, and the host can take it back by touching anything. Password fields and the host's protected apps stay out of reach even then.
• Edge cases: Pair's own checks must cover secure input on macOS and administrator windows on Windows, because the operating systems don't stop injected input there.
• Permissions: remote control needs Accessibility on macOS, asked the first time the host gives control, not at install. No permission is needed on Windows.
• Limits of the low-level path: some games and apps that read hardware directly won't see the guest. Windows' secure desktop (UAC prompts) can't be seen or controlled.