4 ms·

If the new device would stop working soon enough after purchase, customers would be more likely to return it to store. I see the normal manufacturers/sellers r

If the new device would stop working soon enough after purchase, customers would be more likely to return it to store. I see the normal manufacturers/sellers responsibility as the only good answer to the problem. I don't like solutions involving fines or large liabilities, because these can create wrong incentives to people/companies. Doing security properly for these devices is not very expensive compared to scale they are being sold. Therefore I think simple things like increased return/warranty repair rates should provide enough incentive to focus on security.

joe_the_user 9y ago
I don't like solutions involving fines or large liabilities, because these can create wrong incentives to people/companies. Making manufacturers liable for incidental damage their devices do sends the message that they should avoid such damages as far as possible. That seems like a good message to me. If device $20 device X does $20,000 damage to the hospital down the road, the fact that the consumer can return the device seems woefully insufficient.
- pdkl95 9y ago
  Making manufacturers liable for the damage their products do is do allows the insurance industry to set minimum standards. (i.e. you would have to get some kind of certification similar to UL/CE to get insurance)
- mindslight 9y ago
  > device $20 device X does $20,000 damage to the hospital down the road If it were able to do that, then presumably that $20 device had eg a good amount of explosive in it, and therefore would be in no condition to return it to the store. Unless you're alluding to that $20 device being used as a communications proxy, under a mistaken idea that the Internet has some concept of node trust. In reality, the hospitals $20k "damage" would be due to its own developers' negligence and demands for compensation should be placed squarely at the door of its suppliers and integrators.
  - dsp1234 9y ago
    So what you're saying here, is that you're happy to let me drop a device of my choosing on to any part of your network, and that you'll take full responsibility for any damage caused because it was your (or your own developer's) negligence.
    - mindslight 9y ago
      I don't see how you're inferring this, as a consumer's home network doesn't have trusted access to the hospital down the street. What I did imply is that if I develop a device and put it on my network, then I'm essentially responsible for whatever damage it causes. Eg wiring a RPi to a heating element that will start a fire if left on continuously is a poor idea, regardless if the proximate cause is a cosmic ray bit flip or malevolent Internet noise.
      - joe_the_user 9y ago
        So, you're saying that if random consumer buys $25 dollar IP aware camera, puts it on their WIFI (and hence the Internet) so they can look at their cat at work, it is that consumer who the DoS-hit hospital down the road should look to, when that hospital is hit by massive botnet-drive ransomeware attack. 'Cause certainly random average-consumer should know how dangerous adding crap to their network can be ... for others ... and certainly he/she is capable of making provisions for this. Fortunately, modern legal theory actually does consider "who are talking about here, what can expected of them." in cases like this. Hospitals could theoretically sue IoT manufacturer on this as far my ianal knowledge goes and it's more that the manufacturers are distant cheap factories in China that prevents this.
        mindslight 9y ago
        > it is that consumer who the DoS-hit hospital down the road should look to, when that hospital is hit by massive botnet-drive ransomeware attack. Erm, no - the exact opposite. The consumer should look at the camera's manufacturer for their own connection being swamped, incurring overage charges, etc. In your scenario, if the hospital's only problem is that their Internet uplink is swamped, then they should be looking at their link provider for robust upstream shaping, etc. In the case of a simple traffic overload, nothing critical at the hospital should be affected because critical traffic should be segmented, or at least prioritized, over traffic from arbitrary endpoints. If there is more of an affect, then that is due to a further vulnerability that belongs to the hospital! I referenced the hospital's developers/suppliers for these further vulnerabilities - in those cases they should be looking at their network admins, or at the creators of the failing (defective) equipment. The crux of the End to End principle (ie the Internet) is that edge nodes have the intelligence, and thus requirement/responsibility, for discerning "good" traffic from "bad". And (as I said) coming at it from the other direction, general robust engineering principle dictates that physical devices "fail safe" no matter what noise is presented at their network ports.
