One-line answer: smart glasses constantly shout tiny Bluetooth advertising packets — an app just listens, matches the packet's possible payload pattern, and uses signal strength to guess how close they are.
Local simulation only: fictional packet identifiers and modeled signal values. No device scan, model identification or recording-state measurement.
Part 1
Anatomy of a BLE Advertising Packet
Advertising BLE devices can broadcast packets without pairing; rates and contents depend on implementation and operating state. Hover or tap each field below to see what it carries and why it can identify a device type. Sample bytes shown for a fictional manufacturer, AcmeSpecs smart glasses.
Tap a field
Select any segment of the packet to learn what it does and how detection apps use it.
Part 2
Room Scanner Simulation
Drag the glasses around the room (or use arrow keys after clicking the canvas). RSSI is computed live from a log-distance path-loss model. Cross the wall to see attenuation kick in; drag past range and the scanner loses the signal.
Distance—
RSSI—
DetectionNO SIGNAL
Part 3
Why MAC Randomization Isn't Enough
Modern devices rotate their MAC address to resist tracking. Press the button to simulate a rotation and watch which fields actually change under each strategy. Amber fields persist — that persistence is the fingerprint.
Part 4
What You Can and Can't Detect
BLE scanning is a presence signal, not surveillance-camera detection. Honest limits matter.
A scanner CAN tell you
A BLE device matching a known smart-glasses signature is advertising nearby.
A rough proximity estimate from RSSI (near / mid / far).
Whether the same fingerprint keeps reappearing over time.
It CANNOT tell you
Whether the camera is recording — this fictional payload contains no camera-status field; real products need protocol-specific evidence.
Exact distance or direction; RSSI is noisy and reflects off walls and bodies.
Anything if Bluetooth is off. Silence is not proof of absence.
Zero false positives: earbuds, watches, and shared chipsets can look similar.
Part 5
Check Your Understanding
Five quick questions with instant feedback.
Separate signal strength, product clues and identity
Can a received packet prove that someone is wearing recording glasses? A radio observation, a product classification and a recording-state claim require different evidence. This page uses fictional AcmeSpecs bytes and a chosen room model. Its badges describe modeled signal strength, not classification confidence. No Bluetooth scan or permission request occurs.
Worked RSSI example
The initial 300-pixel separation at 28 pixels per metre gives d=10.714 m. With the chosen 1 m reference −59 dBm, exponent 2.4 and wall loss 8 dB: RSSI = −59−24×log10(10.714)−8 ≈ −91.7 dBm. Removing the wall adds 8 dB, giving −83.7 dBm. Distance is taken from canvas geometry, not estimated from measured RSSI. The reference is received power at 1 m, not radio transmit power.
Calibration and privacy limits
Distance is floored at 0.3 m; the page uses a −99 dBm cutoff and an authored 25 m range limit. Signal bands use −65 and −82 dBm. These are chosen thresholds without test data, noise, missed-packet rates or uncertainty. The bounded canvas cannot reach the 25 m cutoff, although low signal can cross −99.
Address rotations are arbitrary random hex strings, not valid Bluetooth private-address cryptography. Manufacturer data and service UUIDs may be shared; a recurring pattern is not necessarily the same individual. Advertising payloads can also change. No original export is provided; screenshots document only this fictional simulation.
Primary specifications and browser access
Bluetooth’s GAP privacy guidance recommends avoiding identifying advertising data and synchronizing data changes with private-address changes. Chrome’s Web Bluetooth documentation describes secure contexts, a user gesture and a chooser for requestDevice. That permission model is distinct from this simulated listening illustration; actual platform support must be checked separately.