That's a real the danger of IoT devices. What happens if the company goes out of business, Or the company decides to terminate support? Cloud services should be additives not necessities.
One of the problems with these devices is they almost always come with "free" cloud management solutions, meaning you pay a one time fee for the hardware, and get access to "the cloud" for life for no additional fee
So the cloud services must be continually supported by selling new devices at an exponentially increasing rate to support both old and new customers.. In other markets this is called a pyramid scheme where new investors pay off old investors...
I will not buy a IoT product that does not some with a Self Hosted management option, preferably open source, but at minimum installable binaries to run on my own server. If they want to provide their own service for the less technical clients more power to them, but for me self hosted or no buy
Having zero knowledge of this product other than TFA, but being familiar with similar systems; It's not an unusual requirement for a consumer device that's app-driven. If you're within the same network, the service can be discovered and all's fine. But if you're on cellular, you hit walls - you don't want to open external ports for these notoriously insecure devices, and discovery outside the network is unsolved.
So it's quite normal to have the device poll a hosted service, waiting for a callback, and the cellular application reaches the same hosted service. But to do so, you need a dependable and trustworthy hosted service.
>> But if you're on cellular, you hit walls - you don't want to open external ports for these notoriously insecure devices, and discovery outside the network is unsolved.
Dynamic DNS. Learned about this the other day from a coworker who sets up his own stuff and connects remotely by phone. You don't get a choice on having a port open - there has to be a way to connect from the outside. Making both the user and the device connect to "the cloud" to get in touch with each other is not more secure, it's less secure - see pissed off company killing a garage door opener.
This doesn't work on corporate networks, or with ISPs who put their users behind a NAT (common for cellular modems). It also doesn't really fix the discovery problem - how does the client running on a different network know what dynamic DNS domain to look up? The easiest method is to use a hosted service to coordinate the two. Then you're back to the same problem.
I'm not aware of a robust solution for IoT device discovery that doesn't use a cloud based system of some sort. All the alternatives are fiddly or vulnerable to weird router/ISP configurations. Not ideal when you want your product to be seamless.
Really it sounds like a good situation for a federated service/protocol.
Let IoT developers develop against the protocol and then consumers can pick a provider to run their IoT hub.
i.e. I go to my garage app and plugin iot://firstname_lastname@iot_hub_provider.com and then that does the heavy lifting of cloud connecting the device and allowing the app to communicate with it.
With a bit of effort, you can have a service that is 1) nearly invisible to anyone not 'in the know', 2) allows incoming global connections without opening any ports, and 3) is extremely-well firewalled from any client lacking a manually-loaded decryption key.
It's not easy, even for technical users, but it can be achieved with 'stealth' Authenticated Tor Onion Services[0]. This does not open any ports, although decryption keys must be manually loaded onto client devices. Crucially, though, any client not in possession of the decryption key can't even determine which Tor introduction point relays need to be contacted in order to set up a rendez-vous with the Onion Service, let alone know what to put in their INTRODUCE2 cells to actually authenticate themselves to the Onion Service.
I make considerable use of this scheme for all sorts of applications and it works very well around the globe, though sometimes slowly and with high latency. The only real catch is that serious censorship evasion (China, Kazakhstan, Gestapo Corporate Firewall) requires using bridges with timing obfuscation, which adds complexity and maintenance burden.
I think there's considerable potential for truly privacy- and security-conscious IoT products using this scheme. All you need is to display a QR code the user can scan on their client device in order to load the service hostname and key. Users run open source server software on their home PC with a bundled Tor. Bonus: Tor use is de-stigmatized and normalized, and Tor traffic increases, improving all users' privacy.
I think the security concern is that IoT devices have such poor security, being behind a firewall is the only thing that stops an attacker compromising them.
Expose the shitty insecure software to the internet directly, the theory goes, and successful attacks are inevitable.
But the issue goes somewhat further. Why does a garage door opener needs to be app dependant in the first place? I don't mean to come out as a luddite and can totally see a place for app driven objects in an IoT network, specifically in the scope of home automation - and control.
But for a garage door opener? Why exactly does it need to be controlled by an app? Do you ever need to control your garage door, while, for example at work? Isn't that just adding an additional layer of complexity, potential problems and a vengeful company between you and your garage door?
Those are nice examples of remote access, but none of them require a 3rd party. The problem seems to be all these web developers throwing the same solution at different problems where it doesn't really fit. Put the server in the product - problem solved.
But then I need to be able to open a connection from my phone to the device. With NATs, Dynamic IPs, ISP configured firewalls/routers and so on, this is decidedly non-trivial. Sure, you and I are smart enough to hack something together that will probably work, but end users aren't.
>> But then I need to be able to open a connection from my phone to the device. With NATs, Dynamic IPs, ISP configured firewalls/routers and so on, this is decidedly non-trivial.
There's always a "but". ISPs need more regulation. They need to be carriers of bits, and they should be forced to hand out fixed IP addresses (IPV6 makes this trivial) or even blocks /8 to homes. In the meantime there is dynamic DNS. It seems like a better idea to fix the problems standing in the way than to run every IoT device through remote servers. If you do that, you're making a choice and it's not in the customers best interest.
I for one will never participate in IoT that works the way these things do today. My furnace needs to fucking work all the time. Having a fancy NEST fail without a network connection is not an option. A simple mercury switch is more reliable and doesn't collect information about me.
...and make that server public-facing. One problem solved, a million security issues gained.
Granted, I put words in your mouth there.
But if you put such an attack surface in your device, you need to be really sure to secure it well. Especially for the case when your company goes out of business, but your customers' devices stay up.
That doesn't work for many home networks, where you can't make incoming connections, and there might not even be a fixed IP address -- at the very least you need some kind of simple server to pass messages between the user's phone and door.
The potential cost would still outweigh the use I would get out from it. But that's strictly me speaking. Other people may totally see it the other way 'round.
I guess that depends on your wifi. I have a heavy concrete construction, so with my car in the driveway I still wouldn't get wifi - let alone on the street, if I want it to open in time to pull straight in.
(for the actual value of this, I guess you'd have to ask the people who bought it. But replacing your 'clicker' with your phone, does appear to be the entire goal of the product - and "not in wifi range" could mean 100 meters away just as easily as 100 miles away)
Because "you" want to sell something to the average Joe or grandma, who wants to just plug it to the power and to the garage, and be done.
There are many cases where the cell phone won't be in the same WiFi of the appliance and on those cases you can:
1 - use some intermediate service: cell phone app <--> cloud <--> appliance
2 - Cell phone app <--> VPN to your WiFi network <--> appliance
3 - Cell phone app <--> router/modem with open ports or redirect ports ou DMZ <--> appliance.
The solution "1" is under your (seller) control, so that it's easy to provide.
Solutions 2 and 3 (and perhaps some others) need intervention from the customer, in some complicated settings. Use it and you'll surely limit your market.
The first (second?) company that creates a protocol fro their modem/router that allows a simple configuration of IoT devices to your cell will make money. You know, like WPS was created to make it easy to connect new devices to your WiFi.
You need 3rd party cloud access so the stuff in your garage can be more easily stolen of course. Just like I need my twitter followers to know when my toast is done so my toaster needs a wifi connection.
Why an exponentially increasing rate? A device like this doesn't use much storage, any logs it keeps can be rotated out after a certain duration, and the cost of storage goes down over time, not up. So storing the same amount of data 5 years from now will be less expensive, not more expensive, than today.
In addition, there are things called annuities, where the purchase price today can have enough set aside to be self-sustaining. Not saying they've done that in this case, but it's not outside the realm of possibility.
>One of the problems with these devices is they almost always come with "free" butt management solutions, meaning you pay a one time fee for the hardware, and get access to "my butt" for life for no additional fee
There's also data leakage, even within the context of "working as expected."
Recently, a clerk with the local/county municipality showed be a circa 4 am toilet flush and hand washing at my place-- based upon the single spike and amount of water used. Me slightly creeped out. The new remote-read water meters break down usage to at least the hour level -- that's what the interface she was in provided.
I can't go to the can without someone "watching". Do I start "obscuring" or "polluting" my toiletries with random flushes and runs out to the backyard bushes?
Maybe I need to roboticize this with a Raspberry Pi (overkill?) or Arduino. (But what random number generator/source do I use?)
If I had money to burn, I could install a cistern that I would draw into only periodically in large bursts.
My water meter is, via a local 433 MHz uplink, on "the Internet of Things". My friend's dog now has more privacy with regard to his bowel movements.
The flip side of this is when you're on vacation and your small-town municipal office calls you and asks if you're filling a pool, as their system has detected and flagged a constant usage over a XX hour period. In my case it was the toilet I flushed right before we left for vacation. It had been running since we left. Their call meant that I could call a family member to go over to our house and find the source of the issue, saving us hundreds of dollars in water usage. It also caused me to start digging into the communications protocol for our electric and water meters [1]. Unfortunately a recent software upgrade has enabled encryption by default on the electric meter transmissions, so I'm only able to decode water meter now, and I'm not sure how long that will last.
Edit: Here's the screenshot of usage data they sent me when I inquired [2]. The dropoff on 7/25 is when our family member shut off water to the running toilet.
I asked about recent increases in my billed amounts and whether my account might be connected to the wrong meter -- something I've read is happening as these systems are deployed.
The clerks have a system at the counter that is already signed in at some degree of administrator level. They can pull up any record they wish, on the spot. There appears to be no concern about logging or auditing of access.
The clerk just took my account number from the bill I brought with me and pulled up my usage for the last couple of days. Swung the screen around and asked whether it looked familiar (it did).
I have access to the same system -- supposedly only for my own account, after I go through an initial sign-up/on process. I wonder how secure that external access to accounts is, but I can't speak to this at this point.
My understanding from reading is also that a lot of these systems transmit unencrypted on the 433 MHz band as they communicate up to local aggregators. I didn't bring that up with the clerk.
By the way, I was given no choice to opt-out of this deployment.
Many electric "smart" meters will expose your electrical usage in just this manner too. With electricity, at least, it's economically feasible to get a "cistern" (Tesla Powerwall, etc).
That does not work. A Powerwall or other battery will just increase the base load over the time it's charging (or decrease the load when it empties), but you will still have noticeable load spikes by which you can identify the device.
Actually, it's even possible to identify certain devices by eye if you have a sufficiently detailed log (I could, for example, distinguish a coffee machine, a dishwasher and a fridge, as well as lights with different wattages, at a resolution of 1-2 measurements/s). Their patterns are quite distinguishable.
Oh, I definitely agree. The cistern analogy with water would function the same way-- refilling from the public water supply as it was drawn upon. I assumed one would disconnect from the public utility input to obscure usage patterns, "refilling" in bulk at a later time. (I did think the Powerwall was aimed at load-shifting, though, too.)
The point is more that this "company" is most probably run and operated by a single person. Hence he is being upset with not being able to answer support questions at night and being forced to deal with every customer professionally, while being busy with a bunch of other things. But this is probably also calculated into the price of the product, and the fact that its just a garage door device.
If it were some medical device, you would expect that its supported by a large company, the device has gone trough mandatory certifications, etc. But that would also show in the price of the product, or the volume at which those products are produced and sold.
The mistake is expecting that every gadget maker provides service such a multi-billion dollars corporation can. It simply can't, its a single-person company and that person has its limits. So you either have to deal with some roughness, or you dismiss everything not backed by a large enough company. Not that big companies can't be assholes, they just know how to be assholes less personally.
> What happens if the company goes out of business, Or the company decides to terminate support?
I agree with you completely. Devices that rely on external servers are not OK. My house's automation uses IoT devices that host their own servers, and/or communicate with those locally that do. I had to build them myself since no company I could find offered anything like this. I'm not a snowflake either, other engineers have done the same.
Currently, IMO, the only reasonable solution to home automation is to do everything yourself, from absolute scratch. Commercial solutions are a combination of insidious spyware and stuff that will become useless when the company becomes acquired, dies, or gets mad at you and shuts down a server.
Servers are necessary because many users have a dynamic IP address.
If your product doesn't need to offer remote control, this isn't a problem. But for many products remote control is a significant USP.
I've built my own IoT systems, and this is one of the first problems that has to be solved.
In an IPv4 world, with domestic networks connected through NAT and a dynamic IP, external servers are going to remain a thing, because the problem cannot be solved without an external server.
If IPv6 ever really takes off every device will have its own address, and then all we'll have to worry about is building bullet proof top tier security into an SoC running some version of Linux that was last patched a few years ago.
Between UPnP, ICE [0], and TURN, haven't we figured this out? I'm asking for real since I've never implemented these. Undoubtedly there are some configurations where these methods fail, but I would expect they work fine on almost all consumer networks.
I understand that TURN is where you proxy the connection through a third-party server, having given up on establishing a direct connection. While that does require a third-party server, there's no reason that server necessarily has to be directly owned/operated by the company; they could set up P2P relays in their devices, and/or open-source the server software so that it could be run locally.
> In an IPv4 world, with domestic networks connected through NAT and a dynamic IP, external servers are going to remain a thing, because the problem cannot be solved without an external server.
It can be solved, but the setup UX might not be great. Wouldn't you just have an "Advanced" UI that allows you to input the public IP address of your home network? The IoT device itself could take it from there and set up the correct firewall and forwarding rules over UPnP, or you can do it yourself. It's a one-time setup. Despite it being dynamic, how often does your ISP-provided IPV4 address actually change?
> how often does your ISP-provided IPV4 address actually change?
About once a week. This also presupposes that every customer of your home automation gets an external IP address with a router they control. What if you don't? What if you only get an internal or private IP address from your building or whatever?
What would a venn diagram look like between people like your mother and people that want home automation? My mother is still firmly in the "why would I want an automatic garage door?" category.
I think something like an automatic garage door opener is a reasonable thing for someone to want; same with, for example, a smart HVAC system or potentially security cameras.
It obviously drops off sharply when you start getting into the Bill Gates territory where monitors on the walls adjust their artwork to suit the people currently occupying the room, or modifying the light levels, etc. But all the previously mentioned stuff seems like a reasonable thing to want, the same as an automated washing machine or a microwave oven became standard items.
Perhaps there is a gap in the market for an independent rendezvous service that IoT devices and their controllers can connect to each other over.
Rather than baking in a dependency on the vendor of the specific device not going out of business, not stopping support for the device you bought, and not taking a dislike to you, you could depend upon an independent service that all (or at least many) IoT devices use.
Just run a dynamic dns server and have the client update that. Then in the client software default to using your dns infrastructure but let the user override, so when you go out of business they could set up their own dyndns and use that.
Mesh overlay networks are a thing - you could very well build on them, and provide your own bootstrap hosts. The issue is that there's no incentive to learn how to manage and build that complexity into your devices and apps, vs building a simple web API.
Assuming a NAT and restrictive firewall like those included in most consumer routers, DNS gets you the public IP address, but it doesn't get you a port to the client (though one may be better advised to use STUN or ICE). You'd need to punch a hole dynamically with UPnP, require the user to punch the hole manually, or introduce a relay server using something like TURN.
Often the user just needs to find the device on their own internal network: in which case a DNS entry of myserialnumber.myIoT.com returning 192.168.1.104 is fine.
Or if you need need to initiate communication from outside the local network: establish a tunnel (in same style as e.g. ngrok).
This is what I'm doing also. Anything I want to access externally can be reached via an mqtt server running on an el-cheapo VPS.
No small irony (to me) that what simply the easiest method for me, is also one I can replace or migrate in a heartbeat. It's a shame there's no commercial offerings that do the same - there's not many vendors at all I trust to not sunset their service while I'm still using it.
(even giants that can afford it. I've been through dotmac / mobileme and now icloud on Apple, email has been the only service I've used for 10 years without being discontinued. Buying in to home improvements where I can't expect 10 years, isn't something I'm comfortable with)
Agree that you shoudn't be buying gadgets that rely on someone elses servers. If you are buying a gadget+service, it makes more sense to subscribe to the service and have the gadget on loan. At least when the service provider dies you can just sign up to another, and get a new gadget (e.g. how cable modems used to work).
The problem with the user setting up his own boxes is that I absolutely will not be bothered with updating the machines. So until there is a solution that lets me have internet connected machines at home that require no maintenance no matter how many years they run, then I'm out of luck.
I bought a TurtleBeach Audiotron years ago. It needed to hook up to the TurtleBeach server on powerup. Naturally, TurtleBeach turned that off at one point, bricking the Audiotron.
Fortunately, they did release a patch that bypassed the ping. I continued using it for years, and finally replaced it with a Grace Digital device, which also relies on connecting to Grace Digital on powerup. I know it'll eventually fail when GD moves on.
Seems like a real problem. On one hand legacy devices -- keeping them supported and updating their vulnerabilities for exploitative uses as we saw from Anna Senpai.
Not sure about the nuclear reactor non-sequitur, but with a physical device like a razor blade you can buy spares, buy 3rd party, or move on.
When an IoT maker adds 'cloud' to their product and makes it inextricably tied to the product's functionality, you have to be able to rely on their ability and willingness to maintain the cloud services for as long as you use the product.
Yes, I can get electricity from a different provider, or buy a new handle, or indeed get a new garage door opener fitted.
The problem is that a cloud-controlled garage door opener creates an unnecessary dependency on the continued existence - and good behaviour - of the vendor, unless one thinks that being able to open it from anywhere in the world is an essential feature of a garage door opener.
There's more to it? Being a cloud service means there's a simple API to open the garage door, using vanilla networking standards. The IoT is maybe more about just using IP for communications instead of special signaling devices (garage-door-opener radios etc).
Even if I just wanted to control the door from my desk at home, I'd still benefit from it being IoT-based.
It's amazing how much cheaper this (i.e. the double-edge "safety" razor) is, and it's amazing how many people don't know it. Over three years ago, I spent $11 on a pack of 100 blades. I'm not even halfway through the package.
> What happens to your handle when your razor blade supplier goes out of business?
This is an utterly stupid comparison. Razorblades cost less than 10 cents and are disposable by design. You don't spend $100 on a garage door monitor, or $1000+ on an appliance or TV expecting to use it once and throw it away.
