6 ms·

> There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upg

> There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upgrade a kernel unless/until the supplier provides a fix. Of course, strong regulation here could help to drive bad practices like that out of the industry, but I'm not going to hold my breath on that one. The effect of regulation like this would make it harder for manufacturers who don't have the market power to lean on their suppliers to provide security patches. This. We were building an IoT product that was effectively stuck on a derivative of Ubuntu 18.04; we couldn't upgrade because vendor wouldn't rebase on a new LTS for a very long time. As our project was being developed in Python, we were stuck on 3.6, and as it reached EOL, many third-party libraries dropped support and wouldn't even release security fixes; we needed to stay on that particular OS because of hardware support; and moving off the distribution-provided Python packages would increase maintenance burden beyond what we were able to handle. Even if the vendor would continue to provide security updates to the base OS and its packages, any real-world software solution will rely on third party packages, which may choose to drop support. I would love it if the lawmakers considered this scenario.

oezi 3y ago
Then fire your shitty vendor or refund your customers. Nothing will change unless everybody changes.
- jnwatson 3y ago
  You can't fire your SoC vendor especially once the product ships. And their are all PITA about security updates.
  - oezi 3y ago
    If you buy from a supplier with a contract that stipulates security updates then you certainly would define the damages which failure to fix will cause you, wouldn't you?
    - AnthonyMouse 3y ago
      One of the issues is that the upstream vendor goes out of business. What you really need is to have the source code for the firmware, ideally in the public mainline kernel tree so that new kernel versions continue to work on the hardware.
      - oezi 3y ago
        Certainly true. Source code escrow should be part of any kind of company selling internet connected devices.
vkou 3y ago
> I would love it if the lawmakers considered this scenario. You're building on quicksand, and you're asking for us to give you leeway when the building collapses. Either do the work of making all of those security fixes yourself, or pick a better platform to build on top of.
- rollcat 3y ago
  > pick a better platform Unfortunately there isn't all that much competition in this space. The choice was try building on quicksand, or let the idea die. I'm glad we tried it.
  - vkou 3y ago
    Until there are consequences for building on quicksand, the vendors have no reason to improve their offerings.
    - rollcat 3y ago
      I don't understand what are you trying to imply here? That we should be punished for building a prototype? Or that had we shipped it in its current state, upstream vendor should be punished for stalling on updates?
cycomanic 3y ago
This is an honest question to these arguments, but as a consumer (and as an extension the FCC protecting them) why should I care? Would you accept the same arguments from your car manufacturer, "sorry we can't fix your broken brakes, our supplier uses a process that isn't supported by new brake standards so just don't brake"? I suspect not, so why not because the car is more expensive? I would argue that the purpose of regulation is exactly to root out this sort of practice. If it was cheap and effortless to do this we likely wouldn't need regulation.
- svnt 3y ago
  The same thing happened to my car — they discontinued support for the cellular module it shipped with. I had to bring it in (and I believe pay something) to have the module updated. I did not and now it no longer has the online functionality. Brakes are not internet-connected, but where the line is between features or functions that might be lost and those that represent the core of the product is an interesting question.
  - TeMPOraL 3y ago
    That's the thing though: most IoT devices shouldn't be Internet-connected, and most definitely should not depend on a vendor cloud (or increasingly, a cloud of a different vendor that sold white-label IoT solution to the "vendor" you you bought the device from). It's an unnecessary limitation, a combination of laziness (going over cloud is easier than figuring out local-first and standardizing on some VPN solution) and abusive business (the cloud on the other side of the world is holding your Internet-connected air conditioner hostage, better play nice). If brakes are not Internet-connected, that's mostly because they were established before Internet - and given the trends in car manufacturing in general, it's only a matter of time. (In some sense, we're already there - if you have cloud-connected self-driving, and that self-driving can override your command to apply brakes, then your brakes are de-facto Internet-connected, even if connectivity isn't a hard dependency in all cases just yet.)
  - rollcat 3y ago
    Brakes are fundamentally both a safety-critical system, and one that is both relatively well isolated from other systems, and dead simple in principle (a bike has simple mechanical brakes and a 3yro could explain why they work). The issue with software OTOH, is that a security hole in one trivial component (e.g. resize images to make thumbnails) can often lead to a full system compromise. Even if you don't get full root, you can still use a compromised system to your advantage: steal personal data, use it in a botnet, serve malware, mine proof of waste, etc. On top of that, adding a dependency is often made very easy by modern package managers, and as the number goes up it gets rather difficult even to vet your direct dependencies, let alone transitive. Installing brakes in a vehicle doesn't automatically pull in a kitchen sink, but in the software world it's widely accepted, almost inevitable. You can spend your time removing the 90% of that library that you don't need, and rewriting the remaining 10%, or you do the "reasonable" thing and just ship.
