Echoes From the Shadows

Getting a picture out of it

The objective was a dashboard that could fetch and display live video from an ESP32-CAM module over a TCP connection, with audio recording through an attached microphone.

The camera itself was the straightforward half — the ESP32-CAM has extensive documentation and community support, so configuring it and experimenting with streaming settings went smoothly. At compile time you specify the network the camera will broadcast on; we used a 5G mobile hotspot. Power it up, it joins the network and starts streaming on an assigned IP.

Then the lag showed up. Extensive testing across resolutions landed on 320×240 as the point where image quality and latency balanced out. The ceiling was set by network quality and the module's 5V supply, not by the code.

Why I replaced the default dashboard

The stock ESP32 dashboard is a single live feed and not much else. I built a custom one to make it actually usable: multiple simultaneous streams, and a built-in network scanner that detects IP and MAC addresses on the local network so a camera's MAC address can be saved to a favourites list for quick access to its settings and streams.

I also implemented a basic face-recognition algorithm that detects faces and clothing from captured images — which turned out to matter more for the argument than for the demo.

The user test that went wrong, usefully

We observed participants without their awareness and used the reveal as a shock factor to start a conversation. Two questionnaires, one before and one after, were prepared to capture how opinions shifted.

Most participants could not locate the camera even though it sat in clear view. The test did not go fully to plan, but it produced the thing we actually needed: real reactions to being watched, and a divide in the responses. Some participants felt safer for the surveillance. Others felt anxious and self-conscious. That split became the project.

A separate lesson landed on day one of Society 5.0: we had assumed the danger of surveillance equipment would generate interest on its own. It did not. We rebuilt the front-end visuals and added posters overnight, and day two drew significantly more people and more feedback.

Two designs, one device

After the second sprint the narrative was still unclear to the client. The intervention that fixed it was sharpening the focus onto the ethical dilemma itself — shifting from warning about unethical behaviour to demonstrating the difference between ethical and unethical surveillance. We built both.

The Light design is built around consent: an LED indicator whenever the camera is active, an obvious way to disable the system, and a route to request deletion of personal data. The Dark design is built around invisibility — hardware that blends into its surroundings, recordings running silently in the background, and no indicator at all.

The point is that the difference between them is a handful of deliberate developer decisions. Technically it is trivial to make a red light turn on while a camera records. In the Dark version we chose not to program it. That choice is the whole argument: the same hardware, optimised purely for the observer, quietly reduces the observed to data objects.

What a Light design actually requires

The Light side is where Privacy by Design stops being a slogan. Instead of streaming all audio to a server continuously, the device analyses sound locally and only transmits when a keyword or safety risk is detected — edge computing that minimises both the data collected and the blast radius of a leak.

For transparency we went below the software layer. A software-controlled indicator light can be disabled by whoever writes the software. An LED wired physically in series with the microphone cannot: if power reaches the microphone, the LED is on. That makes covert listening technically impossible regardless of what the code says.

What no design solves is the human factor. Someone can still place a perfectly ethical device somewhere it has no business being. Design can make misuse harder; it cannot make it impossible without removing the function entirely.

What I took away

Technically: combining hardware and software into one working system, and finding out where the real constraints live — usually in power, network and physics rather than in the algorithm.

Beyond that: our central assumption changed during the project. Awareness alone is not enough; activation is. And a well-prepared, interactive presentation influences how people respond to a project at least as much as the prototype does.