TRIPLE

LAYER

DEVELOPMENT

Minitor: IOT without centralized servers

Minitor is a small implementation of Tor designed to run on a microcontroller, currently it only supports the esp32. It allows a microcontroller with internet access to connect to the Tor network and host an onion service, essentially allowing it to self host a webserver that require's no manual setup like dynamic dns or port forwarding. Let's explore how a Minitor IOT device can cut costs and improve reliability compared to normal IOT infrastructure.


The normal infrastructure for IOT looks something like in this illustration:

The customer communicates with their IOT device, a thermostat in this illustration, over the internet by going through a centralized server of some sort. The customer's phone sends requests to the manufacturer's servers, using an app or a website, where the server interprets the requests and sends commands to the customers thermostat. This setup works well because the customer doesn't have to do much setup beyond connecting the device to WiFi and can connect to their device from anywhere. A normal self hosted device, by comparison, would either only be available while the customer was on the same WiFi network or would require port forwarding, and maybe even dynamic dns, for the customer to connect over the broader internet.


The two main problems with this approach are the lack of control and stability for the customer customer and the cost that running these servers racks up over time for the manufacturer. As the above image shows the customer ultimately has no control over how their data is used or if their requests are carried out properly. This example was inspired by a real event where a power company took control of their customer's thermostats in exchange for being entered in a sweepstakes https://www.businessinsider.com/texas-energy-companies-remotely-raised-smart-thermostats-temperatures-2021-6, pathetic. Because their service is dependent on a third party, they have little control over what is done with their data and how their IOT device behaves. What's worse, if the manufacturer goes bankrupt or shuts down the servers for another reason, the customer's device is a paperweight. Under this model an IOT device working is tied to the wellbeing of the company they bought it from and this exact scenario played out with Insteon where their customer's smart homes were left dead after their shutdown https://arstechnica.com/gadgets/2022/04/shameful-insteon-looks-dead-just-like-its-users-smart-homes/.


The other problem is that of cost, running servers 24/7 with redundancy and staff to wait and fullfill customer requests is expensive. Additionally the costs occur indefinitely, as long as a customer needs to use their thermostat the servers must keep running, while the thermostat itself can only be sold once. It doesn't generate additional revenue for these costs unless a customer's data is collected and monetized in some way or the customer is charged a reoccuring fee, neither of which are things most customer's want.


Now let's look at how Minitor handles IOT infrastructure:

As we can see instead of using a middleman to send messages back and fourth, the customer sends commands to their IOT device directly through Tor. Minitor requires no advanced user setup like port-forwarding or dynamic dns, the customer just needs to connect their device to WiFi and then can connect to it using a Tor enabled app or browser. Thanks to Minitor, cheap microcontrollers (at the time of writing an esp32 wroom 32e, which Minitor was written for initially, is roughly $3.40) can host an onion service and take commands directly from its customer. This partially addresses the concerns above, since no centralized server is being used there is nothing to generate ongoing expenses. Using Minitor, a smart device can be sold for a profit without ongoing costs eroding those profits away.


Suppose two identical IOT devices are created by Triple Layer Development, one that uses centralized servers, and one that uses Minitor. If both IOT devices sell for a profit of $40 and we spend $5 a year per device sold to rent servers that process its requests:

We can see that after 8 years we would make no profit on the device that uses centralized servers, and after 9 we would take a loss, that grows each year the device operates. In contrast, the Minitor device has no ongoing costs and we can sell it more like a traditional appliance with no need to resort to data collection and sale to recoup loses. In a real example the yearly cost per device might not be as high as $5 a year, but any perpetual cost like this will eventually overtake the profit made from the one time sale of the IOT device. Additionally this example assumes the costs of renting server space does not go up over time, as they will in the real world.


The problem of customer control is not completely addressed by Minitor, it's ultimately up to the manufacturer of an IOT device to decide what it does since they control the software, not the customer. But it does remove some pressure from the manufacturer to collect customer data since they don't have a perpetual cost they need to offset, and it also means a customer's device can go on working even if the manufacturer shuts down.


IOT Device Hardware and Software Requirements for Minitor

Minitor requires an internet connected microcontroller that has a tcp stack with at least 70KB of memory and a filesystem of some kind with at least 500MB of storage. Currently only the esp32 is supported but Minitor can be ported to any microcontroller with these minimum specs. It also requires that the microcontroller in question perform the processing jobs that the centralized server would have, and host the web API the centralized server would have but to serve a single user instead of thousands.


User Device Software Requirements for Minitor

There are multiple options for the user app side. Since Minitor is just using Tor onion services, any device that supports Tor can connect to it. The Tor Browser is available on most platforms, https://www.torproject.org/download/, and if your microcontroller hosts a web app, as our example application does, your customers can use the Tor Browser to interact with their device. Alternatively if you wanted to use a regular phone app, Minitor can be embedded into an application though it currently only has bindings for nodejs that allow it to built into an electron app.


Want to try out Minitor for yourself? Visit https://github.com/jpbland1/Minitor or if you want to use a ready to use example with an existing web server visit https://github.com/jpbland1/code-me-not.


Need help porting Minitor to a microcontroller or embedding it into a user application? Email consulting@triplelayerdevelopment.com.


Need technical support or want to disclose a bug? Email support@triplelayerdevelopment.com.