The conventional privacy frame focuses on DATA — who collects it, who stores it, who has access. The structural lens reframes the problem as CHANNEL repurposing: the user built a channel (doorbell camera, smart speaker, location app) for one purpose, and the channel was repurposed for a different purpose by a different entity. The data is not the vulnerability. The CHANNEL is the vulnerability. The user cannot close the channel without losing the service it provides. The collision partners are military infrastructure security specialists (who know that any channel built for one purpose can be repurposed for another, and who design channels with built-in limitations on repurposability) and dual-use technology ethicists who study the structural properties that make technologies resistant to weaponization.
The doorbell camera was installed to see who’s at the door. The smart speaker was installed to play music and set timers. The fitness tracker was installed to count steps. The location-sharing app was installed so the family could find each other.
Each one was a SERVICE — a channel built by the user, for the user, carrying signal the user chose.
Each one is now a surveillance instrument. The doorbell camera feeds a police network. The smart speaker records conversations accessible by subpoena. The fitness tracker’s data is sold to insurance companies. The location-sharing app is used by an abusive partner to track their victim’s movements.
The user built the channel. Someone else repurposed it. The channel that was a service is now a weapon. And the user cannot UN-BUILD the channel without losing the service.
The privacy debate focuses on DATA — who collects it, who stores it, who has access, what consent was given. Privacy regulations (GDPR, CCPA) address data rights: the right to know what is collected, the right to delete, the right to opt out.
These regulations address data as a COMMODITY — something collected and stored that can be governed by ownership rules. The regulations are important and they are improving.
What the regulations do not address is the INFRASTRUCTURE. The smart home is a surveillance infrastructure. Not because it was designed as one — because the hardware that provides the service IS the hardware that enables the surveillance. The camera that shows you who’s at your door is the camera that shows a data broker who visits you. The microphone that hears your voice commands is the microphone that hears your conversations. The infrastructure is DUAL-USE by architecture, not by intent.
The problem is not that data is collected. The problem is that INFRASTRUCTURE built for one purpose can be repurposed for another — and the user cannot separate the two purposes because they share the same physical channel.
This is the dual-use problem from arms control, applied to personal technology. A nuclear reactor generates electricity (service). The same reactor produces plutonium (weapon material). The service and the weapon share the same infrastructure. You cannot have the electricity without also producing the plutonium. Arms control addresses this through INSPECTIONS and SAFEGUARDS — mechanisms that allow the service function while preventing the weapon function from being exploited.
Personal technology has no equivalent safeguards. The doorbell camera has no mechanism that allows the user to see who’s at the door while PREVENTING the data from being shared with a police network. The fitness tracker has no mechanism that counts the user’s steps while PREVENTING the data from being sold to an insurer. The infrastructure is unregulated dual-use.
The intervention shifts from DATA GOVERNANCE (who owns the data after collection) to INFRASTRUCTURE GOVERNANCE (how the channel is built, what functions it can serve, and what repurposing is architecturally prevented rather than legally prohibited).
The distinction matters because legal prohibitions can be changed, circumvented, or overridden by national security exceptions. ARCHITECTURAL prevention — building the infrastructure so that the repurposing is physically impossible without the user’s active participation — cannot be overridden by policy because the prevention is in the engineering, not in the law.
End-to-end encryption is an example of architectural prevention: the message cannot be read in transit, not because a law prohibits it but because the engineering prevents it. The architectural approach to the dual-use problem would apply the same principle across personal technology: build the service so that the surveillance function is architecturally impossible without the user’s real-time, active, revocable consent.
| Factor | Score | Justification |
|---|---|---|
| F1: Mortality & Irreversibility | 6 | Surveillance infrastructure enables authoritarian repurposing; domestic abuse victims are tracked through the devices they installed |
| F2: Scale | 9 | Every smart device in every home — billions of devices |
| F3: Compression Depth | 6 | The user’s private life is compressed into data accessible to actors the user did not choose |
| F4: Time Sensitivity | 8 | The infrastructure is being built now; each new device is a new dual-use channel |
| F5: Voice Deficit | 5 | Users can speak but face a binary: accept the dual-use or lose the service |
| F6: Proximity Gap | 7 | Arms control inspectors and nuclear safeguards designers are not in the consumer privacy conversation |
| F7: Temporal Displacement | 5 | The repurposing can occur at any time after installation; the infrastructure built today is repurposable tomorrow |
| F8: Normalization | 7 | “I have nothing to hide” normalizes the dual-use as irrelevant |
| F9: Hallway Dependency | 8 | The solution requires arms control methodology + privacy engineering + product design |
| F10: Knowledge Readiness | 7 | End-to-end encryption demonstrates the architectural approach; application to other infrastructure is the gap |
| F11: Entry Cost | 5 | Architectural redesign requires manufacturer cooperation or regulation |
| F12: Cascade Potential | 8 | The dual-use infrastructure model applies to every networked device, every platform, every connected system |
Hiddenness Score: 48.5 Actionability Score: 48
Nuclear safeguards designers (International Atomic Energy Agency) have decades of experience with the exact structural problem: allowing the service function of dual-use infrastructure while preventing the weapon function. The specific transferable knowledge: the safeguards METHODOLOGY — how to design inspection regimes, monitoring systems, and architectural constraints that allow electricity generation while preventing weapons production. The principles transfer: how to design consumer technology that allows the service while architecturally preventing the surveillance.
Privacy engineers who design end-to-end encryption have already implemented architectural prevention in one domain. The specific transferable knowledge: the design principle that ENGINEERING trumps LAW for prevention. A law prohibiting message interception can be repealed. An encryption protocol that makes interception mathematically impossible cannot. Extending this principle — building devices where the data CANNOT be extracted without the user’s real-time participation — is an engineering challenge, not a conceptual one.
If you are a product designer: for your next connected device, ask: can this device provide its service function using ONLY local processing, without transmitting data to a server? A doorbell camera that stores video locally and shows it only to the user’s phone on the local network provides the service (see who’s at the door) without the infrastructure (cloud storage accessible to third parties). The local-processing-first design principle is the simplest architectural safeguard.
If you are a policymaker: the regulatory model is arms control, not data protection. Data protection governs what happens AFTER collection. Infrastructure governance prevents the collection architecture from being built in a way that enables repurposing. Require that consumer devices with surveillance capability (cameras, microphones, location trackers) implement architectural safeguards analogous to nuclear safeguards — not legal restrictions on data use, but engineering constraints on data extractability.