We hard-coded the recording light so nobody here can turn it off

The recording indicator light on our booth station has a colour setting and a brightness setting. Below a floor, it has neither. The minimum brightness and the blink itself are held in firmware, outside the reach of the app, the installer menu and the person who owns the unit. You can make it brighter. You can make it amber instead of red. You cannot make it dark, and neither can we without shipping different firmware.

That is a smaller claim than it sounds like, and it is worth writing down precisely, because the interesting part is not the light. It is where the rule lives.

This article is general information, not legal advice. It summarises publicly available regulator guidance as of 28 August 2026, and recording law differs by country, by state, and by whether a conversation is in person or over a phone. Confirm your own situation with qualified counsel before recording anyone.

A hard-coded recording indicator is a disclosure signal whose off state does not exist as a code path. The distinction that matters is not between a bright light and a dim one. It is between a setting a policy promises to leave alone and a setting the software cannot reach. A privacy policy is a document, and documents are revised by whoever holds the pen: a new owner, a new compliance lead, a customer with leverage and a deployment that would be easier without the light. Firmware shipped without the disable path is revised by nobody in the field. The rule survives the org chart. On our unit the adjustable range sits above a hard floor. Colour and brightness move, the floor and the blink do not, and the app has no call that reaches either. That is a design rule enforced in an artifact rather than asserted in a document, and it is the only privacy promise a buyer can verify without trusting us.

What a hard-coded recording indicator actually is

A hard-coded indicator is a light whose disable path was never written. Three properties define it: a minimum brightness the software cannot go below, a blink pattern the software cannot stop, and an absence. No menu item, no API call, no support-ticket escalation turns it off. Everything above that floor stays adjustable.

The reason for the floor rather than a fixed value is mundane. Booths differ in ambient light. A trade-show hall with overhead LED arrays and a booth with a dark backdrop are different visual problems, and a single hard-set brightness would be too dim in one and distracting in the other. So the installer gets range, and the range has a bottom.

The blink is separate from the brightness on purpose. A steady light reads as a power indicator, and every object on a booth counter has one. Motion in peripheral vision does not read as power. It reads as activity, which is what is being disclosed.

None of this is a claim about legibility. We have not published a viewing angle, a legibility distance, or a measurement of how many visitors notice it, because we have not measured any of those on a built unit and inventing them would undo the point of the post. What we can say is what the firmware does and does not contain.

Limitless said this first, in hardware

Credit where it belongs. Limitless published the un-disableable indicator before we wrote a line of firmware. The Pendant FAQ states it directly: “For privacy reasons, there is no way to dim or turn off the light entirely.” That is the same design choice, and it came from a wearable company rather than a furniture one.

The Pendant is no longer sold. Limitless was acquired by Meta, stopped selling the Pendant on 5 December 2025, and ended service the same day in Brazil, China, the EU, Israel, South Korea, Turkey and the UK, with a data-download deadline of 19 December 2025. Existing customers are supported through 2026. So the product is a citation rather than a competitor, which is a reason to name it accurately and no reason to skip it.

Zoom published the software equivalent, and at a scale that makes it an industry fact rather than a niche one. Zoom’s own support documentation states that “Zoom will always notify meeting participants that a meeting is being recorded.” On Basic, Pro, Business and Free Trial accounts under 100 licences, the recording consent disclaimer “is enabled for all users on a Zoom client by default and can’t be disabled.” On larger accounts an admin can switch it off for internal participants, but “the recording consent disclaimer is required for all guest participants.” Phone participants “will always hear a voice prompt.”

Read those two together and the position stops being ours. The dominant enterprise meeting platform decided that a guest — someone who did not buy the software, did not configure it, and cannot change its settings — gets a disclosure the host cannot suppress. A booth visitor is a guest in exactly that sense. The whole argument for putting capture in the furniture is that nobody at the booth should have to manage it, and a signal the operator can switch off is a signal the operator has to manage.

What the published materials say, and what they omit

Across the category, indicator behaviour is mostly not described. This is a table of what vendors publish, not of what their devices do, and the difference is the whole point: a page that says nothing about an indicator is evidence about the page, not about the hardware.