Trombone12 3y ago
As the support schedule for python is known ahead of time, this scenario seems pretty well covered by "disclosure of how long the product will receive security updates": just choose the EOL for the relevant python version in the date-picker.
dmurray 3y ago
Under sensible regulation you wouldn't get to blame a third party here. You would have signed a contract with your vendor to give you updates in line with what the regulation demands, and your insurance company would cover your liability if the vendor goes out of business and you have to pay through the nose to replace them or settle a class action lawsuit. Your expenses would go up and those would be passed on to the consumer, but everyone cheering for this regulation is OK with that. Hopefully the marginal cost of insurance and better vendors would be only slightly above the cost of providing this kind of long term support.
cstejerean 3y ago
> stuck on a derivative of Ubuntu 18.04 [...] as our project was being developed in Python, we were stuck on 3.6 I might be missing something but why do you need to rely on the OS provided Python version? Newer versions that 3.6 should run on older Ubuntu versions. You could have installed newer versions using the deadsnake PPA for example onto 18.04 up until earlier this year (since LTS only has a 5 year support window, and deadsnakes only supports active LTS versions).
- rollcat 3y ago
  If we had the resources to disentangle the entire Python situation, trust me we would. Unfortunately the web of dependencies for that project was quite intricate, and at one point you just need to swallow the vendor's proprietary libraries that they've built against what they've shipped in the base OS. (L)GPL is good on paper, but the effort to actually make use of the freedom it grants is disproportionate. (Which is why I'm a firm believer in the suckless philosophy: if the software is too complex to fully understand, source access or even copyleft aren't worth much.)
  - mkoubaa 3y ago
    GPL is burdensome for businesses to comply with, so I would support public funding for drop in replacements for common GPL tools and libraries

oezi 3y ago

Then fire your shitty vendor or refund your customers. Nothing will change unless everybody changes.

jnwatson 3y ago
You can't fire your SoC vendor especially once the product ships. And their are all PITA about security updates.
- oezi 3y ago
  If you buy from a supplier with a contract that stipulates security updates then you certainly would define the damages which failure to fix will cause you, wouldn't you?
  - AnthonyMouse 3y ago
    One of the issues is that the upstream vendor goes out of business. What you really need is to have the source code for the firmware, ideally in the public mainline kernel tree so that new kernel versions continue to work on the hardware.
    - oezi 3y ago
      Certainly true. Source code escrow should be part of any kind of company selling internet connected devices.

vkou 3y ago

> I would love it if the lawmakers considered this scenario. You're building on quicksand, and you're asking for us to give you leeway when the building collapses. Either do the work of making all of those security fixes yourself, or pick a better platform to build on top of.

rollcat 3y ago
> pick a better platform Unfortunately there isn't all that much competition in this space. The choice was try building on quicksand, or let the idea die. I'm glad we tried it.
- vkou 3y ago
  Until there are consequences for building on quicksand, the vendors have no reason to improve their offerings.
  - rollcat 3y ago
    I don't understand what are you trying to imply here? That we should be punished for building a prototype? Or that had we shipped it in its current state, upstream vendor should be punished for stalling on updates?

cycomanic 3y ago

