Short answer: Every privacy claim about a home security camera, including the one I make about the thing I build, is a sentence written by the party with the least incentive to be checked. It is not falsifiable from the outside. What is falsifiable is the byte count: whether video leaves the building at all, and whether a person walking past the lens is followed by a burst of upstream traffic. Your router already counts this. Below is the exact two-phase test, how to read the result, and four things the test cannot tell you, which matter as much as the things it can. If you want a camera whose answer to this test is boring, Background Camera RemoteStream keeps the stream on your own network — but the whole point of this article is that you should not take my word for that either.
The claim is not falsifiable from the outside
Read the privacy page of any camera product long enough and you arrive at the same grammar every time. Your video is yours. It stays where you put it. We would never. I have written a version of that sentence. Every competitor has written a version of that sentence. Not one of them is evidence, and none of them can be, for a structural reason rather than a moral one: the only party able to observe whether the claim holds is the party making it.
This is worth naming precisely, because "trust us" is doing a specific piece of work here. In most markets the buyer has some independent channel. You can taste the food. You can drive the car before you sign. You can open the case and count the memory. A camera that ships video off your premises is unusual in that the thing being sold — a claim about what happens to a copy of your hallway once it is on a server you will never see — has no independent channel at all, and never will.
The rational response is not cynicism about any particular firm. It is to stop treating the claim as the object under evaluation, and start evaluating something that is actually observable.
What you can observe is bytes, not content
Here is the good news and the bad news in the same fact.
Everything a device sends leaves your network through one point, and that point counts. Your router is a router because it moves packets; most consumer models keep at least a coarse tally per connected client. That tally is not a claim by anybody. It is a side effect of the machine doing its job, and it is on hardware you own.
The bad news is the same sentence read the other way. What the counter gives you is volume, direction and timing. It does not give you content. Transport encryption is doing exactly what it should, and one consequence is that it protects the upload from you as thoroughly as it protects it from anybody else on the path. You will be able to see that some number of megabytes went somewhere. You will not be able to see what was in them, and if you could, that would be a different and much worse problem.
So the question has to be shaped to fit the instrument. Not what is it sending — you cannot know. Instead: does the amount of data leaving this device track what is happening in front of the lens? That question the counter answers cleanly, and it is very nearly the question you wanted.
Why not just read the phone's own data-usage screen?
You can, and it is a reasonable sixty-second first pass — I have written up that version of the check before, using Android's background-versus-foreground data figures.
But it has a weakness the router test does not. The on-device counter is kept by the same operating system the app is running on, reported through a screen the app's own vendor has an interest in, and it is scoped to the one device. The router counter sits one hop upstream on hardware bought from a different company that has never heard of your camera. Nothing running on the phone can influence it. When the two disagree, the upstream one is the one to believe.
The two-phase test
What you need. The router's admin page, the camera, and about an hour of not being in the room.
Step one: find the device. Log into the router — the same address and password you used when you set the Wi-Fi name. Look for a section called something like Connected Devices, Client List, Attached Devices or Traffic Statistics. You want the row for the camera. If the names on the list are unhelpful, the cheapest way to identify it is to stop the camera for two minutes and see which row's counter stops moving.
Step two: baseline. Write down the sent or upload figure for that device, and the time. Then leave the room. Give it an hour with nothing moving in front of the lens, no notifications, nobody opening the viewing app. Read the figure again.
The difference is the idle rate. This is what the device transmits for existing.
Step three: the event. Now go and walk past the lens several times over a couple of minutes. Wave at it. Do the thing the camera exists to catch. Wait five minutes, then read the figure a third time.
The difference between the second and third reading, minus roughly five minutes' worth of the idle rate, is the event cost: what a person in the room costs in outbound traffic.
Why two phases and not one. This is the part most people get wrong, and getting it wrong produces a false pass. A device that only transmits when it detects something looks angelic in an empty room. If you test an unoccupied hallway and see a flat line, all you have learned is that the hallway was empty. The event phase is the phase that discriminates.
Reading the result
Three broad outcomes, and they are easy to tell apart.
Flat idle, flat event. Nothing meaningful is leaving. Whatever the device is doing with the picture, it is doing it on your side of the router. This is the outcome a local-network setup should produce, and if it does not, that is worth knowing about the local-network setup.
Low idle, sharp burst on the event. The device holds its peace until it sees something, then sends. Your hallway, at the moments your hallway is interesting, is going somewhere else. This is not a scandal — it is how a large slice of this category is designed to work and it is often exactly what the buyer signed up for. But it is now a fact you established rather than a paragraph you were asked to accept.
High idle, higher still on the event. Continuous upstream. The room is leaving the building whether or not anything is in it.
Notice what none of that required. You did not have to form a view about anybody's honesty, or read a policy, or decide which company deserves the benefit of the doubt. You read a number three times and did two subtractions.
Four things this test cannot tell you
If I stopped at the previous section this would be advocacy rather than method. The limits are load-bearing.
It cannot see content. Covered above. Volume, direction, timing. Nothing else.
A low figure is not proof of nothing. A device that sends a small amount of metadata on a schedule — an identifier, a heartbeat, a thumbnail — produces a trickle that disappears into the noise floor of any connected gadget doing updates and time sync. This test detects video-shaped traffic. It does not detect a whisper.
It says nothing about the past. It measures what is happening now, on your network. It has no visibility into what was collected before you thought to look, what is retained, who it has been shared with, or what happens when the company is acquired.
It says nothing about who else on your own network can watch. A flat upstream reading means the video is not leaving. It does not mean the video is private, and those are different properties — the LAN threat model is its own subject.
And one practical caveat rather than a conceptual one: not every router will do this. Some report only current throughput rather than cumulative totals, and some report nothing per client at all. If yours is one of those, you are back to taking somebody's word, which is precisely the position this article is trying to get you out of. A cheap router that shows per-client totals is a reasonable purchase if this question matters to you.
Apply it to me
I make an architectural claim: the stream stays on your own network, and the picture does not need to visit anybody's server on its way to your screen.
That claim is a sentence. It has the same evidentiary weight as everybody else's sentence, which is none. The reason I would rather publish the test than the reassurance is that the test is the only thing in this article that does not require you to have an opinion about my character. Run phase one and phase two against my thing. Flat, then flat, is the result I am claiming. If you get something else, that is a fact about the software and I would like to know it.
The version of this industry I want to live in is one where "no video leaves the house" is a measurement somebody took, on their own hardware, in an hour, rather than a badge on a landing page. The instrument for that is already in your hallway cupboard, blinking.
More on running an old Android as a local camera at superfunicular.com.
Top comments (0)