False alarm: How to investigate your way through a surveillance freakout and try to be a better journalist

Part 1: Discovery

I had two pieces of evidence to consider: 1) A device on my wifi network was recording video 2) A smoke detector beyond my reach, battery removed, with no label telling me who its manufacturer is.

I’d just landed in Minneapolis and checked into my room. I was trying to work, but my connection was so slow that I opened a diagnostic tool on my phone called Net Analyzer. After I checked the speed, I remembered a guide I’d read on detecting hidden cameras when you travel. I have no idea how common these hidden cameras are, but just knowing about the availability heuristic is only part of the battle. I felt a strong compulsion to check.

I followed the guide and ran a port scan, indeed finding something the guide warns users about: A port running “RTSP,” or “Real Time Streaming Protocol.” I’ve actually given a talk a few times on how the internet works (and I’m trying not to feel like my internet-teaching credentials should be revoked). In those, I’ve talked a bit about protocols, but primarily about the more familiar HTTP (that is, the web per se as opposed to the internet, which encompasses much more).

As soon as I saw “RTSP,” I was anxious and posted this tweet:

Screenshot of tweet where I ask for help (since deleted, just in case people don’t see update).

I admit that part of why I reached out to folks on Twitter was because I knew the strength of my response to the initial finding was much greater than the strength of my knowledge about the subject. My anxiety was tempered somewhat by wondering whether this streaming was some kind of media service or whether it might be a standard security camera.

I hoped that an expert might point out something obvious I don’t know. But I also hoped that mediating my fears through explicitly (and publicly) reasoning would help me figure out what’s actually happening before I do anything of consequence.

Part 2: Digital investigation, and learning how to be a better programmer

For folks who want to follow along: Within the app, I’d selected LAN, then the network I was using, and “scan,” after which I selected a device and ran “Query IP with Tools,” then the “Ports” tab, returning the results in the screenshot above.

I went back to the device information and saw a “Web Interface” option:

Screenshot of a device details page within the Net Analyzer app.

Which brought me to this not-at-all creepy login screen:

Entering the device’s IP address into my browser had been recommended in my replies — thank you so much, Michael! More on this later.

At the same time that I was looking at the IP login page, another friend of mine suggested that I look for the MAC address to figure out the manufacturer:

At this point, I must admit I was quite anxious and unsure what I ought to do next. My dear friend Emily helped me over messages, too.

Here’s a great moment for tech mentors:

Screenshot of a conversation with my friend in which she explains MAC addresses to me; full text for a screen reader is at the bottom of this post.

I asked Emily’s permission to share this screenshot because I think it’s an example of how excellent she is at teaching. I also think it directly addresses a shortcoming of mine, as a programmer. But first, props for Emily:

I love how she structured the first message because it gave me a clue as to why the MAC address would help (“hardware addresses … more or less baked into”); described explicitly the pattern to look out for (“three octets”); and made explicit why it matters (MAC addresses are “assigned by the manufacturer, so it’s possible to look up”). She also made clear that this search was optional given the other information I had!

The obstacle I bring up about my operating system isn’t super relevant, but I appreciate Emily’s response. It validated a concern I brought up (“Which is nice!”), then reoriented me to the real goal (“But not relevant right now.”).

That reorientation reminded me of some shortcomings I have as a programmer (and journalist, but more on that later):

1) I forgot about a skill I already have because I didn’t abstract.

I’m so grateful to Michael for suggesting this! I’ve done exactly this countless times setting up my own router at home, but I didn’t recognize that I had seen the problem before.

2) I’m easily distracted, and let the interface of the software I was using shape how I reasoned about the problem.

As soon as I was upset, I saw the Net Analyzer app as the only means I had of learning more about the technical issue in front of me. I do the same thing with development environments, tutorials and books.

When I struggle, I abandon any of my own reasoning about what I’m trying to accomplish — say, configuring URLs in a Django app — and start frantically reacting to error messages in my development environment, or trying code samples from any combination of documentation, books, tutorials and/or Stack Overflow. I start changing my code to adhere to what other people have written because I start to feel like I can’t trust myself or the architecture of what I’ve already done.

I would have reasoned more efficiently about what I was trying to do if I’d stepped back from the tools offered in the app’s interface … literally.

Part 3: Physical investigation, and learning how to be a better journalist

I’d have saved myself some time worrying and my peers some time helping me if I’d jumped straight to looking outside. I could’ve found evidence of an external security system and compared what I saw to the Lorex web interface.

