[Also posted to G+ https://plus.google.com/+TomMetro/posts/JRPKoK3MFYZ ]
So what's the answer to your IoT devices being turned into paperweights when the vendor shuts down the back-end servers, as happened here? http://mashable.com/2016/04/04/revolv-smart-home-shutdown/ The answer is standards. In most cases the cloud server back-end exists strictly to solve the problem that without it, it takes a lot more networking knowledge to get apps running on ether the user's LAN, or to access your device from the WAN (Internet). Manufacturers strive to have gear that can be set up with very few steps, and be accessible from anywhere an Internet connection can be had. If you require users look up directions on how to open ports on their router, you'll be loved by security conscious geeks, and panned by consumer electronics reviewers. The best hope might be to see commodity IoT cloud services (like AWS IoT) develop, all using a common protocol. Then your IoT device might come out-of-the-box configured to hit the IoT cloud service the manufacturer partnered with, but could be reconfigured to hit a different one. Same goes for the manufacturer supplied app. By default it connects to the commodity cloud server they chose, but it is configurable to connect to others. Don't want your private data to leave your LAN? No problem. Spin up an open source implementation of the IoT back-end, and point both your IoT devices and apps there. Need WAN access? That's up to you to open a firewall port, ssh tunnel, or use a VPN. Now you have happy clueless consumers, who can stick with the defaults, and you have happy geeks that can configure things they way they want. So what might this commodity middleware be? It looks like MQTT could be it. That's Message Queue Telemetry Transport, an ISO/IEC standard. It specifies a light weight publish-subscribe messaging protocol layered on TCP/IP. https://en.wikipedia.org/wiki/MQTT There are open source implementations of this, including Mosquitto (http://mosquitto.org/) and RabbitMQ (via MQTT plugin). Others listed here: https://github.com/mqtt/mqtt.github.io/wiki/servers Amazon uses MQTT for their AWS IoT service. MQTT is not the only game in town. XMPP (Jabber IM protocol) and Constrained Application Protocol (CoAP) are some other possibilities, but MQTT might have more momentum. Vendors will still want to create web portals that implement proprietary UIs to present the data from MQTT, but most will provide mobile apps, which should continue to work after the vendor has pulled the plug on their back-end servers or gone out of business. The MQTT middleware also provides an API where a 3rd party application (or a custom application you write) can subscribe to monitor data from your IoT sensors. You'll still have to reverse engineer the data, but at least you won't have to reverse engineer the protocol. Now our job as consumers is to demand that IoT vendors use something like MQTT, adhere to the standard, and provide configuration options on both the IoT device and the apps, to make using an alternate MQTT broker possible. -Tom _______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
