I just read the post Privacy in the Smart Home - Why we need an Intranet of Things by Kai Kreuzer from the openHAB.org project in which he is advocating an "Intranet of Things" enabled by a local integration hub, which is a model I refer to as "local gateway" in my "Service Assisted Communication" for Connected Devices post:

All connections to and from the device are made via or at least facilitated via a gateway, unless the device is peered with a single service, in which case that service takes on the role of the gateway. Eventual peer-to-peer connections are acceptable, but only if the gateway permits them and facilitates a secure handshake. The gateway that the device peers with may live on the local network and thus govern local connections. Towards external networks, the local gateway acts as a bridge towards the devices and is itself connected by the same set of principles discussed here, meaning it's acting like a device connected to an external gateway.

OpenHAB is an integration hub and automation software for home automation that runs on top the JVM across a range of platforms and also scales down to the Raspberry Pi. A motivation for Kreuzer's post seems to be to announce the new companion service:

To cater for secure remote access, we have furthermore just started a private beta of a new service: my.openHAB will provide you the ability to connect to your openHAB over the Internet, securely, through commercial SSL certificates, without a need for making any holes in your home router and without a need for a static IP or dynamic DNS service. It does not store any data, but simply acts as a proxy that blindly forwards the communication.

The reason I'm picking up the post and comment on it here is twofold: First, the way how openHAB acts towards devices and how it federates with its "my.openHAB" service is a splendid illustration of the "Service Assisted Communicated" principles I spelled out in my write-up. Mind that I explicitly mentioned there that they're broadly implemented already and this is supporting evidence. Second, while I agree with the architectural foundation and I do find a pure "Intranet of Things" notion interesting, I don't think that's how things will play out in the long run, and I also believe there is, very unfortunately, a bit too much fear-mongering involved in trying to bring the point home. I also think there's a discussion to be made about explicit privacy tradeoffs.

The key concerns that are being raised are the following:

  • You are not the owner of your data; everything is sent to the cloud server, if you wish it or not. What happens with the data is not decided by yourself, but by the cloud service. You will only receive results of the data mining processes, be it as "smart" actions being triggered or as a colorful time series chart. I always thought of this as a no-go and wondered that other people did not mind this fact. […]
  • Even if you have full trust the cloud service company, the NSA affair should have shown you that your data is sniffed and stored in dubious places around the world. […]
  • Every device that creates a connection to a cloud service is a potential security risk. Most of these devices are embedded systems and many lack the possibility of receiving firmware updates for vulnerabilities. There are already many examples where such systems have been hacked - e.g. for heating systems or IP cameras. […]

Let's look at these.

First, whether or not you are owner of your data when using a cloud service is a matter of the service's clear and explicit privacy policy as well as of legal regulation. I am personally an advocate of regulatory frameworks governing the use of telemetry and am pointing out the importance of implementation of clear privacy policies including ways for customers to opt out of data collection and having any previously collected data provably destroyed.

But I also believe that telemetry data collected by manufacturers of devices will yield better products and will help making these products more reliable as we use them.

The privacy problem is not one of "cloud". The problem is whether you trust the manufacturer and service provider and whether you understand the policies. If the privacy policy is 5 pages of 5pt legalese, return the product to the store or don't connect it to a network, ever. Because however good your intentions about keeping things private are, if a regular consumer buys a network-enabled appliance and connects it to a local network, that device will, in very many cases, promptly phone home to the manufacturer saying at least that it has been activated and it will do that ignoring the fact whether there's a home hub on the network. That is not a cloud problem. That is a device problem. What is the device gesture to opt into the "customer experience improvement program"?

I strongly believe that very many customers, indeed the vast majority, will gladly make a privacy tradeoff if they see obvious benefits and when the service provider is honest and transparent about what is being collected, what the customer's rights are, and if the customer can trust that an opt-out leads to an effective destruction of the raw data they've contributed and any data that could further be traced to their identity. There's obviously a gray zone on aggregate data. Opting out now clearly won't change the count of "How many dishwashers were activated in the city of Mönchengladbach in January 2014". Earning trust with concerned customers means to draw the line on that gray zone clearly. What if the manufacturer cheats? Sue them along with 10,000 of your best friends.

The way we can make this scale is by supervision. I believe it would possible to have a globally standardized and auditable privacy practices seal along the lines of ISO 900x by 2018 and ways to anchor this privacy seal into the consumer hive-mind by that time. "If it doesn't carry this label, don't buy this product." The existence of that seal will also make competitors having a very close eye at their respective practices and be loud if they see the other infringing.

Once there is clarity and auditable process on privacy practices and data collection is opt-in, only then we can even get to the question of consumer choice. All of this is a prerequisite for even enabling consumers to make a choice between a local hub and a cloud service to connect your devices to. Without such a framework, manufacturers can largely do whatever they like once you give the devices network.

