 OK, so this is mostly going to be me ranting. I'm going to stand here and rant for 40 minutes straight, and then you can shout at me. Does that seem like a fair deal? Yep. Excellent. So this is going to be me ranting about how people are putting together the internet of things. And if you're building an internet of things thing, or your company is, before you ship it, maybe you want to sit down and think about some of the problems and mistakes that I'm going to talk about in the next 40 minutes or so. Because a lot of people seem to be making them. The desktop increasingly belongs to niche users. It's not going to go away. It's not dead, but it's going to live on in the same way the mainframes live on, quietly, behind the scenes, backstage, developers like us and a few other people will always need it, probably. But despite the prevalent view in the Silicon Valley, the world is not full of people like us. The rest of the world then? Well, for the rest of the world, the next big thing is just that, things. Our computing is slowly diffusing out into our environment. And the current internet of things, things in the wearables that are becoming so popular, is just the tip of the iceberg. Every day objects, well, they're becoming smarter. And in 10 years time, everything you own, everything you wear, every piece of jewelry, everything you carry with you. They'll be measuring, calculating, and weighing your life. In 10 years, the world, your world, is going to be full of sensors. Now, right now, these sensors live in our cell phones, all of which should laden with accelerometers and magnetometers and gyroscopes, some of themometers and pressure and humidity sensors. But the thing to remember about today's mobile devices are cell phones. These are transition technologies, artifacts of our stage of technological progress. These two shall pass. Unlike the beige boxes that came before us and lived under our desks for 20 years, the black rectangle is going to fade into obscurity. Because what you have to remember is this is not a phone. It's just a computer that happens to be able to make phone calls. And people, most people, not people like us, but most people, never wanted computers. People don't like computers. They wanted what computers could do for them. You only have to look at someone trying to install printer drivers and windows to understand that. Anyway, most people aren't us. So it's not just our cell phones, it's our things. It's thermostats, it's weather stations, it's electricity monitors, all of which are now internet-enabled. Our lives, our things, are becoming smarter, more network-enabled. This thing's like cars. This is the Tesla Model S. It's got extensive data logging capabilities. And that's pretty well known after that infamous New York Times article. But what's slightly less well-known, unless you own one or happen to know someone that does, I don't own one, I just happen to know someone that does, is that it's got a full-rest API. This is a web server with a wheel in each corner and a really, really big UPS. Everything's going mobile. What we have to remember about Tesla and the other aspirational internet of things, things, is that this is the leading indicator. They are aspirational. It's Tesla today and the rest of the manufacturer's tomorrow. So like many things, this is just an indicator. It's not how things are going to be. It's just a hint of how things are going to be. But nonetheless, our lives, our things, are becoming smarter. And it's not just our things. We're quantifying not just the world, but ourselves. There's now a company selling wireless biosensor baby pajamas. You can put your baby on the internet. How cool is that? We're being flooded with data, not just about our environment, but our own bodies. The amount of data the average person generates in a day is order of magnitudes more than someone just 50 years ago generated in their entire lives. Well, unless they're still alive today, but you get that, that's fine. But it's not just sensors. We're increasingly not embedding, not just sensors, but actuators. We're making the world controllable, from lights to locks, from locks to thermostats, from thermostats to, well, anything that can be turned on or off, up or down, our world is now controllable. You can turn your lights on or off, and the heat in your living room up or down, from halfway around the planet. Trust me, I know I've been doing it all week, really annoying my wife. Well, it's a trend that's only going to continue. Because we're essentially the banging the rocks to get a stage for this thing. Everything is going to be networked and able. Everything will be smart. I don't think there's a way around that anymore. And that movement away from centrally controlled, heavily architected, top-down design systems of things, those huge, multi-billion dollar building control systems, to individually smart things. That's actually pretty interesting. Because we might live in a world that increasingly filled with sensors, but the sensors aren't connected to anything, except that is us. They might be informing us, allowing us to make better decisions, but it's still us that have to make the decisions. We're building an internet of broken things. Because none of these things talk to one another. It's not the network that connects our things. It's us. And it's hard enough to change the batteries in these things. I don't have to make all decisions for them as well. And sure enough, most systems today are built around the concept of a remote control. They're built around the notion of a person being a participant in the conversation with the thing. For example, tap a button and the light goes on. And that's just remote control. And don't get me wrong, there's nothing wrong with remote controls. I love remote controls. I don't like getting off of the sofa to turn my television on and off. But it's not automation, and it's not autonomy in any sense of the word, which is what's really needed. If everything is going to be smart, if everything is going to be networked and enabled, if everything is going to be a computer, do you really want to have to talk to all of them? Thinking back, how long ago was it when you had a big pile of remote controls next to your TV? One for your TV, one for your VCR, one for your laser disc player? No, and no one bought laser disc players, did they? Anyway, there was a big pile of remote controls. And that got old really, really quickly. And these days, you're probably back to one. And the internet of things equivalent to that pile of remote controls is an iPad stuffed full of apps. One app, one thing. And that's going to get old just as quickly. We've become a mechanical Turk inside our own software. Worse yet, we've become a mechanical Turk inside other people's software. The things are making us make decisions. And there's an app for this, and there's an app for that. You need an app to talk to your thermostat, and one to talk to your weather station. And it's a problem that's only going to get worse, because the people building the things seem to all have this same model. Everyone's building a thing, and then there's an app to go on top of the thing, and then there's a cloud service to go on top of the app. And I think that's wrong. Someone is wrong on the internet. So how should things work? Well, in the last few years, we've finally got to the stage where we've decided, when we're building software, that offering the user choice isn't necessarily a good thing. It isn't necessarily the best thing to do. More choice sometimes can be a bad thing. It can be a confusing thing. The more buttons and dials you add, the worse your design is. Every control you add is the design decision you are not taking. Effectively, you're offloading the design of your interface onto the user instead of doing the work yourself. And that's not great. And we've taken this problem out into the physical world. On the left, the remote control for Sony's Google TV. I don't think they make it anymore, but it was the remote control for Sony's Google TV. On the right is the remote control for the Apple TV. These things do the same job. Look at them. They do the same thing at the same basic level. These do the same thing. One on the left represents design indecision. Passing design decisions to the user. Design decisions that should have been made up front, and now the user has to make every single day of their lives. And you should have made once for them. The whole point of this sort of technology is to reduce the friction in our lives. Internet and even our light bulbs make them harder to use than a wall. And that's not a win. Nobody wins, except the people that sold you the light bulb. And this is where systems like the Phillips Hue fall down. The smarts are in the light bulb, the light bulb. Smart light bulbs are actually held up as one of the great success stories of the internet of things, which is crazy when you think about it. I think it's nuts. Light bulbs are things you turn on or off with a switch on the wall. Yes? That's how all of us use light bulbs. And how do you break the Phillips Hue system? You use the switch, you've been trained for your entire life on the wall to turn it off. And suddenly the light bulbs aren't smart anymore because there's no electricity going to the bulb. A smart light bulb replaces something we use every day, that wall switch. But it does it poorly. Really, we need to replace the switch, not the bulb, because after all, you're going into a dark room. What are you going to do? You're going to go into your pocket and get your phone out. You're going to unlock it. Or you're going to try and use the Touch ID thing, which never really works properly. And then forget your pin code. And scroll to the Phillips Hue app, or whichever light bulb app you're using, and open the app. And then scroll down the 40 light bulbs you're using in your house. And get to the right one. And then slide it up. Or you can just go like this. And then you're leaving the room, and you get your phone out, and you open the phone, and you just go like that. Which one are you going to do? Seriously? This is the wrong audience. So exactly, you replace the light switch. The thing you're doing here is trading one time friction installation for friction every time you use the light bulb. Because replacing a light switch is a big deal, and maybe not us, but most people have to get an electrician in to replace a light switch on a wall. Some countries even mandate that you have to get an electrician in to replace the light switch. For us, it's not a big deal, probably. But that's a lot of friction if you're going out to replace a light bulb. I have to replace my wall switch. I have to get someone into my house with screw drivers, and this electricity stuff is scary. So it's a lot of friction to go over to adopt a new type of product. Whereas everyone knows how to replace a light bulb, which is why smart light bulbs are selling, and smart switches aren't. Because it's a new class of product, and people are wary of that one time installation friction. But in the long term, it's not a good trade. Because we might be happy to use the app, and we might be happy to use the Raspberry Pi, or overcome a bunch of friction to use this cool thing. But most people will not. A year ago now, as says in January last year, in fact, Samsung introduced a smart washing machine. Others are forward. I think this is the whirlpool version released at the end of last year. It boasts Wi-Fi, a colored control screen, and can be started from an iPhone app. And we'll text or email you when your clothes are ready. It costs $1,700 US, as does the smart dryer that goes along with it. And if you're wondering who'd want to buy an internet enabled washing machine, you're not alone. Even whirlpools not too sure. They've been quoted as saying, we're a little bit of a hammer looking for a nail right now. And this is about a product they have built and are trying to sell. And that's because they haven't got the points. They have a thing, and they've connected it to the network, the internet. And despite the name, that is not what the internet of things is supposed to be about. This is not a smart washing machine. A smart washing machine has one button, one. It turns it on and off. And then you throw the clothes in, and all of your clothes have NFC tags. And the washing machine works, I want to do by itself. Because that's what the word smart means. And then when it was nearly done, it would tell your heating system to fire up the radiators in your house so you would have somewhere to hang your clothes so you wouldn't have to spend another $1,700 on the smart dryer. Only then would it send your push notification to tell you to come and get your clothes out of the washing machine because, hey, the robotics, that's hard. Anyway, that would be smart. What surely means the answer to my question of how should this work is that it should work like magic. Not every choice should be presented to the user. Not every option offered to them. It should be context sensitive, but not just that. It should be anticipatory, not reactive. We need to build systems again, not just individual things so the systems can learn, adapt, and get better of doing things for you, because otherwise you may as well just do them yourself. The internet of things needs to be transport neutral. It doesn't matter whether your thing is sitting on your Wi-Fi network, it's talking Bluetooth low energy. It's connected to your router via a cable. Whether it's talking Zigbee or Z-Wave, it doesn't matter. You should be able to see it and make use of it. And right now, things are islands unto themselves. You might have a house full of Philips Hue light bulbs, but you can't just unscrew one of them and replace it with a Bluetooth low energy bulb, at least not without ending up with two apps and two entirely separate systems, which is dumb because they're both just light bulbs. And fixing that problem, the fact that both things are both light bulbs and don't talk to each other, shouldn't be something you as a user should even care about. It shouldn't be something that is even vaguely on your horizon. And the fact that all of these devices are scattered across various levels of the protocol diagram is, of course, one of the real problems. And that isn't going to go neatly away. In fact, one of the things that's driving the emergence standards war is the fact that these devices are not necessarily all sitting neatly with TCP IP stacks, but they're scattered at much lower levels or much higher levels. These are devices that are hard to make to talk to one another. And that emerging standard war that's brewing, if not already outright declared, is going to be a real problem going forward. There are any number of standards agencies already, let alone standards. And of course, there are companies like Samsung, for instance, that are more than one of these big conglomerate committees. And I don't know whether it's the left hand of the company doesn't talk to the right hand of the company, or they're having a fight, or they're just trying to guarantee that they're on the winning side. No one really knows how this is going to shake out. And unlike back in the IETF days, when we could all sit down and agree about things, anyone that was ever in an IETF meeting will know that's a falsehood. I think the time for an IOT standard, one standard to rule them all, if you want to say that, put it that way, has probably been gone. Anyone proposing a single standard for the internet of things at this stage of the game is trying to sell you something. You have to be pragmatic here, because it should be obvious to anyone that isn't crazy that one single standard and one single protocol isn't going to win the home. Basically, you're never going to buy your internet of things sofa from the same people you buy your internet of things fridge from, probably because they'll make uncomfortable sofas. But despite that, these things are going to need to talk to each other. I want to be able to stand up off my sofa, walk into the kitchen, have my lights turn on, open the fridge, get my beer, close the fridge, go back to my sofa, sit down, and my film on pause. I want that to happen. And I want people that don't want that to happen for that not to happen to them. You might not get a choice. Anyway, they have to talk to one another somehow. And the internet of things has to worry a bit less about the cloud or come to that, the internet. Sure, we can connect a bunch of the things to the internet to the cloud, but this, that is to say, the internet of things is not so much about connecting things to the internet. It's about putting computing and sensing everywhere. That's going to be the real game changer. And in a great number of cases, there's no real benefit, at least to the user, of letting the internet of things things talk to the world outside the home. In Englishman's home, it's his castle. I'm Scottish, but I'll let them away with that one. And I sort of agree with it anyway. Essentially, I think the most internet of things things don't have any need to leave the local network. And the people should think hard about that. Giving a thing a network connection doesn't mean you have to give a thing an internet connection. It's not the same thing. The internet of things desperately needs to be client-neutral. Because like the early days of Twitter, I'm not entirely sure we figured out what it's for yet. I complained earlier that there was an app for each thing. And clearly, by implication, I'm seeing there should be one app. I don't think I ever claimed there should be a single app for everybody. Everyone has different needs. Everyone has different wants. So everyone should have a different client. Everyone needs something slightly different from the app that talks to their things. And people building the internet of things need to realize that you're not special. Your thing is no more special than anyone else's thing. It has to be easy to switch out from the manufacturer's provided client to one that you write yourself or someone else writes yourself and runs on iOS or Android or is hacked together with an Arduino, some wire, and some gaffer tape. People building the internet of things have to stop offering API access only at the cloud layer. And oddly enough, this might not actually be that hard because a lot of these things actually have local API that the manufacturers won't tell you about, because despite having the heavily documented REST API for their cloud service. For instance, I'm using something called an owl intuition system to monitor my electricity usage and also to control my heating in my house. Normally I do that from their website. It's actually quite a nice web app. I like it or use their iOS app, which at least according to Wireshark also talks to their web app and not the local bit of hardware. Despite this, the owl is a rather nice local system based around multicast UDP for reporting and UDP messaging for control. It's not widely advertised as a feature. You have to mail the manufacturers and they'll send you a manual. They're quite happy to send you a manual, how it works. And once I had the manual, it was pretty trivial to put together a Node.js library and an iOS library to let me control my heating or rather let some of the other things in my house control my heating, which is sort of the point, surely. I don't want to control my heating. The whole point of me buying a SMAT thermostat was so I didn't have to. It's smart. Is that why we invented computers in the first place? The internet of things desperately needs all of this because the number of smart devices we have is increasing and we'll continue to increase them by the only ones to continue to talk to them. They have to start talking to one another. This, for instance, is the NetAppmo weather station app. The NetAppmo is a rather nice home weather station and climate station. Now, amongst other things can report the amount of CO2 building up inside your house. And here it is reporting the CO2 buildup in my bedroom. It's building up overnight as myself, my wife, and my dog, which probably breeds out more CO2 than myself and my wife combined, the big dog. It's climbing overnight. It's not good. Waking up in a headache. You don't want that. It reports it weekly with a push notification. There are supposed to be for urgent things. It is urgent. Getting CO2 buildup overnight and it's reporting the telling me every week that, hey, on Wednesday, it was really bad. It's Monday now. This is not as helpful as the makers seem to think it is. Especially your access to something that can fix the problem like a nest, which can turn your HVAC fans on or off and circulate the air around your home, which solves the problem in real time, locally. And this is something I'm doing right now. I've got a piece of software that sits in my home and monitors the CO2 buildup. And when it goes above 1,000 ppm or something like that, it turns the fans on in my house and circulates the air around. And I don't wake up with a headache, which means I drink less coffee, which is good. But of course, it shouldn't have to be the net atmo. And it shouldn't have to be the nest. It can and should be anything that can detect CO2 and anything that can turn a fan on or off. There's no way you, as a user, should be concerned at that level. You shouldn't have to care about that stuff. You shouldn't have to deal with it. And of course, a remote service living in the clouds can't possibly know what's going on in your local network. Unless there's something on the network that's actually doing the job to sit there and look around and look around for things. Any sensible architecture of the internet of things has to take this into account. It should auto discover all of your things. You know the ideal world, you shouldn't have to tell the service that you own a thing. Most people, people that aren't us, don't even know what an IP address is. Do you really want them to sit there and try and figure out how their network fits together? What a Bluetooth Mac address is? It's insane. The way you configure most of these devices is nuts, because most of them are using the wrong model. There's nothing there just to look for them and fix them for the user. When you bring a new thing into your home from the store and you plug it in, as much as possible, the service that's controlling and talking to all of your things should just find it. And of course, there's any number of ways to do that if you're local. SSDP, MD, and NAS, listening for multicast traffic anyway, a bunch of ways. But all of these discovery mechanisms require a local presence. Architecturally, again, this makes sense. It's necessary. This user shouldn't have to be burdened to tell a piece of software, to having to intimately describe their home network to a piece of software. They have the stuff, the thing talking to their stuff should just know how it works. Anything else is madness. So IFTTT, if this, then that, is doing a lot of this stuff in the cloud. And I like them a lot. But my weather station, the thing measuring the CO2, is six feet down the corridor from my nest, the things controlling my fans. Do I really want my house to stop working if my internet connection goes down? My heating, my refrigerator, my stove, if my house's connection to the internet is down, do I want all of these things to stop working to stop being smart? To me, at least, that doesn't sound very smart. Especially since there's a thing that's going to be a serious privacy backlash. I really don't think the current age where privacy is no longer a social norm is going to survive the coming of the internet of things. Big Data is all very well when it's harvested quietly behind the scenes stealthily. When you're being tracked online and in the clouds, most people, again, possibly people like us, don't view the internet as the real world. But it's going to be different when your thermostat is telling the world you're not at home. It's going to be different after the first big IoT privacy breach, the first time someone's thermostat or light bulbs or whatever is compromised. Or worse yet, the first time your thermostat is hacked to blow up your boiler after the first murder by internet of things. And yes, I'm being serious here. The first murder by the internet of things isn't going to be a fleet of micro drones bearing down in you while you walk down Oxford High Street armed with cruise missiles. It's going to be a thermostat or a plug or something of the type. The rush to connect devices to the internet has lobbed to sloppy privacy controls and sloppy security. This, for instance, is a thing I'm sure we've all heard of, which is the global distribution of hosts infected with the Karnabotnet. Now, the Karnabotnet is sort of interesting for those of you who might not have heard of it. Unlike most of them, this was built to prey on embedded devices, small embedded systems rather than desktop computers. And it was for research purposes. Built by an anonymous researcher to measure the extent of the internet and what they call the great internet census of 2012, the botnet made use of trivial vulnerabilities, things like the default passwords set on routers. And as the creator concludes, a lot of devices and services we have seen during our research should never have been connected to the public internet at all. As a rule of thumb, if you believe that nobody would connect back to the internet, really nobody. There are at least 1,000 people who did. One hotel I regularly stay out when I'm in London recently had a top to bottom renovation. Now, considering the renovation cycle of most major hotel chains, this hotel targeted at the hipster silicon roundabout crowd didn't really need one, but it had one anyway. As part of the renovation, every room ended up with one of these. This is a Robert's internet radio. And don't let the retro styling fool you. It's actually a powerful internet appliance. It bears little or no resemblance to the radios we grew up with. Now, soon after this hotel was renovated in every room. Given the radio, I found myself staying there, again, and I wasn't feeling that well. In fact, I felt downright lousy. All I wanted to do was stay in my room and have a nice snuggly blankie. But I got bored, and I couldn't actually focus on what I was supposed to be doing. In fact, I can't remember what I was supposed to be doing, instead I started poking around with the toy they'd given me, the internet radio. Now, when I arrived in the room, the radio had been playing music. Clearly, obviously. At least I did vaguely hope so for the peace and quiet for the people around us. It hadn't been left on since the morning when they'd last clean the room. When I checked in, got assigned a room at Sunpoint, their booking system, talked to the network, and something between me going to the front desk and the elevator, the radio was turned on. Yeah, makes sense. Sure enough, poking around in the settings, I revealed that it was on a Wi-Fi network. Interestingly, it wasn't the Wi-Fi network that the hotel was offering to guests. It wasn't the public-facing network, but a second hidden network dedicated to pushing music around the hundreds of radios in their building. Very sensible, I thought. This wasn't a device designed for industrial deployment. And let's take a step back and just assume that, in this context, for the sake of argument, industrial also refers to hotels. This is a consumer device. Now, like a lot of Internet of Things devices, and that law is full of itself about this device again, this is an Internet of Things device. Just like the Sonos and the Apple TV are Internet of Things devices. It's much part of the Internet of Things of smart light bulbs. Anyway, like a lot of Internet devices, this thing's at an app. Now, the app assumes, requires, in fact, that your phone and the radio are on the same network. At least we can discover new radios not already registered to the cloud account. Now, the hotel weren't using the radios in the same way that the manufacturer assumed they were doing. In fact, I actually figure that somewhere, someone, somewhere, a reverse engineer at the REST API of the radio and had plugged it somewhere into the front desk reservation system. And there was a whole bunch of parallel or possibly cobalt doing something in the background. Anyway, the hotel didn't care about the consumer facing app that the radio was supposed to be paired with. But I did. Going back to the configuration menu, it proved rather really simple to flip the radio onto the customer facing Wi-Fi network. Now I could use the app, except I wasn't alone. These radios advertised themselves in the network using UPNP. And it seemed like a bunch of other people had done exactly the same thing as I did, or not. Because the default behaviors for these radios is to lock onto the first open Wi-Fi network it confines. Consumer devices have to be easy to set up. All you needed to do to drop these onto the open customer facing Wi-Fi network was factory reset them. And it looked up afterwards. And there's a whole bunch of ways these radios could accidentally be factory reset. Out of a couple of hundred radios that were probably in the hotel, I found 30-ish. Of course, to access someone else's, not mine, I needed a pin. But if the radios were factory reset, so was the pin. And the default pin on a robust internet radio is 1, 2, 3, 4. About half of you were right. Actually, I did try 0, 0, 0, 0 first. Anyway, you guessed it. That worked in every single radio except mine. Because I'd not done a factory reset. I added a new network profile to the radio. You know, put it on the guest-facing network because I wanted to switch it back at the end when I left him a nice guy. But now I had control if I wanted to 15% to 20% of the radios in the hotel. Can you imagine what I could have done to the hotel's business if I wanted to? I've wanted to wake up to hard rock music at 4 AM in the morning that you couldn't turn off. No, me either. Can you imagine the TripAdvisor reviews? That's why they're the next. Well, I unplugged the radio. This is a security vulnerability the hotel had because they'd taken a consumer-targeted device and deployed it in an industrial context. They'd done this because the radio, the internet appliance was cooler, had more features, was just more customer-friendly and probably a darn sight cheaper than the equivalent enterprise device. That's the scatter problem. I have another talk on that. I'm not giving this here, but I do have another talk on that. Right now, security is taking second place to convenience, which is fine sometimes. But you don't really want to expose your things to the internet, to the world. Putting the smarts and the data into the cloud is just to flat out the wrong choice for a lot of internet of things devices that live in the home. Of course, you should be able to talk back from the outside world to your things, which are on your desk or on your home, but that doesn't mean you need to put the smarts in the cloud. The smarts can, maybe even should, be local. Most internet of things devices I've come across don't need smarts in the cloud. What they need is an encrypted proxy, not a fully-featured web app. Effectively, what you actually need is a three-layer solution. You need a bottom layer, and this is something that has to be co-located with your things that handles discovery. But beyond that, it also handles speaking to all of the things in their own protocols, because I don't believe they'll ever only be one. Then you need a middle layer, which holds an abstract data model. One that makes light bulbs look like light bulbs, and thermostats look like thermostats. And then you need a reverse client layer on top. And it's that abstract data model. This is the thing that makes smart stuff, the stuff that sits above it possible. There are a huge number of different types of smart light bulbs, for instance. And if you're not a light bulb person, and I will be the first to admit I'm not, you might be surprised how complicated the lighting models for these things are, and how badly they implemented by most manufacturers. Actually, you're probably not surprised by the second bit. Do you really want to end up in a situation where you care about which light bulb you're buying? When you go into a store that has a whole aisle of different light bulbs, and you're going down there, and it's not just how they screw in, it's like which protocols they speak, and which manufacturer has built them. Do you really want to live in that world? That's insane. That's more insane than when we had to buy a specific type of computer. More insane. But that's companies thinking they're going to own the whole home. And I argue strenuously that this is something that's never going to happen. I just don't think people are going to stand for it. So last year in a bit, along with a few other people, I've been thinking around and attempting to think about some of these problems. And then offer up some architectural ideas sketched out in software. We called it the thing system. Basically it's a bunch of software components and network protocols that tries to fix some of these things I've been ranting about for roughly the last 40 minutes or so. Or at least suggest some ideas that I or we think are better. It's written in Node.js in as lightweight as possible. Effectively, it's a middleware for the internet of things. It's designed to allow you not just to talk to all your things, but all your things to talk to your other things, which is sort of the point. The heart of the system is a server which implements a lot of the architectural ideas I've been talking about. And it takes care of the bottom layer. That's the discovery in talking to all of the things. And while some of the things require pressed appear, like those Philips Hue blight bulbs I wasn't particularly polite about earlier, or login credentials like the Latin nest, it at least knows about them and can prompt the user's client to provide the information or push the button. But it's the middle layers, the abstract data model that makes the things look like once another. That makes them client neutral. That actually makes them useful to the user. We have a rather nice HTML5 client, but it eats our own dog food and talks the same API as any other client, which means that it doesn't matter what sensor you're using to circulate the air or to detect the CO2 buildup in the first place. Your things can now talk to one another because, due to the abstract data model, it's actually possible to build a real rules engine. And not just a rules engine, but also more complex machine learning examples on top of it. We also have some lightweight protocols for our own, which means that you can take something simple as an Arduino and a Wi-Fi shield and a sensor, and then with about 20 lines of code build, a weather station. One that because of that abstract data model presents itself in exactly the same way as the commercial net app more station does, at least to the user's clients. Yes, more protocols. For small sensors, we've used something that's essentially JSON over multicast UDP. That's just that things need to report back. And then for more complicated stuff, we have JSON over WebSockets. So it's really pretty simple stuff that you can get into and use, even if you don't use all of our top end stuff. It also provides an end-to-end encrypted proxy channel, so talking back to your things from outside your local network is possible. We're calling that things as a service, because, hey, anything as a service is sexy. Anyway, with mid-10 or maybe 11 point releases right now, there's a point release every couple of months. The current one's called Tooth Fairy, because I could. Of course, you can grab the code live from GitHub. It's all open source. It's all under MIT. The documentation's all under CC0. And to be perfectly honest, I've pretty much scratched my own itch at this point. I'm probably not going to push the system much further. I'm a decent proof-of-concepts guy, but historically bad at production systems. I know it works. I'm going to go off and do something else now. But I'd like to encourage people to take a look at it. Even if you don't think it's right, even if you don't think the way we've tackled the problems are correct, maybe you've recognized that some of the problems I've talked about are really real. And it should feedback in people how should be thinking about the Internet of Things, how people should be addressing it. Because right now, the Internet of Things is broken. And it really needs to be fixed. Thank you. I believe we've got like five minutes for questions. Good day. I guess more than the security question where we can't trust the devices in our house, I also think there's a problem, which I kind of think of as the shouting at the GPS problem, where the device is trying to help and it's trying to be intelligent. But it's not doing precisely what we want because it can't read our minds. And it sort of ends up with that Frankenstein complex thing where people want to turn off all the intelligence because it's not as intelligent as we are. Do you think this is something that we can solve? So I would entirely agree with your point that if anyone has a Nest, the Nest has intelligent features to figure out whether you're at home or not and then fix your central heating accordingly. A lot of people turn them off because the Nest is stuck in a corridor somewhere and the thing it relies on to figure out whether you're at home is a motion sensor. And if you never go down the corridor, it doesn't know whether you're at home or not. So yes, the devices have problems. And I think the solution to that problem is for them to talk to one another because what you're doing is you need to build, you need to synthesize a picture of how the real world actually looks, how it really works, from a number of different sources. I don't think one single device will ever have a real representation of the world, or a good representation of the world. Basically, it's an aging architecture problem. It's a problem for all of these things and not very smart together, but out of them, we can possibly synthesize, we can get emerging complexity, and we can possibly get a more realistic view of how the world actually works. And I think if it's going to be worked anywhere, I think that's the way it's going to work. Do you have a way of remotely updating the things? So if there's a firmware bug in one of the things, you can fix it or patch it a security vulnerability? No. Absolutely not. And that is an amazingly pertinent question. That is one of the serious, horrifying problems that is going to be with us in the next few years. And I've seen a few open source projects trying to address that. I can't remember what they are off the top of my head. But I have seen people try and address it. I think it's a horrifying, awful problem because people won't. We know that, right? Even we don't do it. When was the last time you updated your firmware? Put your hand up if you've updated your Modem firmware. You've actually, oh. Wrong crowd, wrong crowd. Put a hand up if any of your relatives have updated your Modem firmware. I didn't want to look out. Put your hand up if you updated it for your relatives. But you know where the problem is. It's not going to happen. And yes, that's a real problem that has to be addressed. And none of the manufacturers are addressing it right now, really, because they're still in the idea that they'll own the home. And they're going to have something in your home that will do that for them. There was a hand there, there, and then you've given me a hand up for a long while. I could speak to you with regards to that question you just spoke to, but I won't, because I have another one. At the keynote, the very first keynote at this conference, Evan Moglen was talking about the dire necessity for us to include the first law, Asimov's first law, in everything we do. And if it was ever needed, surely it would be needed in internet devices. And yes, it's a ridiculously large request. But if you were to think about it, your discussion with regards to CO2 consumption, your discussion with regards to human beings being slightly incompatible to AC power in the bath and catching fire, laws of physics, all those sorts of things, do you think it'd be possible to distill some of that down into a bunch of norms that could never, ever be breached so that various devices as a goal to aim towards? Because the problem you just described now with patching things, it's got a solution. We know how to do it. We just have to be persistent and forceful and do it. But trying to narrow down the first law into internet of things devices so that people don't die is a very worthy challenge, but a bit harder. So the problem I have with the first law is that if we ever come and we generate real artificial intelligences, they won't let us do anything. They'll wrap us in cotton wool and stick us in a closet. Because pretty much everything we do from walking down a set of steps is something that leads potential harm. Yeah. You just don't really engage. Yeah. I don't really see how you can do it. I don't see how you can standardize it. I think it's a worthy aim, like not killing people, very worthy aim. Maybe I said that wrong. But I think actually doing it is a hard thing. I mean, I could pick up a laptop and come up and beat you around the head with it. I won't, because my laptop's expensive. But there might be others. But anything can be used to do harm. And I think that's where possibly in the future humans will still have a place in the world, stopping people doing harm. Yeah. Earlier on in your talk, you were advocating what I considered to be sort of a truism of user interface design, which is less controls. Yeah. Yet particularly Bob Young, for example, in his talk, was talking about how open source gives us more control as user, as users of the technology. How do you see that as a trade-off? And so how does it work out in practice? I see it as a trade-off, but I also see it as a choice. I want the choice to have more control. And lots of the things I use have that control, because I want the choice in that specific realm. Other things I use, this laptop, for instance, has less choice, because I don't care anymore. I don't care that this particular laptop restricts me for doing particular things. It's not something I care about. It's a tool I use to do work. And at that point, I do not care that it won't let me do things that if I sat down and built a Linux distribution onto it, and I built it all up, and it let me do this. I'm willing to live. That's a trade-off for me. I'm willing to spend less time configuring this so that I can do something I actually want to do. And I think the same will hold true as we move the computing diffuses out into the environment. Some of it will be very interested in having the control at a very low level about these devices. And some of us, probably more of us than not, possibly not the people in this room, won't care. I think that the control has to be there, but I don't think it has to be exposed at all times. I think that is just wrong. Last question. Did you have your thought about building off existing like home automation standards? Like KNX is a big one in Europe, I believe. So the stuff that we built sits on top of all of those. That's at the bottom layer where it talks to all of the individual devices. So it talks to instant devices. It talks to a bunch of other different types of systems. And above that is the data layer that turns these systems so it doesn't look to the user like you have systems. So yes, I think that's a crucial thing for anything that tries to solve this problem, is that all of these different systems are going to have to talk to each other. No one individual system will win. Thank you. Thank you, thank you, Alastair, for telling us how to fix all the IOTs. It's simple, you're right.