0046: The sharer gives control, anyone asks

Status: accepted. It extends 0038 and 0043 to a guest's screen, and replaces the consequence in 0042 that guests' screens are never controlled. The rest of those stands.

Context

Testers wanted a guest who shares their screen to be able to hand the keyboard over, as the host can, and anyone in the call to be able to ask for control of whatever is being shared. They also wanted to ask each other to unmute, turn on a camera or share, instead of saying it out loud. Until now control applied only to the host's screen, and only a guest could ask, only the host could answer. Remote control is a common route for scams, and letting a guest's computer be driven turns the trust model around: a host could invite someone and then ask to control their computer.

Decision

• The sharer gives control. Whoever shares a screen, host or guest, can give control of that screen to one other person in the call, the host included. Nobody else can give it. Control is tied to the screen it was given for (Signal::Control says whose screen) and ends when that turn ends, when either person leaves or reconnects, or when the sharer touches their own mouse or keyboard.
• A guest's computer gets the host's protections. On a guest who shares, the helper injects with the guest's own protected apps from Settings › Pair, drops keys while macOS secure input is on and into administrator windows on Windows, asks for Accessibility the first time, and shows the control frame and banner. The first time a guest gives control in a call, Short Leash asks them to confirm, naming who will be able to use their mouse and keyboard and how to take it back.
• The guest's Short Leash checks too. It remembers who it gave control of its screen to, and refuses control of its screen by anyone else even if the host's leashd says so; the host can't hand someone a guest's computer by itself. leash pair give-control on a guest is the person's own command and doesn't show the first-time confirmation.
• The host relays and checks. Control of a guest's screen goes through the host's leashd like every signal: it accepts a Control for a guest's screen only from that guest while it's their turn, and only to someone in the call who isn't in a browser or away. The host can still end any turn, which takes control back.
• Anyone can ask anyone. An ask (Signal::Ask) is for one of: turn your microphone on, turn your camera on, share your screen, or give control of the screen you share. The one asked sees a notice with one action and Not now; nothing turns on until they say yes. A yes to sharing ends the current sharer's turn and starts theirs; the host's leashd makes that change when it passes a guest's yes on, so turns still go through the host.
• Limits, kept by the host. One open ask of a kind from one person to another; an ask runs out after a minute; after Not now the same ask waits 30 seconds; six asks a minute per person. A browser guest can only be asked to unmute. Answering an ask is never possible from the CLI or MCP.
• Mixed versions. An older version of Short Leash drops messages it doesn't know, so an ask to it runs out unanswered and a guest on an older version of Short Leash can't give control. No new capability flags.

Consequences

• Control both ways is a new risk. A guest's computer can now be driven, which is what scams look for. The guard is the same as the host's: only the person whose screen it is can give control, they confirm the first time with the controller's name in front of them, everything shows while it lasts, and their own hand takes it back at once.
• Guests may see the Accessibility prompt the first time they give control, on macOS. Nothing is asked when they only watch or talk.
• Asks replace saying it out loud, and the limits keep them from becoming a way to nag.
• CLAUDE.md's invariant 12 now says the sharer gives control, not the host.