3 ms·

1. Company wants to sell an iot product. 2. Through research they find user wants to interact with their smart device while outside of range of wifi/bluetooth.

1. Company wants to sell an iot product. 2. Through research they find user wants to interact with their smart device while outside of range of wifi/bluetooth. 3. Company builds device firmware and cloud infrastructure to support this goal. 4. Company wants to simplify business logic and doesn't provide local (wifi/bluetooth/zigbee) support. Online only can service both on-premise and off-premise. 5. Company needs to reduce costs and justify ongoing operational costs of supporting this cloud + device service. 6. We arrive at the current solution.

jasonjayr 3y ago
7. insecure, opaque devices that have always-on internet connections, that owners cannot upgrade/fix/defend against and require external actors to protect (ISP's blackholing bad traffic) Remember, the S in IoT is for Security. They could simplify their business logic by making sure local first is reliable, and internet access can be turned off, and supporting vendors making (user-controlled, upgradeable, etc) gateways that handle the cloud/internet/local handoff
- seanalltogether 3y ago
  I don't disagree with you, since the company I work for supports both local network access to their devices as well as cloud access for when you are outside the home. But supporting both does not simplify business logic, it increases complexity. It introduces more states and failure points that your firmware devs and app devs need to account for.
  - Nextgrid 3y ago
    A solution to that is to make the cloud-based service as dumb as possible, only operating as a NAT traversal helper and/or TURN relay, over which the local-only protocol is tunnelled.
  - jasonjayr 3y ago
    I appreciate your response, and don't want to go too far off the thread here, but as a software developer/architect myself, how can that possibly be true? The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection. This would be the same mechanism a local-first connection would use, right? What am I missing here?
    - seanalltogether 3y ago
      Aside from all the small added complexities of swapping between local http polling vs mqtt pub/sub for both apps and devices, the big complexity is managing authorization. Think about how simple the device firmware gets to be if the only access pattern is a single secured mqtt channel for processing commands. Anything coming down that pipe comes from a cloud provider that has already negotiated who can and can't send those commands. When you open up local access the device itself now needs more code to manage authorization and all the attack surfaces that come along with that.
TheJoeMan 3y ago
What's interesting is the "ongoing operational costs" should be calculated to NPV and rolled into the cost of the garage door one-time-purchase. We're talking about a $3-400 garage door opener not a $20 echo dot.
WWLink 3y ago
I'll argue the fucking garage opener shouldn't even be connected to the internet. It, like every other "smart home" device should be connected to a zigbee/z-wave/thread gateway that can be replaced when it gets old and the manufacturer can't/won't support the gateway anymore. This current model is a fucking failure.

jasonjayr 3y ago

7. insecure, opaque devices that have always-on internet connections, that owners cannot upgrade/fix/defend against and require external actors to protect (ISP's blackholing bad traffic) Remember, the S in IoT is for Security. They could simplify their business logic by making sure local first is reliable, and internet access can be turned off, and supporting vendors making (user-controlled, upgradeable, etc) gateways that handle the cloud/internet/local handoff

seanalltogether 3y ago
I don't disagree with you, since the company I work for supports both local network access to their devices as well as cloud access for when you are outside the home. But supporting both does not simplify business logic, it increases complexity. It introduces more states and failure points that your firmware devs and app devs need to account for.
- Nextgrid 3y ago
  A solution to that is to make the cloud-based service as dumb as possible, only operating as a NAT traversal helper and/or TURN relay, over which the local-only protocol is tunnelled.
- jasonjayr 3y ago
  I appreciate your response, and don't want to go too far off the thread here, but as a software developer/architect myself, how can that possibly be true? The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection. This would be the same mechanism a local-first connection would use, right? What am I missing here?
  - seanalltogether 3y ago
    Aside from all the small added complexities of swapping between local http polling vs mqtt pub/sub for both apps and devices, the big complexity is managing authorization. Think about how simple the device firmware gets to be if the only access pattern is a single secured mqtt channel for processing commands. Anything coming down that pipe comes from a cloud provider that has already negotiated who can and can't send those commands. When you open up local access the device itself now needs more code to manage authorization and all the attack surfaces that come along with that.

TheJoeMan 3y ago

What's interesting is the "ongoing operational costs" should be calculated to NPV and rolled into the cost of the garage door one-time-purchase. We're talking about a $3-400 garage door opener not a $20 echo dot.

WWLink 3y ago

I'll argue the fucking garage opener shouldn't even be connected to the internet. It, like every other "smart home" device should be connected to a zigbee/z-wave/thread gateway that can be replaced when it gets old and the manufacturer can't/won't support the gateway anymore. This current model is a fucking failure.