Bringing PETs home: A Dataflow Programming Model and Runtime for Privacy-Preserving Smart Home Applications
Files
Defrère_51621900_Pihet_66151900_2026.pdf
Open access - Adobe PDF
- 2.71 MB
Details
- Supervisors
- Faculty
- Degree label
- Abstract
- Smart home services are useful but carry a hidden cost: most architectures route sensitive data, such as video feeds, audio recordings, or sensor readings, through external cloud services. This gives third parties broad access to intimate household information. Local-first platforms such as HubOS address this by keeping data processing on the hub, but they still rely on binary access control: a module either receives access to a resource, or it does not. This model cannot express policies such as "share the camera feed, but only a blurred version, and only when the doorbell rings." This thesis introduces a framework that extends HubOS with Privacy-Enhancing Technologies (PETs) as first-class components of its access control model. Rather than deciding only whether a connected device or an external application may access data, the system now also controls how the data reaches it. HubOS governs data access through TABAC, a rule-based model in which permissions are granted dynamically when a trigger fires and its conditions are met, then automatically revoked after a set period. We extend this model with an optional PET block in each rule, allowing a rule to declare not only when a permission is granted, but also how the data must be routed before it reaches its target. The raw source is made unreachable to the application as a direct consequence of rule activation, not as a separate or external configuration step. We validated the framework through three use cases: a doorbell notification service receiving only face-blurred video, a security application receiving keyword detection events instead of raw video, and an audio notification service receiving scrambled voice. Our evaluation confirms that permission rewriting correctly enforces isolation and data privacy, but also helps highlight a hardware constraint: video-intensive workloads saturate generic CPU-based hubs, and benefit from dedicated hardware. The result is a rule model in which privacy is expressed not only as an allow-or-deny decision, but as a data path: which module processes which stream, under what conditions, and what the downstream application is allowed to receive.