What benefits would customers trade some of their data privacy for? Remote control of devices around the home, energy efficiency management for their heating and cooling systems, avoiding utility grid black-/brownouts with service credit for opting in, device feature updates, general usage statistics, seamless home/mobile/work user experiences, rental property management, and more. Most scenarios that go beyond simple remote control and local stats do require data pooling in the cloud and producing insights that manufacturers, service providers, and utilities can provide higher level services on top of. Some people will find it creepy when they get a notification that the grinder in their coffee-maker is about to fail due to wear and tear and whether they want to have it replaced – I, for one, would welcome that with open arms.

Kreuzer's second point about the NSA and other government agencies is one that I'm sympathetic with, but it's also a sad one to bring up, because he's announcing a service that falls into the same category as all cloud services and he's assuming that an Intranet is generally safe from snooping. Let me preface this with the reminder that I'm speaking for myself and not at all for my employer here. Fact of the matter is that when the government of the country where the gateway service is hosted walks in with a court warrant, the good intentions come to a screeching halt or the service does. It is in the best commercial interest of all public cloud providers to keep customers data private as much as it is in the altruistic best interest of openHAB. The motivations may differ, but the goal is the same. We all want to lock the spies out and will do so until the Gewaltmonopol (state's monopoly on physical force) shows up. The state's ability to force providers to act against their will and goals also extends to the telecom operators and has done that for decades. If you bring up "NSA" as an argument for keeping things in the Intranet, you will also have to allow the conspiracy theory that operator-supplied cable and DSL modem-devices can be abused as bridge-heads into local area networks.

With this I am not defending, belittling, or justifying anything that we've learned about recently from the Snowden disclosures. I believe we've been betrayed by the governments, but fixing this is a political cleanup task and not a technical one. If the state shows up with a court order (even secretly if allowed by law) they're entitled to whatever that order says. If there's no such order, the government is clearly acting against the law – which computer systems can't read and interpret. What we can do is tighten security across the board, but it's an illusion to consider the "Intranet" a safe haven.

Which gets me to the third point about "every device that creates a connection to a cloud service is a potential security risk" which I consider to be tragically shortsighted. If we broaden the scope, though, it becomes instantly true: "every device that creates a connection is a potential security risk".

Home Intranets are the least defended and most negligently secured network spaces in existence. If you connect a BluRay player or Smart-TV or the legendary Refrigerator to your home network, that device has a very broad bouquet of options to see things and talk to things. And you will have no idea what it actually does unless you're skilled enough to use a tool like Wireshark for traffic analysis, which is only true for total network geeks.

In all actuality, it frightens me much less that the Refrigerator sends an hourly health-status package to the manufacturer than the Refrigerator having any access to anything on my network without me explicitly approving that. For the exact reasons that Kreuzer cites: Most of these devices are embedded systems and many lack the possibility of receiving firmware updates for vulnerabilities.

I want those devices off my private network rather than on it for those exact reasons. Exactly contrary to the "Intranet" mantra, I would want devices that want to piggyback on my home network to be banned from talking to anything but the outside network either by ways of a special flag in the MAC address and forced routing rules and/or by forcing them into an IPSec tunnel with the network gateway device. And I will only unblock them when I want to. Otherwise I'm perfectly fine with those device carrying their own GSM SIM or other long-range RF circuit and communicating with an external network when I have agreed to a policy to allow that and/or have explicitly enabled that functionality. I personally prefer for devices to rendezvous in public network space where they are considered as potentially hostile to each other.

I believe that the notion of by-default privileged mutual access for an arbitrary hodgepodge of devices by the sole fact that they are plugged into the same network is asking for trouble. Tricking devices into downloading and executing malicious payloads will be the favorite mass-exploitation vector for getting a local bridgehead into the home. Going through a local hub will help with that, but that will require that all devices will use it, which I consider wishful thinking at best. My second-most favorite vector and the one with the potential to inflict direct physical or monetary harm is parking a van in front of the house and going straight through poorly protected local radio traffic based on flawed standards with weak protection of which there are still many in home automation. That's something not out of reach for a skilled stalker or would-be burglar or a private investigator doing a "background check". So now you've got someone on the "Intranet".

I believe in the model of having federations of local and external gateways help with protecting and governing access to devices and laid this out in my previous post in great detail. But I also believe that we can't trust any of the devices we bring home from the store and that a notion of "Intranet" is naively dangerous and will become worse as we connect more devices. The privacy issue is one we need to tackle by (self-) regulatory means and by establishing a model that allows consumers to make informed decisions whether a product is trustworthy and we need to establish measures to audit this and also sanction violations. Privacy is not nearly as easy as cloud and local. Privacy is about trust, trustworthiness, and betrayal.

Updated: