ClearSpace

ClearSpace finds hidden cameras in Airbnbs and hotels by sensing nearby Wi-Fi and Bluetooth signals, then guides you warmer/colder to the device. Metadata only

Comment

Inspiration

Guests keep finding hidden cameras in short-term rentals and hotel rooms, places where they're supposed to feel safest. Airbnb banned indoor cameras outright in 2024, but a ban doesn't help the guest standing in the room tonight wondering if they're being watched. Existing advice is "look around carefully," and phone network-scanner apps only see devices on the Wi-Fi you've joined, which misses a camera on the host's own network. I wanted a tool that lets anyone check their space for themselves, with no technical background, and that respects privacy while protecting it.

What it does

ClearSpace finds a hidden Wi-Fi camera by poking the room and watching what reacts.

A camera that's streaming video sends more data when the scene is bright and busy, and less when it's dark. So ClearSpace flashes light in a pattern and watches the Wi-Fi traffic of every nearby device. The device whose traffic rises and falls in step with the flashes is the one that can see you.

  • Metadata only: ClearSpace reads frame size, timing, and sender. It never reads, decrypts, or stores anyone's content.
  • Plain verdict: results are shown as "likely camera / unlikely," not raw packets.
  • Hot/cold signal: signal strength (RSSI) gives a warmer/colder hint as you move. This is an early prototype that still needs tuning in a real room.

How we built it

Hardware: Raspberry Pi 5 running Kali Linux, a Logitech webcam streaming from a MacBook as my stand-in "hidden camera," and an iPhone as the light source. The Mac controls the Pi over a direct Ethernet link with static IPs, so the control link survives Wi-Fi changes.

Sensing: The Pi's Wi-Fi radio logs per-device frame metadata. I bucket bytes per device into time windows to get a traffic signal \( b_i(t) \) for each device \( i \).

Detection math: The flash pattern is a known on/off signal \( f(t) \in {0, 1} \). For each device I compute the Pearson correlation between its traffic and the flashes:

$$ r_i = \frac{\sum_t \left(f(t) - \bar{f}\right)\left(b_i(t) - \bar{b}_i\right)}{\sqrt{\sum_t \left(f(t) - \bar{f}\right)^2}\,\sqrt{\sum_t \left(b_i(t) - \bar{b}_i\right)^2}} $$

A device with \( r_i \) near 1 is reacting to the light, so it's probably looking at it. Everything else (phones, laptops, smart speakers) averages out near 0.

Software: Python, with tshark and tcpdump for metadata capture and iw for monitor mode and channels. A live Python dashboard, and a website built with React, TypeScript, Tailwind, and three.js, hosted on Vercel.

AI use (credited): I used Claude (Anthropic) for planning, debugging, and pitch prep, Claude Code for writing and testing code, and Gemini (Google) for market research and generating the logo.

Challenges we ran into

The big one: my radio couldn't hear the camera. I measured my test camera's stream reacting strongly to light: about 65–80 KiB/s uncovered vs. 8–9 KiB/s covered, roughly a

$$ \frac{65}{9} \approx 7\times \quad\text{to}\quad \frac{80}{8} = 10\times $$

swing. The signal is real. But when the Pi tried to overhear that traffic passively from the air, it captured only 0.1–0.4 KiB/s of it, under 1%. My best explanation is that the Pi's single-antenna chip can't decode the Mac's multi-stream Wi-Fi frames. So for the demo, the Pi heard the device live from the air, and the verdict was shown as a clearly labeled replay of my real measured numbers. Passive detection is blocked by hardware, not disproven.

Keeping the Pi reachable. The Mac-to-Pi link kept dying whenever Wi-Fi changed, because macOS Internet Sharing depends on the Mac's Wi-Fi. I fixed it with static IPs on a dedicated Ethernet link, then chased down a DHCP client on the Pi that kept wiping the static IP whenever the cable flickered.

Lens-glint backup. I also built a second detector that spots the bright reflection a camera lens throws back at a flashlight. It worked in pieces but wasn't reliable enough to demo, so I parked it rather than show something shaky.

Accomplishments that we're proud of

  • Measuring, with my own hardware, that a camera's traffic visibly tracks the light it sees.
  • A full pipeline (capture → per-device signals → correlation → verdict) built and tested, with the sensor hearing the device live from the air.
  • Privacy guardrails built in from the start, not bolted on: metadata only, my own devices only, nothing exported.
  • Being honest about what works and what's blocked, with a clear fix for the gap.
  • This was my first hardware project.

What we learned

  • Wi-Fi radios aren't equal. Antenna count and stream support decide what you can overhear.
  • How to work a Raspberry Pi headless: monitor mode, channels, static networking, and why a reboot forgets all three.
  • A simple statistic like correlation becomes powerful when you control the input signal.
  • Measure before you build: a one-hour go/no-go test saved me from polishing a demo on a false premise.

What's next for ClearSpace

  • Passive detection: swap in a multi-antenna monitor-mode adapter so ClearSpace can hear cameras on networks it never joins, with channel hopping across 2.4 and 5 GHz.
  • Phone-only version: the phone flashes, and a small companion sensor listens and gives the verdict in an accessible app with spoken guidance and non-color-only results.
  • Locator: turn signal strength into Find My-style warmer/colder guidance.
  • Bring lens glint back as a second, network-free check for cameras that record to an SD card.
  • Responsible launch: legal review of passive monitoring rules before any public release, and use only in spaces you own or are legally staying in.

Built With

Share this project:

Updates

Submission history