4 ms·
There's no incentive for manufacturers to do anything. This actually just increases sales, as dead devices are replaced (probably by the same device/firmware).
by yborg 9y ago
There's no incentive for manufacturers to do anything. This actually just increases sales, as dead devices are replaced (probably by the same device/firmware). Insecurity converts the equipment to a consumable that generates an annuity.
- DougN7 9y agoThis is the key problem. The manufacturer might even consider the poor security as a feature (for them)
- bigiain 9y agoThere's a couple of other problems there too - the "manufacturer" is often some unknown and unfindable usually Chinese contract electronics assembly firm, who had little to do with the design or software. The company who contracted them to do it often no longer exists a few years down the track. The place it gets sold can easily be somewhere like Ebay, AliExpress, or Kickstarter - where the vendor really isn't going to care once your payment has cleared. (Source: I was the platform security guy for an IoT startup in 2013/14, for a company who no longer exists and who's only product run is still out there somewhere no longer getting security updates...)
- jpalomaki 9y agoIf 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 agoI 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 agoMaking 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 agoSo 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 agoI 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.
- 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 agoUpdates are expensive if you reinvent them from scratch but cheap if you adopt an existing framework.
- rcxdude 9y agoThere 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 agoI 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