Cameras raise privacy issues for people being captured

What it is

A headset that must see the room has cameras on the front. People talking nearby, papers on the table, a whiteboard behind the wearer, all enter the frame — they are not the user, yet they are being captured. Bystander privacy is that asymmetry: the wearer opened the cameras for tracking and see-through; the people in the frame did not choose, and often do not know they are already in it.

The issue is a camera pointed at public or semi-public people, not the wearer’s own account settings.

Why it happens

SLAM and video see-through need a continuous outward image. Continuous and “currently recording” look like the same thing from beside: a lens aimed at you. Phone photography has a lifting gesture; a headset has no such gesture, so capture moves from an observable act to a device default. Faces, badges, screen contents, the background of a conversation appear in the frame; once those leave the device — saved, uploaded, read by an app — the harm shifts from “being seen” to “being taken away.”

WebXR lists pose and spatial data as sensitive, mostly protecting the wearer. Third parties in the same picture are not automatically covered. Meta’s passthrough camera API treats the image as device-user data and asks for a runtime permission — a relation between app and wearer, which is not the same as the person beside agreeing.

Studying it

Denning, Dehlawi, and Kohno interviewed café bystanders with a mock-up: many never noticed the device; those who did named “I might be being recorded” as the main difference from existing cameras. Later work conditions on whether a face appears, whether frames leave the device, and on data path (on-device tracking only / saved / uploaded), and collects discomfort plus the judgment “am I being captured.”

Independent variables: whether the camera is actually producing frames, whether data leaves the device, whether identifiable people are in the scene. Dependent variables: bystanders’ judgment that they are being captured, discomfort ratings, whether they choose to leave.

A dummy that does not look live underestimates the “it is shooting” judgment. A working see-through headset is the object this leaf should measure.

Where it stops holding

Alone at home, lens on an empty wall, there is no captured person and the constraint sleeps. A physically shuttered camera that coasts on IMU for a short stretch produces no new picture. In a space already full of CCTV, the extra headset path is still closer and more likely to carry a facial close-up — “there are already cameras here” does not cancel it, though the base rate changes how strongly people react. Writing “whether to put an indicator light” or “whether to ship a unified notice-and-consent form” as the design is already past the phenomenon that cameras create a privacy issue for people in frame.

Applying it

• Default outward images to on-device tracking. Do not treat passthrough frames as shareable, trainable, or uploadable material.
• If an app needs frames out or saved, tell the wearer that people beside will be in the picture. A refusal must not lock unrelated features.
• For acceptance, write a data-path table: each camera stream is local, cached, or off-device. Any path that cannot be named is handled as capturing bystanders.
• How to check: turn on see-through in a room with another person and ask that person “do you think you are in the picture now?” Then check the fact: is their face in a frame, did that frame leave the device. The gap between judgment and fact is the live form of this privacy issue.

Related

• Same group：N5.06.1 The wearer's actions are unintelligible to bystanders · N5.06.3 Social acceptability constrains where the device can be used
• Nearby：N5.11 Bystanders and Social Acceptability · N2.13 Physical Safety of Input (Collisions and Bystanders)
• Search terms：bystander privacy · incidental capture · outward-facing camera