A Privacy Signal the Smart Glasses Industry Can Test

The usual recording-light design leaves a failure built into the product. A manufacturer puts a camera in a pair of glasses, adds a light the person being filmed may never notice, then leaves everyone else to negotiate consent in real time. NearLens can observe compatible Bluetooth signals nearby, but an outside detector can report only what the hardware chooses to reveal.

Paul Stefaan Mooij, founder of PMSG, approached that problem as a hardware designer. His team is developing PMSG, an open-source architecture for smart glasses, and published the BLE privacy signal before the glasses reached commercial release. That order matters. Privacy enters the hardware design before an assurance is added to the finished product.

NearLens is partnering with the PMSG project to implement detection of the convention in an upcoming iOS release. The app is being developed to distinguish compatible wearables that are idle, actively recording video or using a live microphone. This adds genuine real-time recording-state awareness on top of NearLens's existing presence detection and would make NearLens one of the first consumer iOS apps built to recognize the PMSG signal.

Our partnership with PMSG moves NearLens beyond presence awareness toward a clearer, real-time account of what compatible wearables say they are doing. PMSG has turned a difficult public-interest problem into an open convention the industry can test, challenge and improve.

The PMSG repository lays out the whole proposal in one README. PMSG means Prototype Modular Smart Glasses. Developed openly by TeQMeQ/Control-C, it is a proof of concept and a preference protocol: not a kill switch, not a detector.

The convention gives each state a compact marker: 📵 means a bystander is asking not to be recorded; 📷 means a wearable has a camera on board but is idle; 📸 means photo or video recording is active; and 🎤 means the microphone is live. A suitable phone app or inexpensive Bluetooth tag can advertise the bystander request while compatible glasses advertise their own state.

The service data uses a one-byte bit field. An idle camera that honours do-not-record requests is represented differently from an active camera. A scanning device does not need a cloud account, a person's name or a location history to process the state.

The implementation is deliberately plain. There are workshop UUIDs for a Recording Presence Service and a Do-Not-Record Request, example advertising names, sample ESP32 code and instructions for testing with nRF Connect. When recording starts, the wearable changes its advertised state. If it claims to honour a nearby request, it should refuse to open a new clip and tell the wearer why.

That warning can become a useful product interaction rather than a dead end. The glasses might explain that a nearby person has requested no recording or that the venue has published a no-recording policy, let the wearer acknowledge the notice and keep advertising the device's state. If capture continues, PMSG proposes recording whether a do-not-record signal was present and what kind of capture occurred in the file's metadata. The README suggests fields for the protocol version, request state and capture mode.

PMSG is equally direct about what this cannot do. It is a preference protocol, not a kill switch or a universal hidden-camera detector. It cannot force an uncooperative device to identify itself. Bluetooth range is local, not city-wide. Browser-based advertising is unavailable on iOS, so an iPhone needs a native app or operating-system feature. Those limits make the proposal more credible because they draw a clean line between signalling and enforcement.

The convention is not yet an adopted Bluetooth standard, but it raises the level of the industry conversation. Instead of asking the public to accept vague assurances, PMSG offers a concrete service UUID, a compact status field and behaviour that competing teams can test, challenge and improve. Whether manufacturers adopt this exact design or refine it through a standards body, the initiative deserves serious public discussion because it establishes a more ambitious baseline: recording devices should communicate what they are doing.

A recording light asks a person across the room to notice a tiny physical cue and interpret it correctly. A BLE state lets nearby software read information the glasses already possess internally. The device knows whether a camera is present, whether capture is active and whether audio is being recorded. Exposing those facts does not solve consent, but it stops pretending the bystander should infer device state from industrial design.

The metadata carries evidence of the request past capture. A social platform could detect it during upload, warn the person posting, ask for more context or apply a policy chosen for that service. Regulators could define how recording applications preserve and respond to the field without prescribing one brand of glasses. The repository does not claim that Meta, TikTok or any other platform does this today. It creates a technical point where product rules and legal duties could connect to what happened when the file was made.

That is more ambitious than detection alone. A shared signal could connect four decisions that currently happen in isolation: what the bystander requests, what the wearable reports, what the recording application permits and what the publishing platform accepts. Each participant can still refuse. The refusal becomes visible instead of disappearing into a light nobody saw.

Mooij sees operating-system support as the next layer. Apple, Google and other platform vendors could make the preference available at system level, then combine it with user-controlled context. A home, a family event and a public children's pool can have different recording expectations. Apple Maps, Google Maps, Yandex Maps, Baidu Maps, Amap or a recognised Wi-Fi network could help people discover a venue's recording policy before capture begins. These services would surface the rule, not enforce it automatically. A location-based policy cannot replace individual consent, and a privacy feature should not create a new log of who was present.

Open platforms make that experiment easier. MentraOS publishes an open-source smart glasses operating system with a developer SDK and access to camera commands across compatible devices. A separate Mentra Community repository contains open-source smart glasses hardware files covering its mechanical design, electronics and software. Neither linked project page mentions a PMSG implementation. Together they show that a recording-state layer can be tested in open software and hardware before a large closed ecosystem decides to support it.

The protocol does not need polite encouragement from the industry. It needs forks, test devices and specific objections. The teams behind Meta smart glasses and Snap Spectacles can influence how the rest of the market behaves. Brilliant Labs works openly enough to test unusual interaction models early. Vuzix already sells camera-equipped hardware and developer access, while Rokid builds glasses around a camera, display and AI features. Each of those teams is close enough to the problem to answer a useful question: what would prevent its hardware from broadcasting its recording state?

Adoption does not require accepting every PMSG choice. A company can dispute the emoji-based names, propose different UUIDs, challenge the one-byte flag layout or explain why a camera state cannot update within one second. That would still move the work forward. Silence leaves the category with the current default, where the device knows exactly what it is doing and the person in frame is expected to guess.

The most useful next step is boring engineering. Fork the repository. Put the advertiser on a development unit. Point a scanner at it from across a meeting room. Publish the failure cases. An open protocol earns legitimacy when competing hardware teams try to break it and the specification gets sharper as a result.

TeQmeQ is listed as attending The Things Conference 2026 in Amsterdam on 22 and 23 September. Mooij says he plans to demonstrate NearLens and discuss the signal with people working on Bluetooth Low Energy and connected hardware. The demonstration is not listed as a conference session. Its value is more practical. The proposal will be in front of engineers who can challenge the radio behaviour, reuse the example or take the UUID question to the relevant standards group.

The Bluetooth SIG programme already includes a roadmap presentation and a panel on cooperation across wireless systems. PMSG's README asks the SIG for a 16-bit Recording Presence Service. That request may be premature, incomplete or exactly the sort of application-level convention Bluetooth should examine. The bad outcome would be leaving the question with marketing teams while manufacturers invent incompatible indicators.

NearLens exists because nearby hardware reveals too little. Through its partnership with PMSG, the app is now implementing the convention as a stronger input alongside presence awareness. The upcoming iOS version is intended to interpret compatible 📷, 📸 and 🎤 states and present them in language people can understand. Phones still need an accessible way to detect and explain those signals while devices and standards remain fragmented. NearLens and PMSG are working together to help bridge that gap.

Mooij says he plans to bring the proposal to Web Summit Lisbon 2026. By then, the repository should have more than approval from people who already agree with its premise. It should have criticism from camera engineers, privacy researchers and competing glasses makers. If the signal survives that testing, it could give NearLens better data and give the public a clearer view of what nearby hardware is doing.