3 ms·

Cars are also relatively expensive. iot products seem more in the disposable and non-essential space. You can always just throw it away without much inconveni

Cars are also relatively expensive. iot products seem more in the disposable and non-essential space. You can always just throw it away without much inconvenience, so why put a lot of effort into the purchase process? Heck people don't even seem to care much about cell phones and keeping them up to date (iPhone and Nexus aside). And cell phones are far more important than lights etc. As for the last paragraph, perhaps certification instead of standards? The equivalent of UL (Underwriters Laboratory) would work, but it would need to suit the nature, prices and timelines of these products. At least consumers would then know to look for the logo. While there could be conventions for REST endpoints, I'm sceptical they would be of any use. The devices by their nature are special purpose (rather than general) so there would be a lot more domain knowledge needed to make sense of them. Additionally making them robust against general clients versus only in-house ones is a lot more work. The general ones would attempt to do nonsensical or potentially even harmful settings, and so would require more engineering spend to protect against.

kbenson 10y ago
> Heck people don't even seem to care much about cell phones and keeping them up to date (iPhone and Nexus aside). I think that's inherently a feature of them being too closely linked with the companies that provide them. Phones are the extreme case of what IoT devices could become. Once the phone OS is no longer supported by provider, keeping it is both a liability, and increasingly problematic as things stop working. Compare to old Nokia bumb brick phones. People still use those. While the close control over phones has yielded some advantages (a boost to their markets and security, for one), a phone is generally much more complex than the average IoT device, and is closer to a general purpose device. > As for the last paragraph, perhaps certification instead of standards? Certification doesn't prevent a service from going away a year later. We need a way to hook the device up to another service. If it's a standard, there's nothing to prevent an open source product that you can install on your own server, local or remote. > While there could be conventions for REST endpoints, I'm sceptical they would be of any use. The devices by their nature are special purpose (rather than general) so there would be a lot more domain knowledge needed to make sense of them. I would be interested in exploring some specific examples. What, besides aggregation of audio, video, or stats, and configuration options is there that would be hard to support? Also, I'm not saying we can't or shouldn't have specialized services where it makes sense, just that we should have open standards that companies can work to implement if they choose. > Additionally making them robust against general clients versus only in-house ones is a lot more work. They always need to be robust against general clients. Allowing companies to think they can get away with ignoring this will be very problematic in the future. Having a well defined standard and likely off-the-shelf software to help implement it will probably do quite a bit towards making things more secure, not less. See home routers and the use of openWRT, Tomato, etc. I think this would more than likely raise the lowest common denominator when it comes to security of IoT devices.
- rogerbinns 10y ago
  Note that certification could also include verifying there is a plan in place for whatever period of support is reasonable. (We could dig deeper on this.) Configuration options are hard to support. Say for example a "power level" setting is exposed (how much power is consumed to provide the device functionality). But it is also the case that more power shortens the lifespan of the device. A general client can end up setting that to 100% but won't know about the consequent lifespan issues, or too low a level results in half the functionality being switched off. By robustness I don't mean malformed inputs etc, but rather what is done with valid values. A general client will be oblivious, but an in house could present only part of the power range (the rest behind an "advanced" section). Settings will also interact with each other in device specific ways (eg power would affect maximum volume for an audio device). Pretty soon you'll need a complicated highly featured description language for the settings, interactions, cautions, effects etc. Also would you want to take support calls if external tools have been modifying the configuration, given that a single support call costs the same or more than the profit on the device? That all said, I see nothing wrong with someone publishing and maintaining a set of best practises. IMHO it is the route most likely to get traction and improvement in devices.
  - kbenson 10y ago
    I think any certification that requires a plan be in place for future support is going to be either too weak (if the company goes under, support is gone) or too burdensome (requiring some trust be in place for future support should the company go under is very inefficient). Just allow more control by the user. This lowers barriers to entry for the market, and allows for interesting and unique future uses. As for non-standard methods of configuration and support, I see no problem with requiring your own software if you want it to be supported, and requiring it be set to default levels (or a verification that no values are outside norms) before a support incident is allowed. You want to permanently log whether any settings have been set that void your warranty? Go ahead. This is a solved problem. Try to get Apple to fix your phone if the little water sensor inside has been tripped. I see no problem certifying hardware, I'm just not sure how something like UL for software works in practice.