This is an honest question to these arguments, but as a consumer (and as an extension the FCC protecting them) why should I care? Would you accept the same arguments from your car manufacturer, "sorry we can't fix your broken brakes, our supplier uses a process that isn't supported by new brake standards so just don't brake"? I suspect not, so why not because the car is more expensive? I would argue that the purpose of regulation is exactly to root out this sort of practice. If it was cheap and effortless to do this we likely wouldn't need regulation.

svnt 3y ago
The same thing happened to my car — they discontinued support for the cellular module it shipped with. I had to bring it in (and I believe pay something) to have the module updated. I did not and now it no longer has the online functionality. Brakes are not internet-connected, but where the line is between features or functions that might be lost and those that represent the core of the product is an interesting question.
- TeMPOraL 3y ago
  That's the thing though: most IoT devices shouldn't be Internet-connected, and most definitely should not depend on a vendor cloud (or increasingly, a cloud of a different vendor that sold white-label IoT solution to the "vendor" you you bought the device from). It's an unnecessary limitation, a combination of laziness (going over cloud is easier than figuring out local-first and standardizing on some VPN solution) and abusive business (the cloud on the other side of the world is holding your Internet-connected air conditioner hostage, better play nice). If brakes are not Internet-connected, that's mostly because they were established before Internet - and given the trends in car manufacturing in general, it's only a matter of time. (In some sense, we're already there - if you have cloud-connected self-driving, and that self-driving can override your command to apply brakes, then your brakes are de-facto Internet-connected, even if connectivity isn't a hard dependency in all cases just yet.)
- rollcat 3y ago
  Brakes are fundamentally both a safety-critical system, and one that is both relatively well isolated from other systems, and dead simple in principle (a bike has simple mechanical brakes and a 3yro could explain why they work). The issue with software OTOH, is that a security hole in one trivial component (e.g. resize images to make thumbnails) can often lead to a full system compromise. Even if you don't get full root, you can still use a compromised system to your advantage: steal personal data, use it in a botnet, serve malware, mine proof of waste, etc. On top of that, adding a dependency is often made very easy by modern package managers, and as the number goes up it gets rather difficult even to vet your direct dependencies, let alone transitive. Installing brakes in a vehicle doesn't automatically pull in a kitchen sink, but in the software world it's widely accepted, almost inevitable. You can spend your time removing the 90% of that library that you don't need, and rewriting the remaining 10%, or you do the "reasonable" thing and just ship.

Trombone12 3y ago

As the support schedule for python is known ahead of time, this scenario seems pretty well covered by "disclosure of how long the product will receive security updates": just choose the EOL for the relevant python version in the date-picker.

dmurray 3y ago

Under sensible regulation you wouldn't get to blame a third party here. You would have signed a contract with your vendor to give you updates in line with what the regulation demands, and your insurance company would cover your liability if the vendor goes out of business and you have to pay through the nose to replace them or settle a class action lawsuit. Your expenses would go up and those would be passed on to the consumer, but everyone cheering for this regulation is OK with that. Hopefully the marginal cost of insurance and better vendors would be only slightly above the cost of providing this kind of long term support.

cstejerean 3y ago

> stuck on a derivative of Ubuntu 18.04 [...] as our project was being developed in Python, we were stuck on 3.6 I might be missing something but why do you need to rely on the OS provided Python version? Newer versions that 3.6 should run on older Ubuntu versions. You could have installed newer versions using the deadsnake PPA for example onto 18.04 up until earlier this year (since LTS only has a 5 year support window, and deadsnakes only supports active LTS versions).

rollcat 3y ago
If we had the resources to disentangle the entire Python situation, trust me we would. Unfortunately the web of dependencies for that project was quite intricate, and at one point you just need to swallow the vendor's proprietary libraries that they've built against what they've shipped in the base OS. (L)GPL is good on paper, but the effort to actually make use of the freedom it grants is disproportionate. (Which is why I'm a firm believer in the suckless philosophy: if the software is too complex to fully understand, source access or even copyleft aren't worth much.)
- mkoubaa 3y ago
  GPL is burdensome for businesses to comply with, so I would support public funding for drop in replacements for common GPL tools and libraries