This is probably the most embarrassing feature of what happened today, because it’s both simple and a consistent obstacle to my being a better programmer and journalist: I was distracted by an irrelevant but salient feature of my environment.

Here I was responding to Peter Aldhous having helpfully researched the company whose login I’d encountered earlier (Lorex). I’d perfunctorily browsed their site and found that it was quite evidently a straightforward security camera company. But I couldn’t ignore the smoke detector! It had all the great features of a false lead: It was physically out of reach and kind of unusual and doggone it, right in front of me. And I’d made the simple mistake earlier of looking up what fake smoke detectors look like before looking up what legitimate smoke detectors look like.

If I’d taken a few beats to treat this like a story, I’d have proceeded like this: The smoke detector in my room is most likely to be a normal smoke detector, and this will be my operating hypothesis until I have sufficient evidence to reject it.

Put another way: I ought to look it up like I would look up any normal smoke detector and find a match! Once I’ve done that, look for whether any fake detectors also match, and more thoroughly review those matches for any distinguishing features.

Here’s what I was first working with:

It took me a little too long to come up with a better set of comparison images, because in my first round of research I didn’t see where the camera was supposed to be:

The photo still isn’t great because the device is far away, but this orientation — unlike the first set — allows a direct comparison of the supposed camera placement. The cutout is clearly absent from the device in my room. Before I saw the image on the right, I hadn’t known quite where to look for it.

If I’d taken a few beats to treat this logically, I’d have proceeded like this: A fake smoke detector is by its very nature going to appear at least superficially identical to a legitimate one, so looking for fakes that match is a bad idea.

But I didn’t sleep enough last night and I was tired and hot and over-caffeinated, which are some of the best ingredients for Bad Idea Stew.

I found what appears to be an exact match in a legitimate device in just a couple of minutes of searching:

The Kidde I4618, which I will probably never forget

I’m also heartened that my friend Emily resolved upon the same model in her own search:

I’m battling guilt that she did all this work for what wound up feeling like a failure to simply think on my part, but I’m trying to mitigate that with the recognition that she, like all nerds, loves the research regardless.

The solution, of course, was just to go outside. I saw security cameras over multiple outside entries, including one that I’d scrutinized when I first arrived.

This is, I’m ashamed to admit, one of my biggest shortcomings as a data analyst and especially as a data reporter: I need to learn when to step away from the screen.

I’ve agonized on my own time to scrape sites without even attempting to request the information from a human. I’ve checked out a handful of books from the library instead of calling an expert, even under the pretense of needing Just One More Source before calling a source. Sometimes this is indeed the more efficient route, but when I avoid picking up the phone or emailing someone, I can’t know.

So yeah, I could have walked the perimeter of the building immediately after seeing that login page to resolve what I was seeing, and I didn’t — for fear of seeming creepy, because I didn’t want to run into anyone, and all the mundane stuff that reporting often entails!

I’m sort of beating myself up over this, but I also don’t think I’m alone. I hope what I’ve shared here can be helpful to people either practically — how do you root out a hidden camera? — or more abstractly. Exactly this impulse to help is how I’m fighting the urge to delete all this and fret over how many people will think I’m daft. If you’re reading this and you’re also struggling to frame your blunders more positively, please know you’re not alone! It can be so easy to conflate ignorance with a fundamental, immutable ineptitude.

Also, the real story is this: I learned a lot today, thanks to excellent peers in journalism, tech and beyond. They were generous with their knowledge and their time, a pattern I’ve seen for years and which is no less astounding for its reliability. You all inspire me to be a better programmer, a better journalist, and of course a better human.

Miscellaneous notes

The guide I used is in no way responsible for my weird journey today. Its last sentence: “Just be careful sometimes a little knowledge can get you all paranoid without there actually being an issue.” I uh … didn’t read that far the first time.

A digression on the availability heuristic and news reporting: One headline that comes to mind is The Atlantic’s “Airbnb Has a Hidden-Camera Problem.” Upon reflection, this headline is clever in that it’s strictly true: Any hidden camera in an Airbnb is going to be a problem, but I imagine most people reading that headline will take it to mean hidden cameras are pervasive.

Also, if you haven’t set up your own wifi, you should try it! It’s actually really rewarding, and in my experience is less expensive than having your ISP rent the equipment to you.

I should note that someone suggested I attempt to access the account using default credentials, but yet another brilliant engineer I’m friends with advised against it.

I’m also not a legal expert, but my intuition was that it’d be dicey too. This is yet another thing I should look up!