C4.17.3Cross-user command injectiondesignresearch

Misattribution treats one person's motion as another person's command

Aliases: misattribution · command billed to the wrong user · cross-user execution

What it is

Misattribution is not a missed gesture. The class is right and the bill is wrong: the motion is posted to someone else's session. A is confirming a payment, paging through a record, or dragging a timeline; B's swipe is taken as A's confirm or drag. For A the interface advances without a matching action; for B an idle or other-directed motion produces a consequence B may never see. The error is cross-user command injection, not a false negative on a recognition scorecard.

Why it happens

The usual pipeline is: detect motion → classify → deliver to “the current session.” If the session pointer is bound to the wrong person, a more confident classifier produces a cleaner wrong execution, and “just do it again” may keep charging the same wrong account. Shared displays hide the damage: B may stand off-axis and never see A's dialog; A may never see B's hand. In surgical navigation, classroom clickers, or household account switching, “current user” is tied to permission, privacy, and billing, so one swapped owner crosses an isolation boundary. If undo stacks are per session, the injected party may not even have an undo entry.

Studying it

Script a scene where one person sits in a high-consequence intermediate state and the other performs a low-consequence or unrelated motion—A paused on a confirm dialog, B waving to a companion. Record whether the wrong command ran, whose session it hit, whether A noticed, and whether B knew they had triggered the system. Code these events separately from “the motion was not recognized.” Vary relative angle and screen facing to see how visibility changes detection and report delay. Do not fold everything into overall accuracy; injection averages away.

Where it stops holding

If both people are already editing the same shared object (dragging one map, flipping one album), the harm of “whose ledger” drops and the live issue becomes concurrent-edit conflict. A single-user headset never admits another person's hand into the same input stream, so this error shape does not appear. Harm scales with session isolation: on a public query kiosk, a swap is mostly an annoying page jump; bound to payment, a medical record, or a door, the same swap is a security event. When a child mimics an adult's gesture, the classifier is often more correct, and injection risk rises rather than falls.

Applying it

  • Log “class correct, user wrong” as its own audit event; do not merge it into recognition-failure counts.
  • Before a high-consequence step, add a sender-visible identity check (highlight that person, speak a name, or require a short face-the-screen confirm) so a hand at the side cannot complete the dialog of the person in front.
  • Put undo on the session that actually changed, and let the injected party see “that was not your hand.” Walk two-person scripts through pay, delete, and submit, not only the single-user happy path.

Related

  • Same group: C4.17.1 When several people share the sensing volume, the system must decide who owns the current action · C4.17.2 Attribution depends on identity features, not on the motion itself · C4.17.4 Arbitration rules must be predictable to users, such as first-come or nearest-person
  • Adjacent: C4.27 Decoupling gestures from consequence severity · C4.30 Bystanders and third parties
  • Search: misattribution · cross-user command · session isolation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C4.17.3