Smart home privacy discussions tend to focus on the dramatic case: somebody watching a camera feed. It's the easiest risk to picture, and it isn't the one that applies to most households.
The data that actually leaves a typical smart home is far more boring than that, and considerably more revealing. It's a list of times and state changes.
Why boring data is the revealing kind
A motion sensor doesn't transmit a description of you. It transmits motion detected and a timestamp, which looks harmless in isolation.
Now collect a few weeks of it across a house.
You know when the household wakes and when it sleeps. You know which days somebody works from home. You know when the house is empty, for how long, and how predictably. You can watch a routine change: someone sleeping in the spare room, someone getting up at 3am repeatedly, a household that suddenly has an extra person in it. You know when they went on holiday and roughly when they'll be back.
None of that needed a camera, a microphone, or your name. It's derivable from door sensors, motion sensors and light switches, which are the cheapest and least alarming devices in the house.
Which is why "we only collect anonymous telemetry" is a weaker assurance than it sounds. Occupancy patterns aren't anonymous in any meaningful sense. There's one household producing them, and the pattern is the identity.
What actually gets transmitted
State and events make up the bulk of it: every on, off, open, closed and detected, each with a timestamp. This is most of the traffic and the most revealing part in aggregate.
Telemetry and diagnostics come next, meaning firmware versions, connection quality, battery levels and error reports. Genuinely useful to a manufacturer, and also a reliable presence signal, because a device that reports in is a device with power and a person nearby.
Then account and identity data: email, household name, device names, sometimes location for weather or sunset timing. "Master Bedroom Camera" tells somebody a lot before it transmits a single frame.
Voice and video is the category everyone thinks of, and the one most tightly governed by published policies. Real, but usually not the main leak.
Metadata leaks through encryption
This is the part that surprises people, and it changes how you should read a privacy promise.
Your smart home traffic is almost certainly encrypted, so nobody on the path reads the contents. But encryption hides the payload, not the fact of the transmission. An observer on the network can still see which device talked, to which server, when, and how much data it sent.
That's often enough. A burst from the doorbell at 07:14 followed by activity from indoor sensors is a person leaving for work, whether or not anyone can read a single byte of it. Traffic patterns on their own can reconstruct a household's rhythm.
So "end-to-end encrypted" is a real and worthwhile guarantee about contents. It is not a guarantee that your routine is private. The only thing that fully addresses the metadata problem is not sending the traffic at all, which is the practical argument for local processing, independent of anyone's privacy policy.
Curious whether Nexop fits your home?
Book a live demo, run by one of the founders rather than a salesperson. Or join the waitlist and hear from us the day it ships.
How to check for yourself
Read the retention section, not the intro. Every privacy policy opens by saying privacy is important. Skip to how long data is kept, whether it's shared with affiliates or partners, and what happens when you delete your account. Vagueness there is the signal.
Look for "affiliates" and "business transaction" specifically. Both are standard clauses that permit your data to move to companies you've never evaluated, including if the vendor gets acquired.
Do the disconnect test. Cut the internet, leave the local network up, and see what still works. Whatever stops was reaching outside for something. This tells you more than any document will.
Watch your own DNS. Your router or a Pi-hole will show which servers your devices contact and how often. There's nothing to decrypt, because the pattern of who-talks-to-whom is the useful part, and it's often surprising.
Check whether deletion is real. Can you delete history, and does it delete or just hide? Is there an export? When neither exists, data is usually being retained for reasons other than serving you.
Being fair about the other side
Cloud processing isn't automatically bad faith, and treating it that way leads to poor decisions.
Some genuinely valuable things need offsite data: video stored away from a camera a burglar could walk off with, cross-device features, models too large to run at home. Vendors have legitimate needs too. Diagnostics do improve products, and a company with no telemetry ships worse software.
The reasonable position isn't zero transmission, it's proportionality. Does the data leaving match the value coming back, and did anyone ask you? A thermostat sending diagnostics is proportionate. A light switch that needs a cloud account to toggle is not.
Our side of it
Nexop is built so household data stays on the local device by default: routine learning, device state, occupancy, automation history. That isn't a promise about how we'll behave with your data. It's an architecture where the question mostly doesn't arise, because a pattern that never leaves the building doesn't need a retention policy.
Two qualifications. Nexop is pre-launch, so this describes how it's designed rather than a track record. And a local-first product still has ordinary internet touchpoints: updates, optional remote access, and this website, which does use analytics. What we collect there and why is in our privacy policy, which is written to be read rather than to be defensible.
If you want to interrogate any of this properly, book a demo and ask the awkward version. Those are the questions we'd rather answer before you buy than after.