Blinq’s line is the one worth sitting with, because it is honest and it is common. The duty is placed on the user, and the reminders go to the person doing the recording. Nothing in that flow reaches the person being recorded. That is the design question underneath all of this: who is the signal aimed at, the operator or the stranger. Nobody at the booth should have to remember to press record, and by the same logic nobody at the booth should be the only person who knows it is running.

An indicator is transparency, not a lawful basis

This is where the easy version of this post falls apart, and the collapse is more useful than the argument it replaces. A visible recording indicator does not make the processing lawful under GDPR. It is transparency, and transparency is a separate requirement from having a legal ground.

The European Data Protection Board says so directly. In its draft Guidelines 1/2024 on Article 6(1)(f), adopted 8 October 2024 as a version for public consultation, paragraph 53 reads: “the mere fulfilment of the information obligations set out in Articles 12, 13 and 14 GDPR is not sufficient in itself to consider that the data subjects can reasonably expect a given processing.” Paragraph 52 closes the other exit: “The fact that certain types of personal data are commonly processed in a given sector does not necessarily mean that the data subject can reasonably expect such processing.”

Put together, those two paragraphs remove both arguments a vendor reaches for. You cannot say the sign fixes it, and you cannot say everyone does it. The legitimate-interests balancing test still has to be passed on its own terms, and the indicator is not what passes it.

We are stating this against our own interest, which is the reason to state it. An always-on light is good practice, it is honest, and it is the thing we would want as a visitor. It is not a compliance product. The actual legal position varies enough that we wrote it out separately: what booth recording law requires changes with the jurisdiction, and the Korean position has its own statutes and its own penalties in booth recording consent under Korean law.

Ambient Trust, defined as something that costs money

Ambient Trust is the name we use for a narrow rule: a device in a shared space discloses its own operation through a property nobody present has to manage, and the disclosure is enforced in an artifact rather than in a document. The test of the term is whether it costs something. If it does not, it is a slogan.

It costs three things here. First, it removes a feature customers will ask for, and asking is reasonable — a booth designer who has spent money on lighting does not want a red blink in the frame. Second, it forecloses an install path. A customer who needs the light off for a filmed keynote cannot have it off, and that is a lost deal rather than a support conversation. Third, it makes the firmware harder to change later, because adding the code path is now a public reversal rather than a release note.

The same shape shows up elsewhere in the design. The identification limit that comes out of the optics is a boundary held by physics rather than by a setting, and both choices do the same trick: take the thing a policy would promise, and move it somewhere a policy cannot revise.

What this rule forbids us from shipping

The rule is only real if it names products we cannot build. Here are three, written as prohibitions rather than principles. No feature that hides the fact of capture or lets the indicator be switched off. No feature that requires a staffer to wear or operate anything. No data retention the people in the conversation cannot reach and delete.

The first one is this post. The second one closes off a set of obvious improvements — a wearable satellite mic would fix real coverage gaps, and we have written out exactly which ones in what booth-fixed capture cannot do. The third one rules out the storage model most convenient to us.

Each of these is a feature request we expect to receive and a specification we can be held to. That is the difference between a prohibition and a value. If you are evaluating any capture device, including ours, the version of this question that gets a real answer is the mechanical one: ask the vendor whether the indicator can be turned off, and by whom, and in which build. An answer that describes a policy is a different answer from one that describes a code path.

What we gave up

An invisible device would be easier to build and easier to sell. It would have fewer parts, no firmware argument, no lost deal over a keynote, and it would let us describe the product as unobtrusive without the qualifier we currently have to attach. We would rather have that product, on the days when the engineering is annoying.

What we would not have is a way to answer the only question a visitor at a booth actually has, which is whether the object on the counter is listening. There is no version of that answer that lives in a privacy policy the visitor will never open. It has to be a property of the object, visible from the visitor’s side of the counter, in the first second, without anyone having explained anything.

The light is not a compliance feature and it is not a differentiator. It is the smallest honest answer to a question the visitor never gets to ask out loud, and it is held in the one place nobody can quietly revise.