5 ms·

The comment you are responding to though is asking why some of the non-physical-yet-local protocols aren't leveraged but instead you have to go all the way back

The comment you are responding to though is asking why some of the non-physical-yet-local protocols aren't leveraged but instead you have to go all the way back out to the internet and back to do something local. Why don't these products use LAN or other local, non-cloud options? That you can physically control it doesn't answer the question.

vlovich123 8y ago
For starters you don't have to worry about AP isolation & inconsistent router configurations. It also drastically simplifies the user enrolment/validation process and makes the UX of that far more consistent. It also might mean it's a lot more difficult to take over a Nest remotely if it's pinned to only communicate with Nest servers. Finally, the C&C protocols can evolve in the current model more easily as it's all server-side; the mobile & web apps just need to communicate via simple REST APIs. This drastically simplifies the maintenance of these codebases & speeds up how quickly they can address any security vulnerabilities. These choices Nest has made simplifies the SW stack, UX & provides for better security at the cost of mandating a physical fallback rather than a LAN fallback. You may see things differently but that doesn't mean these aren't valid engineering tradeoffs.
- gerbilly 8y ago
  > These choices Nest has made simplifies the SW stack, UX & provides for better security at the cost of mandating a physical fallback rather than a LAN fallback. You may see things differently but that doesn't mean these aren't valid engineering tradeoffs. Well it sounds like tradeoffs that make the engineer's life easier. Maybe they should actually tackle the harder challenge of getting their supposedly smart devices to work in a heterogenous networking environment. That would be a real innovation.
  - tjoff 8y ago
    Wouldn't really be innovation, it would just be doing the bare minimum required. The only reason these "smart" devices can exist is because the market hasn't matured and customers don't know any better.
  - vlovich123 8y ago
    Easier engineering life = cheaper maintenance = lower product cost = more $$ for consumer. Similarly, easier engineering life = less time spent on maintenance = more time spent on customer features. I'm also unclear why you are claiming the only gains are in maintenance. Security is a real end-user benefit & having devices not allow arbitrary incoming network connections is a security choice. Similarly, arbitrating everything through the web results in a simpler, more reliable, enrolment process & makes it easy to add customer features like family control more easily, securely & reliably. These are all customer-facing advantages. 2 hours out of a year is still 3, almost 4, 9s of uptime. That's probably better than your home network/ISP. I get it. You personally would prefer they traded off for supporting direct connection to your phone. However, that doesn't invalidate that there are legitimate engineering reasons someone might choose other tradeoffs.
    - dcow 8y ago
      I get your point, too, but will challenge the assumption that things need to be insecure in order to operate on an isolated LAN. It's a myth. TLS works just fine if you provision the peers with certificates. Not global TLS certs, just ones you generate for the LAN. There are other ways to do security if TLS is not what you're looking for. The problem is these options aren't easily accessible to developers so the path of least resistance is to use internet security.
      - vlovich123 8y ago
        I think you just answered your own question. The generation & management of these TLS certificates presents a giant challenge you're papering over. There's probably technical solutions to make it pretty seamless but now in addition to the cloud you have a completely alternate control path you have to maintain, secure & keep updating. Additionally, some of the solutions to managing an isolated LAN with a decent UX might entail a cloud component anyway (to manage the TLS certificates). I could totally understand why the Nest team wouldn't view it as a compelling product requirement. You need the cloud anyway because people regularly control the thermostat outside their home (e.g. to pre-warm/pre-cool when they're heading home). It's all the same infrastructure that's leveraged to run products beyond the thermostat (doorbell, security) that also have a compelling remote use-case. The isolated LAN approach could still require a cloud component for managing access. The C&C UX could become quite confusing trying to support both isolated LAN & cloud. If the cloud part fails you're no worse off than if you had a non-smart thermometer/doorbell with a good UX. Now you could obviously have remote abilities without the cloud but the UX story becomes even trickier because you need to figure out how to rendezvous & punch through a wide variety of firewall configurations. These are all things technical users could solve given the appropriate settings exposed (eg. dynamic DNS) but it's totally unnecessary for the less technically minded users Nest is targeting (or even technical-minded users who don't want to care about managing every single smart device on their network).
- kodablah 8y ago
  I may be in the minority, but I won't buy remote control devices that require access to the internet. I am not trying to control my devices outside of my house unless I take the intranet iface and expose it myself. A bit off topic, but I am hoping one day the always-on in-home server takes off for the average user so that my ability to expose my in-home server to the public internet is no longer a minority skill.
nordsieck 8y ago
> Why don't these products use LAN or other local, non-cloud options? For the equivalent effort to implement, most customer's revealed preferences are for new/better features rather than robust local intelligence. This kind of event just doesn't happen very often.
- kodablah 8y ago
  > This kind of event just doesn't happen very often. While it may not happen very often, I wonder how many customers (like me) they lose because the customers do not want their devices to even have internet access but still want local remote control (and are willing to sacrifice non-local remote control).
  - kemitche 8y ago
    The answer is going to be "very few." Perhaps enough that a competitor has room to gain some share, but the average user, even for a product like Nest? Nah.
dgacmu 8y ago
It'd be interesting to do a study of how many device outages can be fundamentally attributed to the 32-bit IP space. :-) (In case it's not clear, many of the reasons devices use cloud rendezvous have to do with NATs and firewalls and the difficulty of doing direct node-to-node communication in today's very fragmented Internet. Not all - some are security and complexity.)
soylentcola 8y ago
I'd imagine it's so you can check on them or adjust them from outside your home network. If you're leaving town for a week and forgot to switch off the air conditioning, you don't need to run back home when you're halfway to the airport. I guess ideally they would utilize a more localized protocol when you're nearby and then fall back to control->remote server->device when you're not.

vlovich123 8y ago

For starters you don't have to worry about AP isolation & inconsistent router configurations. It also drastically simplifies the user enrolment/validation process and makes the UX of that far more consistent. It also might mean it's a lot more difficult to take over a Nest remotely if it's pinned to only communicate with Nest servers. Finally, the C&C protocols can evolve in the current model more easily as it's all server-side; the mobile & web apps just need to communicate via simple REST APIs. This drastically simplifies the maintenance of these codebases & speeds up how quickly they can address any security vulnerabilities. These choices Nest has made simplifies the SW stack, UX & provides for better security at the cost of mandating a physical fallback rather than a LAN fallback. You may see things differently but that doesn't mean these aren't valid engineering tradeoffs.

gerbilly 8y ago
> These choices Nest has made simplifies the SW stack, UX & provides for better security at the cost of mandating a physical fallback rather than a LAN fallback. You may see things differently but that doesn't mean these aren't valid engineering tradeoffs. Well it sounds like tradeoffs that make the engineer's life easier. Maybe they should actually tackle the harder challenge of getting their supposedly smart devices to work in a heterogenous networking environment. That would be a real innovation.
- tjoff 8y ago
  Wouldn't really be innovation, it would just be doing the bare minimum required. The only reason these "smart" devices can exist is because the market hasn't matured and customers don't know any better.
- vlovich123 8y ago
  Easier engineering life = cheaper maintenance = lower product cost = more $$ for consumer. Similarly, easier engineering life = less time spent on maintenance = more time spent on customer features. I'm also unclear why you are claiming the only gains are in maintenance. Security is a real end-user benefit & having devices not allow arbitrary incoming network connections is a security choice. Similarly, arbitrating everything through the web results in a simpler, more reliable, enrolment process & makes it easy to add customer features like family control more easily, securely & reliably. These are all customer-facing advantages. 2 hours out of a year is still 3, almost 4, 9s of uptime. That's probably better than your home network/ISP. I get it. You personally would prefer they traded off for supporting direct connection to your phone. However, that doesn't invalidate that there are legitimate engineering reasons someone might choose other tradeoffs.
  - dcow 8y ago
    I get your point, too, but will challenge the assumption that things need to be insecure in order to operate on an isolated LAN. It's a myth. TLS works just fine if you provision the peers with certificates. Not global TLS certs, just ones you generate for the LAN. There are other ways to do security if TLS is not what you're looking for. The problem is these options aren't easily accessible to developers so the path of least resistance is to use internet security.
    - vlovich123 8y ago
      I think you just answered your own question. The generation & management of these TLS certificates presents a giant challenge you're papering over. There's probably technical solutions to make it pretty seamless but now in addition to the cloud you have a completely alternate control path you have to maintain, secure & keep updating. Additionally, some of the solutions to managing an isolated LAN with a decent UX might entail a cloud component anyway (to manage the TLS certificates). I could totally understand why the Nest team wouldn't view it as a compelling product requirement. You need the cloud anyway because people regularly control the thermostat outside their home (e.g. to pre-warm/pre-cool when they're heading home). It's all the same infrastructure that's leveraged to run products beyond the thermostat (doorbell, security) that also have a compelling remote use-case. The isolated LAN approach could still require a cloud component for managing access. The C&C UX could become quite confusing trying to support both isolated LAN & cloud. If the cloud part fails you're no worse off than if you had a non-smart thermometer/doorbell with a good UX. Now you could obviously have remote abilities without the cloud but the UX story becomes even trickier because you need to figure out how to rendezvous & punch through a wide variety of firewall configurations. These are all things technical users could solve given the appropriate settings exposed (eg. dynamic DNS) but it's totally unnecessary for the less technically minded users Nest is targeting (or even technical-minded users who don't want to care about managing every single smart device on their network).
kodablah 8y ago
I may be in the minority, but I won't buy remote control devices that require access to the internet. I am not trying to control my devices outside of my house unless I take the intranet iface and expose it myself. A bit off topic, but I am hoping one day the always-on in-home server takes off for the average user so that my ability to expose my in-home server to the public internet is no longer a minority skill.

nordsieck 8y ago

> Why don't these products use LAN or other local, non-cloud options? For the equivalent effort to implement, most customer's revealed preferences are for new/better features rather than robust local intelligence. This kind of event just doesn't happen very often.

kodablah 8y ago
> This kind of event just doesn't happen very often. While it may not happen very often, I wonder how many customers (like me) they lose because the customers do not want their devices to even have internet access but still want local remote control (and are willing to sacrifice non-local remote control).
- kemitche 8y ago
  The answer is going to be "very few." Perhaps enough that a competitor has room to gain some share, but the average user, even for a product like Nest? Nah.

dgacmu 8y ago

It'd be interesting to do a study of how many device outages can be fundamentally attributed to the 32-bit IP space. :-) (In case it's not clear, many of the reasons devices use cloud rendezvous have to do with NATs and firewalls and the difficulty of doing direct node-to-node communication in today's very fragmented Internet. Not all - some are security and complexity.)

soylentcola 8y ago

I'd imagine it's so you can check on them or adjust them from outside your home network. If you're leaving town for a week and forgot to switch off the air conditioning, you don't need to run back home when you're halfway to the airport. I guess ideally they would utilize a more localized protocol when you're nearby and then fall back to control->remote server->device when you're not.