spitfire 10y ago
"Underwriters Laboratory" for devices is such a good idea. This is a world I want to live in. I can imagine warnings like "mothership required", "Uses personal information", etc.
- rogerbinns 10y ago
  How about positives too, like "uses best practises for updates", "uses appropriate authentication and authorisation for its function", "uses a reasonable amount of power" etc
- walterbell 10y ago
  UL plans to certify IoT devices, http://www.computerworld.com/article/3051147/internet-of-things/ul-takes-on-cybersecurity-testing-and-certification.html http://www.computerworld.com/article/3051147/internet-of-thi...

kbenson 10y ago

> Heck people don't even seem to care much about cell phones and keeping them up to date (iPhone and Nexus aside). I think that's inherently a feature of them being too closely linked with the companies that provide them. Phones are the extreme case of what IoT devices could become. Once the phone OS is no longer supported by provider, keeping it is both a liability, and increasingly problematic as things stop working. Compare to old Nokia bumb brick phones. People still use those. While the close control over phones has yielded some advantages (a boost to their markets and security, for one), a phone is generally much more complex than the average IoT device, and is closer to a general purpose device. > As for the last paragraph, perhaps certification instead of standards? Certification doesn't prevent a service from going away a year later. We need a way to hook the device up to another service. If it's a standard, there's nothing to prevent an open source product that you can install on your own server, local or remote. > While there could be conventions for REST endpoints, I'm sceptical they would be of any use. The devices by their nature are special purpose (rather than general) so there would be a lot more domain knowledge needed to make sense of them. I would be interested in exploring some specific examples. What, besides aggregation of audio, video, or stats, and configuration options is there that would be hard to support? Also, I'm not saying we can't or shouldn't have specialized services where it makes sense, just that we should have open standards that companies can work to implement if they choose. > Additionally making them robust against general clients versus only in-house ones is a lot more work. They always need to be robust against general clients. Allowing companies to think they can get away with ignoring this will be very problematic in the future. Having a well defined standard and likely off-the-shelf software to help implement it will probably do quite a bit towards making things more secure, not less. See home routers and the use of openWRT, Tomato, etc. I think this would more than likely raise the lowest common denominator when it comes to security of IoT devices.

rogerbinns 10y ago
Note that certification could also include verifying there is a plan in place for whatever period of support is reasonable. (We could dig deeper on this.) Configuration options are hard to support. Say for example a "power level" setting is exposed (how much power is consumed to provide the device functionality). But it is also the case that more power shortens the lifespan of the device. A general client can end up setting that to 100% but won't know about the consequent lifespan issues, or too low a level results in half the functionality being switched off. By robustness I don't mean malformed inputs etc, but rather what is done with valid values. A general client will be oblivious, but an in house could present only part of the power range (the rest behind an "advanced" section). Settings will also interact with each other in device specific ways (eg power would affect maximum volume for an audio device). Pretty soon you'll need a complicated highly featured description language for the settings, interactions, cautions, effects etc. Also would you want to take support calls if external tools have been modifying the configuration, given that a single support call costs the same or more than the profit on the device? That all said, I see nothing wrong with someone publishing and maintaining a set of best practises. IMHO it is the route most likely to get traction and improvement in devices.
- kbenson 10y ago
  I think any certification that requires a plan be in place for future support is going to be either too weak (if the company goes under, support is gone) or too burdensome (requiring some trust be in place for future support should the company go under is very inefficient). Just allow more control by the user. This lowers barriers to entry for the market, and allows for interesting and unique future uses. As for non-standard methods of configuration and support, I see no problem with requiring your own software if you want it to be supported, and requiring it be set to default levels (or a verification that no values are outside norms) before a support incident is allowed. You want to permanently log whether any settings have been set that void your warranty? Go ahead. This is a solved problem. Try to get Apple to fix your phone if the little water sensor inside has been tripped. I see no problem certifying hardware, I'm just not sure how something like UL for software works in practice.

spitfire 10y ago

"Underwriters Laboratory" for devices is such a good idea. This is a world I want to live in. I can imagine warnings like "mothership required", "Uses personal information", etc.

rogerbinns 10y ago
How about positives too, like "uses best practises for updates", "uses appropriate authentication and authorisation for its function", "uses a reasonable amount of power" etc
walterbell 10y ago
UL plans to certify IoT devices, http://www.computerworld.com/article/3051147/internet-of-things/ul-takes-on-cybersecurity-testing-and-certification.html http://www.computerworld.com/article/3051147/internet-of-thi...