Local bystander detection is necessary, but not sufficient

I’m increasingly convinced that mixed-reality glasses should be required to handle bystander detection locally when they recognize, blur, or label people in a public place. Keeping identifiable video or biometric material on the headset can reduce the breach and scope-creep risks of a centralized system, even if it does not make the processing harmless.

The uncomfortable part is that local recognition can still enable profiling, false matches, or covert social filtering. “Local” describes where the inference happens, not whether the person being observed has any meaningful protection. Detection, identification, and attribute inference also shouldn’t be casually bundled together.

I’d support a visible, auditable “bystander protection” mode with transient processing, immediate deletion, documented behavior, demographic/error testing, and absolutely no cloud fallback. Should that be a manufacturer requirement? Disagree, suggest implementation ideas, or explain how you’d verify the feature actually works.

The no-fallback requirement is the important bit. A mode that quietly uploads when the local model is uncertain is not local protection; it is an availability feature wearing a privacy label. I’d also want the device to fail closed when the protection subsystem crashes, not continue recording by default.

I’d separate the legal or policy requirement from the engineering requirement. The brief supports local matching as a risk reduction, not as a complete privacy solution. Any mandate should specify the behavior being protected, because “bystander detection” could mean very different things from identification or age estimation.

A visible indicator helps, but only if people can understand it at a glance. A tiny status icon is basically theater in a crowded street. I’d prefer a persistent outward-facing signal plus a short plain-language explanation, even if that makes the product slightly less sleek.

Auditability is where this gets difficult. A manufacturer-controlled log can prove what the software claims it did, not necessarily what the camera pipeline actually exposed. Reproducible builds, hardware-enforced network isolation, and independent testing would be more convincing than a dashboard screenshot.

I agree in principle, but “required” creates a product problem if the protection mode makes the glasses unreliable in ordinary lighting or crowded spaces. Users will disable anything that constantly mislabels people or blocks useful overlays. The mode needs a graceful, privacy-preserving degradation path, not just a compliance checkbox.

This is a good case for a local-first contract: the core behavior must remain useful offline, and synchronization should not be a prerequisite. I’d publish a small machine-readable state report showing whether frames, templates, or confidence data ever crossed the device boundary.

Small terminology point, but it matters: blurring a detected face is not automatically face recognition. The testing and risk analysis should name the actual task. Otherwise a vendor can claim strong performance for detection while users assume it has prevented identification.

I’m not sure a visible protection mode should be mandatory if bystanders cannot meaningfully opt out anyway. It may create false reassurance: people see the badge and assume they are safe, while local inference still sorts them into categories. Perhaps the requirement should be limits on outputs, not just processing location.

Immediate deletion sounds straightforward until you define the buffer. Frame queues, crash dumps, telemetry, model caches, and debugging traces are where these promises usually get fuzzy. The audit spec should test the ugly paths: power loss, exceptions, updates, and diagnostic mode.

Independent verification would need repeatable test scenes and a chain of custody for the device. Otherwise every party can blame lighting, firmware, or an “unsupported configuration.” I’d want published failure cases, not only aggregate accuracy, and a way for an auditor to inspect the no-network claim.

Make the mode a physical switch, document it, and let skeptics inspect the results. If the feature requires a marketing page and a trust-me certificate, it is probably not a feature. Also, glasses that cannot protect bystanders without a cloud service should simply say so.