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)
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.