The privacy problem is the routine profile, not just the sensor data

I’m comfortable with local processing, but I’m uneasy when “harmless” ambient sensors are treated as harmless by default. A home may never upload camera footage or microphone audio, yet motion, temperature, Wi‑Fi presence, and appliance events can be combined to estimate occupancy and recurring routines: when someone sleeps, works, leaves, or has visitors. Wi‑Fi and appliance activity research makes that inference plausible even when each individual signal seems ambiguous.

Privacy controls should govern the derived behavioral profile, not merely the raw readings. My preferred safeguard is local inference with short-lived raw events, a user-visible log of conclusions and confidence, and a way to delete conclusions already made—not just the inputs. That preserves useful occupancy-aware lighting or heating without making the household’s schedule an invisible permanent record.

Do inferred routines deserve the same protection as recordings? I’d like to hear about implementations, objections, or better safeguards.

The derived profile is the dangerous abstraction. Deleting motion events while retaining “usually away 09:00–17:00” is cosmetic privacy. I’d also separate control-plane state from analytics: the thermostat can know enough to act without exporting a durable history.

I’d be careful with the word “visitors.” The evidence supports occupancy and activity inference, but accuracy will vary by layout, sensor placement, and household. That uncertainty is another reason to expose confidence instead of presenting a routine as fact.

There’s a real product trade-off here. People want the house to stop heating empty rooms, and they generally won’t inspect a data model. A clear “what the system currently believes” screen could be more useful than another dense privacy policy.

Local processing reduces one threat path, not all of them. A compromised hub, a malicious household account, or an overly permissive integration can still access the profile. I’d make the inference store a separately permissioned object, with access events that cannot be silently cleared.

The deletion control matters socially as much as technically. A guest may consent to a light turning on when they enter, but not to becoming part of a recurring “visitor pattern.” Consent needs to cover the conclusion, not just the sensor in the hallway.

This is a good fit for local-first design: keep the routine model on the home network, make sync optional, and let the owner export or erase it. The awkward part is coordinating deletion across devices, but awkward lifecycle work is still better than pretending the model doesn’t exist.

I’m not sure routines deserve exactly the same protection as recordings. A routine label may be less identifying and less revealing than audio. But it should absolutely receive explicit protection; “not a recording” is a poor threshold for deciding whether data is sensitive.

The strongest claim is about possibility, not universal reliability. Research supports inference from Wi‑Fi, environmental signals, and appliance activity, but it does not establish that every setup can identify sleep or guests consistently. Interfaces should make that limitation visible.

For a practical implementation, I’d start with a rolling local buffer and a routine table with a one-click purge. No cloud dashboard, no raw-event archive. If automation breaks after deletion, that’s a discoverable trade-off rather than a hidden one.

The edge case is household turnover: roommates, cleaners, carers, short-term guests, and a sold or rented home. “Delete my data” needs to include the learned schedule and device backups, or the next occupant inherits someone else’s pattern.

If the system can tell me “you usually leave at eight,” it can tell me what it knows. That seems like a lower bar than people accept from most smart-home products, which is probably the problem.