Tales from the crypt: JavaScript & the Internet of Things

js-iot.md

Tales from the crypt: JavaScript & the Internet of Things

Let`s face the truth, "The Internet of Things" (or IoT like the all the cool cats say) isn't more than a fancy buzzword. Interestingly though, it is used by two different groups of people, one wants to "shove big data into the cloud" and the other group builds DIY software & hardware to control their coffee machine using a Tessel backed up by an Raspberry PI.

If we dive deeper into this topic, looking for a common ground both groups build upon, we see the same questions bubbling up: Is my battery powered motion detector really connected to the internet? If all these devices belong to the category "Internet of Things", why do I need a vendor specific access point to control them? Does my cloudy big data lightbulb producer know when I turn on the lights? And very important: Why doesn't this "Internet of Things" work in my browser? Do I really need 20 iPhone apps to turn stuff on and off?

On the meta level, all these questions could be answered with: "open source"! And that´s what we´re going to do, we reverse engineer one of the most used "closed source consumer electronics homeautomation protocols" (say that 5 times in a row) and build a JavaScript based open source module for it. Using that module we´re then able to control the privacy of our data (because now we truly own it), combine these former vendor locked in devices with DIY components (to build the use cases we need, not the ones the industry wants us to), control that devices from our own browser app (our goodbye to the world of "IPhone Apps of Things") and as a byproduct explain why JavaScript should be the language of choice for this "IoT" thingy (and of course, have some fun time hacking on hardware).

The breadth of topics described can easily fill a one day workshop. What exactly do you want to cover in-depth?

• Connectivity to "The Internet" ("Internet", "Web", "Network", …)
• Privacy (by way of showing what can actually be concluded from user data)
• APIs and UIs (silo vs. open, App vs Web App, …)
• How to reverse engineer closed protocols
• JavaScript vs any other language

From a language perspective, JavaScript is not exactly the best equipped tool for dealing with binary protocols (I assume you want to talk about your HomeMatic endeavor). Go, for example, has a number of nice features built into language constructs themselves. PHP (named just because its well known) has pack() and unpack() to work with binary data. JavaScript has neither the finesse of Go, nor the basic functions PHP offers. Yes, Node has Buffer, but that's Node, not JavaScript. And looking at all the bit-shifting-cutting-slicing-concatenating stuff you know all this, maybe even had a look at jDataView.

I agree, if you really go into detail, this could be expanded to fill a whole day.
The ideas is to give a rough & short overview of the current state of things;

• Is any device at home directly connected to the Internet (And with Internet I mean, can the device be accessed remotely without using bridges/routers etc). Some examples why this isn't the case (latency, power consumption, etc.)
• Regarding the privacy section. First of all, explaining what could be tracked by 3rd parties, then give at least one example which conclusions can be made beyond the data raw data (Probably going to use the Netatmo example here - How many people are in the room (CO2 concentration), What are they doing (a meeting, working silently, etc.))
• APIs and Silos, yep, big thing. With "using one app per vendor/device" or worse "one protocol per device" the true potential can't be unleashed, as the software to mix & match this data just isn't compatible.
• The reverse engineering part will be the biggest of the talk, as it simply makes sense to show people how those closed protocols look like & how I was able to determine which bit meant what. Also, it is just fun to turn things on & off with Node ;)
• JavaScript vs. any other language (in the whole damn universe):
  This is more of a summary. Why did I code that protocol adapter in JavaScript. What possibilities gives that to me (In terms of reusing the code cross plattform/cross app/cross type - Smartphone App, Serverside, Desktop App, Browser "App" -)
  It basically allows me even to decide dynamically where to evaluate the code. These exampels are aimed to show what the future could look like. Modern Browsers can deal well with binary data (Node, as you mentioned, can do too). Using Chrome & Firefox, I can establish a P2P binary socket connection & parse that data in the browser if I want to - see browser-buffer or binary.js as examples of existing tools that allow us to do exactly that.

Each of this topics has a complexity of its own, and I´m planning to give hints on further readings etc. if someone is interested to dive deeper into a specific topic. But overall, 35 to 45 minutes should be enough to give people an idea on what is really the current state of "The Internet of Things" and why nearly every vendor that claims to do "IoT" stuff makes it worse even more.

can the device be accessed remotely without using bridges/routers etc

a) is that relevant
b) is that something you really want, considering your insight into how bad hardware vendors are at writing software? I don't want my toaster sending spam mails or participating in a DDOS. I'm quite happy with a (single, hardened) bridge to shield those devices from the internet.
c) consider a not-so-secure device with a microphone able to stream whatever you're saying to an attacker. make things worse tenfold with video in play.

First of all, explaining what could be tracked by 3rd parties

what couldn't? what about more sophisticated sensors that analyize your urine for health metrics identifying that your daughter's pregnant?

The reverse engineering part will be the biggest of the talk

that likely diminishes the other topics to side-notes

I can establish a P2P binary socket connection & parse that data in the browser if I want to

true, but only relevant for control of devices. totally meaningless for their automation. The former is what we can do right now. the latter is what we actually want to achieve.

---

I'm not arguing against this talk, btw. I just wonder what you want to achieve with it.