bigiain 9y ago
"Doing security properly for these devices is not very expensive compared to scale they are being sold." Not sure that's true. I did a 18 month stint with a tiny (6 person) hardware startup - most of my time was spent ensuring our devices could auto-update their embedded Linux securely without bricking or losing any of the custom hardware specific capabilities. It's not an easy trick to pull off (big thanks to the ARCH Linux team for all their work that I built on), and there's ongoing cost involved to ensure newly discovered vulnerabilities have a process to be evaluated, patched, tested, and deployed to the fleet of devices.
- wmf 9y ago
  Updates are expensive if you reinvent them from scratch but cheap if you adopt an existing framework.
  - rcxdude 9y ago
    There aren't any good frameworks for doing so in an embedded space. Traditional linux package managers aren't really great for this (nix is the closest to getting it right, but isn't really ready on embedded yet). edit- The main objective, of course, being allowing unattended atomic updates with as low a risk of bricking the device as possible. Usually these devices will be updating the whole root filesystem at a time, which is otherwise read-only. Ideally this is also done with as little downtime as possible. There is some work in this space in standardizing a solution, but it isn't really there yet, so it tends to get home-grown for each product.
    - bigiain 9y ago
      I got super lucky. Between the design/BOM stage and the actual first manufacturing run, the price of 4Gig micro SD cards dropped below the price of 2Gig ones - so I ended up (at the last minute...) with enough space to do a complete system install on a separate partition. Reduced my fears of remote bricking everybody's devices enormously...
- thingification 9y ago

joe_the_user 9y ago

I don't like solutions involving fines or large liabilities, because these can create wrong incentives to people/companies. Making manufacturers liable for incidental damage their devices do sends the message that they should avoid such damages as far as possible. That seems like a good message to me. If device $20 device X does $20,000 damage to the hospital down the road, the fact that the consumer can return the device seems woefully insufficient.

pdkl95 9y ago
Making manufacturers liable for the damage their products do is do allows the insurance industry to set minimum standards. (i.e. you would have to get some kind of certification similar to UL/CE to get insurance)
mindslight 9y ago
> device $20 device X does $20,000 damage to the hospital down the road If it were able to do that, then presumably that $20 device had eg a good amount of explosive in it, and therefore would be in no condition to return it to the store. Unless you're alluding to that $20 device being used as a communications proxy, under a mistaken idea that the Internet has some concept of node trust. In reality, the hospitals $20k "damage" would be due to its own developers' negligence and demands for compensation should be placed squarely at the door of its suppliers and integrators.
- dsp1234 9y ago
  So what you're saying here, is that you're happy to let me drop a device of my choosing on to any part of your network, and that you'll take full responsibility for any damage caused because it was your (or your own developer's) negligence.
  - mindslight 9y ago
    I don't see how you're inferring this, as a consumer's home network doesn't have trusted access to the hospital down the street. What I did imply is that if I develop a device and put it on my network, then I'm essentially responsible for whatever damage it causes. Eg wiring a RPi to a heating element that will start a fire if left on continuously is a poor idea, regardless if the proximate cause is a cosmic ray bit flip or malevolent Internet noise.
    - joe_the_user 9y ago
      So, you're saying that if random consumer buys $25 dollar IP aware camera, puts it on their WIFI (and hence the Internet) so they can look at their cat at work, it is that consumer who the DoS-hit hospital down the road should look to, when that hospital is hit by massive botnet-drive ransomeware attack. 'Cause certainly random average-consumer should know how dangerous adding crap to their network can be ... for others ... and certainly he/she is capable of making provisions for this. Fortunately, modern legal theory actually does consider "who are talking about here, what can expected of them." in cases like this. Hospitals could theoretically sue IoT manufacturer on this as far my ianal knowledge goes and it's more that the manufacturers are distant cheap factories in China that prevents this.
      - mindslight 9y ago
        > it is that consumer who the DoS-hit hospital down the road should look to, when that hospital is hit by massive botnet-drive ransomeware attack. Erm, no - the exact opposite. The consumer should look at the camera's manufacturer for their own connection being swamped, incurring overage charges, etc. In your scenario, if the hospital's only problem is that their Internet uplink is swamped, then they should be looking at their link provider for robust upstream shaping, etc. In the case of a simple traffic overload, nothing critical at the hospital should be affected because critical traffic should be segmented, or at least prioritized, over traffic from arbitrary endpoints. If there is more of an affect, then that is due to a further vulnerability that belongs to the hospital! I referenced the hospital's developers/suppliers for these further vulnerabilities - in those cases they should be looking at their network admins, or at the creators of the failing (defective) equipment. The crux of the End to End principle (ie the Internet) is that edge nodes have the intelligence, and thus requirement/responsibility, for discerning "good" traffic from "bad". And (as I said) coming at it from the other direction, general robust engineering principle dictates that physical devices "fail safe" no matter what noise is presented at their network ports.

bigiain 9y ago

"Doing security properly for these devices is not very expensive compared to scale they are being sold." Not sure that's true. I did a 18 month stint with a tiny (6 person) hardware startup - most of my time was spent ensuring our devices could auto-update their embedded Linux securely without bricking or losing any of the custom hardware specific capabilities. It's not an easy trick to pull off (big thanks to the ARCH Linux team for all their work that I built on), and there's ongoing cost involved to ensure newly discovered vulnerabilities have a process to be evaluated, patched, tested, and deployed to the fleet of devices.

wmf 9y ago
Updates are expensive if you reinvent them from scratch but cheap if you adopt an existing framework.
- rcxdude 9y ago
  There aren't any good frameworks for doing so in an embedded space. Traditional linux package managers aren't really great for this (nix is the closest to getting it right, but isn't really ready on embedded yet). edit- The main objective, of course, being allowing unattended atomic updates with as low a risk of bricking the device as possible. Usually these devices will be updating the whole root filesystem at a time, which is otherwise read-only. Ideally this is also done with as little downtime as possible. There is some work in this space in standardizing a solution, but it isn't really there yet, so it tends to get home-grown for each product.
  - bigiain 9y ago
    I got super lucky. Between the design/BOM stage and the actual first manufacturing run, the price of 4Gig micro SD cards dropped below the price of 2Gig ones - so I ended up (at the last minute...) with enough space to do a complete system install on a separate partition. Reduced my fears of remote bricking everybody's devices enormously...
thingification 9y ago