5 ms·

You know what really bugs me about the whole affair? And granted. I didn't look into this specific product, but Why the hell do I need cloud storage at all for

You know what really bugs me about the whole affair? And granted. I didn't look into this specific product, but Why the hell do I need cloud storage at all for a fucking garage door opener?

tezza 10y ago
"Cloud" is now what they used to call "centralised control via https callbacks and polling"
soneil 10y ago
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.
- CaptainZapp 10y ago
  Thanks for the explanation, I appreciate it. 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?
  - soneil 10y ago
    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)
  - syshum 10y ago
    > Do you ever need to control your garage door, while, for example at work? Use cases include - Closing the door because you forgot to close it when you left, or a child forgot to close and you notice on your Security system - Monitoring your system remotely and letting in 3rd parties with out giving them access directly - getting alerts when your door is open and closed
    - CaptainZapp 10y ago
      Thanks. 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.
    - phkahler 10y ago
      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.
      - CJefferson 10y ago
        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.
      - dagw 10y ago
        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.
        PaulRobinson 10y ago
        IPv6. Apple made it work with "Back to my Mac". It's not hard.
- phkahler 10y ago
  >> 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.
  - michaelt 10y ago
    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.
  - leoedin 10y ago
    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.
    - PaulRobinson 10y ago
      You know, IPv6 fixes a lot of this...
    - pythonaut_16 10y ago
      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.
dickbasedregex 10y ago
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.
woliveirajr 10y ago
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.
- eli_gottlieb 10y ago
  Or you could make an old-fashioned remote-control garage opener with no app, no phone, no web browser, and fewer security holes.
  - decwakeboarder 10y ago
    The entire point of Garadget is to add control of your garage door over the internet...
    - TeMPOraL 10y ago
      Some products are better off not existing at all. A lot of IoT devices are in that category.
  - TeMPOraL 10y ago
    Or just add a 433MHz and 868MHz radios to phones. Number of usages will be countless. (Ways to have fun with that will be countless too.)
- rubidium 10y ago
  In other words, smarthomes need smart hubs for the average consumer.

You know what really bugs me about the whole affair? And granted. I didn't look into this specific product, but Why the hell do I need cloud storage at all for a fucking garage door opener?

tezza 10y ago

"Cloud" is now what they used to call "centralised control via https callbacks and polling"

soneil 10y ago

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.

CaptainZapp 10y ago
Thanks for the explanation, I appreciate it. 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?
- soneil 10y ago
  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)
- syshum 10y ago
  > Do you ever need to control your garage door, while, for example at work? Use cases include - Closing the door because you forgot to close it when you left, or a child forgot to close and you notice on your Security system - Monitoring your system remotely and letting in 3rd parties with out giving them access directly - getting alerts when your door is open and closed
  - CaptainZapp 10y ago
    Thanks. 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.
  - phkahler 10y ago
    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.
    - CJefferson 10y ago
      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.
    - dagw 10y ago
      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.
      - PaulRobinson 10y ago
        IPv6. Apple made it work with "Back to my Mac". It's not hard.
phkahler 10y ago
>> 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.
- michaelt 10y ago
  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.
- leoedin 10y ago
  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.
  - PaulRobinson 10y ago
    You know, IPv6 fixes a lot of this...
  - pythonaut_16 10y ago
    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.

dickbasedregex 10y ago

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.

woliveirajr 10y ago

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.

eli_gottlieb 10y ago
Or you could make an old-fashioned remote-control garage opener with no app, no phone, no web browser, and fewer security holes.
- decwakeboarder 10y ago
  The entire point of Garadget is to add control of your garage door over the internet...
  - TeMPOraL 10y ago
    Some products are better off not existing at all. A lot of IoT devices are in that category.
- TeMPOraL 10y ago
  Or just add a 433MHz and 868MHz radios to phones. Number of usages will be countless. (Ways to have fun with that will be countless too.)
rubidium 10y ago
In other words, smarthomes need smart hubs for the average consumer.