The $10 IoT Bulb That Smuggles Banned Books Over Wi-Fi

What happened

Richard Osgood took a generic Wi-Fi smart bulb — the kind of $10 ESP32/ESP8266-based fixture that ships from a dozen interchangeable Shenzhen factories — and reflashed its firmware to serve a library of banned books. The hardware screws into a standard E26 socket. It draws power from the lamp. It still emits light. And it broadcasts an open Wi-Fi SSID that, when joined, triggers the captive-portal handshake every modern phone performs automatically, dumping the user into a browser pointed at a local web server hosting EPUBs of titles that have been pulled from U.S. school libraries.

The build is unglamorous in the best way. Osgood didn't design custom silicon or fork a kernel. He took an off-the-shelf IoT product, replaced the vendor firmware with a small HTTP server plus a captive-portal redirect, and packed the flash with public-domain and contested texts. The bulb's existing 2.4 GHz radio, originally meant to phone home to a cloud MQTT broker, now serves as the access layer for a library. Hit the SSID, accept the captive portal, browse the catalog. No accounts, no logs, no upstream.

It landed on Hacker News at 250 points with a comment thread that split predictably between "this is brilliant" and "the threat model is half-baked." Both are right, and the project is more interesting because of the tension.

Why it matters

The headline framing — banned books, civil liberties, dead drops — is the bait. The actually interesting part is the platform choice. An ESP32 smart bulb is the perfect hostile-environment server: it's mass-produced, indistinguishable from millions of identical units, draws power passively, has no screen, no speaker, no obvious UI, and reading its contents requires no tools beyond the phone already in your pocket.

Compare this to the alternatives the censorship-resistance community has spent a decade refining. Tor bridges require a client install and a threat model that survives traffic analysis. IPFS requires a gateway and a willingness to explain what a CID is. USB dead drops — the Aram Bartholl project that defined this aesthetic in 2010 — require physical contact with a port that's increasingly rare on modern phones and that triggers OS-level permission dialogs. Mesh radios like Meshtastic require dedicated hardware that looks like dedicated hardware. Every prior generation of "covert distribution channel" has lost ground because the carrier device became more conspicuous than the payload it carried.

The bulb inverts this. The carrier is the most boring object in the room. The protocol — open Wi-Fi plus captive portal — is the exact mechanism every airport, coffee shop, and hotel uses, which means phones treat it as routine and users have a decade of muscle memory for clicking through it. The HN thread surfaced the obvious caveats: an open SSID is trivially detectable by anyone running a Wi-Fi survey, the ESP32 has limited storage so you're picking a curated subset rather than mirroring Library Genesis, and the moment one bulb gets identified the entire SKU becomes searchable. None of these are fatal. They're operational parameters, the same kind any deployable system has.

What's underappreciated is the supply-chain ambiguity. The bulb is functionally identical to its commercial cousin until someone joins the SSID. There is no way to distinguish a reflashed bulb from an unflashed one without a radio scan and a connection attempt — and even then the worst-case outcome is "this bulb hosts a weird web page," not "this bulb is contraband." That asymmetry — high cost to detect, low cost to deploy, near-zero cost to abandon — is the property that makes infrastructure resilient. The bulb is closer in spirit to samizdat than to Signal: it doesn't try to be secret, it tries to be uninteresting.

What this means for your stack

If you build for hostile or constrained environments — censorship circumvention, disaster comms, conference badges, anything where the threat model includes "someone searches the room" — the lesson here is that the ESP32 ecosystem has matured into a viable application platform, not just a sensor platform. Flash is cheap, the toolchain (ESP-IDF, PlatformIO, or even Arduino) is mature, and the captive-portal pattern lets you ship an interface to any device with a browser without writing a single line of native code.

The practical primitives are worth lifting even if you never touch a light bulb. A captive-portal-only web app is a deployment model most developers haven't considered: zero install friction, zero app-store review, zero DNS, and the user reaches your UI by joining a network the way they'd join hotel Wi-Fi. Conference organizers have used this for schedule apps. Field researchers use it for survey collection in no-signal areas. The bulb just demonstrates the upper bound of how invisible the hardware can be.

If you're on the other side — defending a network — the takeaway is that your rogue-AP detection probably indexes on SSID names and MAC OUIs that look suspicious. A bulb broadcasting `LightSetup-A4F2` from a Tuya OUI does not look suspicious. It looks like every third smart bulb on Amazon. The detection surface most enterprise Wi-Fi gear assumes is wrong for this class of device, and the fix is behavioral (any AP serving a captive portal that isn't your captive portal) rather than identity-based.

Looking ahead

The broader pattern is that consumer IoT has quietly become the cheapest general-purpose computing substrate ever shipped, and the firmware is the only thing standing between its intended use and any other use. Expect more of this — not necessarily libraries, but the same template applied to whatever the deployer needs to be deniable, ubiquitous, and powered by someone else's electricity. The bulb is a proof of concept for a deployment model, and the model generalizes faster than the regulatory or detection apparatus can.