5 ms·

The issue that needs to be addressed is economic. Devices are paid for once, but security is ongoing work. The Android world has shown that no-one has figured

The issue that needs to be addressed is economic. Devices are paid for once, but security is ongoing work. The Android world has shown that no-one has figured out how to deal with the mismatch. I'd expect that devices on subscription will do better on security because they have an economic incentive to do so. Even then vendors will want to end of life hardware that is no longer economic to support.

2OEH8eoCRo0 3y ago
We are too spoiled by cheap garbage and the true cost of these things is hidden.
- Goronmon 3y ago
  Yup, all we have to do is make expensive garbage instead, and then the problem would be solved.
ilyt 3y ago
"If you want to stop supporting it before 10 years, open source everything including getting the new firmware onto device (so all the keys etc)" So keep supporting it or give away how your stuff works underneath and allow someone else to. Bricking device into a landfill should not be decision corporation is allowed to take on most (all?) customer devices.
- janosdebugs 3y ago
  This is not viable because what of the vendor used a proprietary build system? They can't open source it. Setting that aside, I have yet to see a complex system that you can rebuild without a lot of undocumented know-how just by having the source code. Companies don't typically keep meticulous documentation on this, they keep people around to do it. When the product goes out of support, the people get transferred or fired.
  - squeaky-clean 3y ago
    It just doesn't work in reality. I work somewhere that makes IoT devices, our microphone noise-cancellation code is written by a third party with a license not to redistribute. They sell their code to multiple companies. If we stopped supporting some device for X years, does that mean we're legally allowed to open source their noise cancelation code?
- riskable 3y ago
  It shouldn't be time-based it should be support-based. As in, the moment you stop supporting your product is the moment you're legally required to publish the source code and any signing keys, tools, etc necessary to use it.
  - raisin_churn 3y ago
    The problem is "oh, we're still supporting it, we just released an update yesterday that fixed an issue with kerning when selecting certain fonts on the built-in LCD. What do you mean 12 critical CVEs unpatched for years?" So now you have to define "supported," which will be lobbied to death by every vendor in the world.
    - riskable 3y ago
      Well, if the company is willing to live with the risks/liability of a still-supported product containing unfixed vulnerabilities then they're clearly not long for this world. Eventually someone will sue--no matter what the support agreement/TOS states--and they will win. Even if they don't it'll still be a pointless large expense for the business.
  - AnthonyMouse 3y ago
    Then by the time you can see what they actually provided, the company is already bankrupt and if what they provided is non-compliant or otherwise useless, it's too late. There is no excuse for not providing it from day one. And more than one reason to do it -- not only do you verify that you have what you need before they're gone, it allows people to find vulnerabilities sooner so they get patched before more people have the vulnerable device, and allows them to improve the software in general even when the hardware vendor is in a commodity market with margins to slim too do it themselves.
  - brightlancer 3y ago
    So any company that makes a device knows that all their proprietary work will become public if they end support -- that seems like a great reason for companies to not build devices.
- teeray 3y ago
  The FCC actually could have a decent mechanism to force this. The documentation for Part 15 compliance often has a confidentiality request for certain device internals. They could have some uncloaking mechanism where that information is released if the company is no longer supporting the device.
  - TrueDuality 3y ago
    That's a pretty slick idea actually. I've been battling on the upstream reference design angle as I think that's where a lot of security issues truly come from. Release of device internals probably wouldn't help fix those upstream references unless it also covered support the drivers of individual electronic chips from their producers as well, but it definitely would help opensource devs to potentially fix things for devices they love.
TrueDuality 3y ago
If you look deeper into the issue, there is a lot of people willing to do volunteer security work to keep using devices they love. I don't think we should have to rely on this and without it I 100% agree with what you're saying. The other side of the coin, the other option we shouldn't really rely on but we can, is entirely blocked by the way these vendors operate. Android has had its fragmentation issues because the vendors aren't using the stock Android, and aren't upstreaming the drivers and tweaks needed to actually run Android on their hardware. There is usually an economic incentive to not do so (if a custom ROM can be made for their phone, they won't get the ad and deal revenue from the garbage they've preloaded into the phone). Some do this better than others and there are custom ROMs out there that allow you to update, but custom ROMs are a horrible solution for most customers. It's really only accessible to technical people that have the time and energy to put into it and maintain it directly. The same thing is true for most IoT devices, the drivers aren't upstreamed, the source is closed, third parties can't fix the software or use it outside the designed ecosystem and the manufacturer doesn't have an economic incentive to give you any time after you've purchased their product. A lot of manufacturers of devices are mostly white labeling reference designs with a small modification for an extra sensor or other relatively small benign change to the electrical schematic and they'll correspondingly use the reference software for that design which hasn't been updated in 20 years since the reference design was created. Those designs usually have the same problem, the manufacturer of the chip had some devs hand edit a "stable" version of the Linux kernel outside of any source control or public repository and shipped a binary with custom drivers (probably not up to the normal quality expected of code merged into the kernel either). I think that last one is really the sticking point. The fractured Android ecosystem isn't great but its fracturing issues have been much better in the past 6-8 years than it was up till about Android 8 (based on my recollections) so is kind of an outdated example at this point. If manufacturers of custom ICs kept reference designs up to date, or upstream their drivers into mainline Linux that becomes the economically cheapest, lowest effort, and widest impact change that could make meaningful security improvements to all devices produced. I have zero idea how to turn that into something that can be legislated though.
- pierat 3y ago
  > The other side of the coin, the other option we shouldn't really rely on but we can, is entirely blocked by the way these vendors operate. Android has had its fragmentation issues because the vendors aren't using the stock Android, and aren't upstreaming the drivers and tweaks needed to actually run Android on their hardware. There is usually an economic incentive to not do so (if a custom ROM can be made for their phone, they won't get the ad and deal revenue from the garbage they've preloaded into the phone). That's a really long-winded way to say "Violate GPL of Linux Kernel". Compiled in closed source modules is explicitly against terms of GPL2, and yet billions of violating portable computers. And people wonder why I pirate? Our rights are constantly shat on by the same interests that would imprison us for copying software or movies.
gsich 3y ago
The Android shitshow has a major problem: Qualcomm

2OEH8eoCRo0 3y ago

We are too spoiled by cheap garbage and the true cost of these things is hidden.

Goronmon 3y ago
Yup, all we have to do is make expensive garbage instead, and then the problem would be solved.

ilyt 3y ago

"If you want to stop supporting it before 10 years, open source everything including getting the new firmware onto device (so all the keys etc)" So keep supporting it or give away how your stuff works underneath and allow someone else to. Bricking device into a landfill should not be decision corporation is allowed to take on most (all?) customer devices.

janosdebugs 3y ago
This is not viable because what of the vendor used a proprietary build system? They can't open source it. Setting that aside, I have yet to see a complex system that you can rebuild without a lot of undocumented know-how just by having the source code. Companies don't typically keep meticulous documentation on this, they keep people around to do it. When the product goes out of support, the people get transferred or fired.
- squeaky-clean 3y ago
  It just doesn't work in reality. I work somewhere that makes IoT devices, our microphone noise-cancellation code is written by a third party with a license not to redistribute. They sell their code to multiple companies. If we stopped supporting some device for X years, does that mean we're legally allowed to open source their noise cancelation code?
riskable 3y ago
It shouldn't be time-based it should be support-based. As in, the moment you stop supporting your product is the moment you're legally required to publish the source code and any signing keys, tools, etc necessary to use it.
- raisin_churn 3y ago
  The problem is "oh, we're still supporting it, we just released an update yesterday that fixed an issue with kerning when selecting certain fonts on the built-in LCD. What do you mean 12 critical CVEs unpatched for years?" So now you have to define "supported," which will be lobbied to death by every vendor in the world.
  - riskable 3y ago
    Well, if the company is willing to live with the risks/liability of a still-supported product containing unfixed vulnerabilities then they're clearly not long for this world. Eventually someone will sue--no matter what the support agreement/TOS states--and they will win. Even if they don't it'll still be a pointless large expense for the business.
- AnthonyMouse 3y ago
  Then by the time you can see what they actually provided, the company is already bankrupt and if what they provided is non-compliant or otherwise useless, it's too late. There is no excuse for not providing it from day one. And more than one reason to do it -- not only do you verify that you have what you need before they're gone, it allows people to find vulnerabilities sooner so they get patched before more people have the vulnerable device, and allows them to improve the software in general even when the hardware vendor is in a commodity market with margins to slim too do it themselves.
- brightlancer 3y ago
  So any company that makes a device knows that all their proprietary work will become public if they end support -- that seems like a great reason for companies to not build devices.
teeray 3y ago
The FCC actually could have a decent mechanism to force this. The documentation for Part 15 compliance often has a confidentiality request for certain device internals. They could have some uncloaking mechanism where that information is released if the company is no longer supporting the device.
- TrueDuality 3y ago
  That's a pretty slick idea actually. I've been battling on the upstream reference design angle as I think that's where a lot of security issues truly come from. Release of device internals probably wouldn't help fix those upstream references unless it also covered support the drivers of individual electronic chips from their producers as well, but it definitely would help opensource devs to potentially fix things for devices they love.

TrueDuality 3y ago

If you look deeper into the issue, there is a lot of people willing to do volunteer security work to keep using devices they love. I don't think we should have to rely on this and without it I 100% agree with what you're saying. The other side of the coin, the other option we shouldn't really rely on but we can, is entirely blocked by the way these vendors operate. Android has had its fragmentation issues because the vendors aren't using the stock Android, and aren't upstreaming the drivers and tweaks needed to actually run Android on their hardware. There is usually an economic incentive to not do so (if a custom ROM can be made for their phone, they won't get the ad and deal revenue from the garbage they've preloaded into the phone). Some do this better than others and there are custom ROMs out there that allow you to update, but custom ROMs are a horrible solution for most customers. It's really only accessible to technical people that have the time and energy to put into it and maintain it directly. The same thing is true for most IoT devices, the drivers aren't upstreamed, the source is closed, third parties can't fix the software or use it outside the designed ecosystem and the manufacturer doesn't have an economic incentive to give you any time after you've purchased their product. A lot of manufacturers of devices are mostly white labeling reference designs with a small modification for an extra sensor or other relatively small benign change to the electrical schematic and they'll correspondingly use the reference software for that design which hasn't been updated in 20 years since the reference design was created. Those designs usually have the same problem, the manufacturer of the chip had some devs hand edit a "stable" version of the Linux kernel outside of any source control or public repository and shipped a binary with custom drivers (probably not up to the normal quality expected of code merged into the kernel either). I think that last one is really the sticking point. The fractured Android ecosystem isn't great but its fracturing issues have been much better in the past 6-8 years than it was up till about Android 8 (based on my recollections) so is kind of an outdated example at this point. If manufacturers of custom ICs kept reference designs up to date, or upstream their drivers into mainline Linux that becomes the economically cheapest, lowest effort, and widest impact change that could make meaningful security improvements to all devices produced. I have zero idea how to turn that into something that can be legislated though.

pierat 3y ago
> The other side of the coin, the other option we shouldn't really rely on but we can, is entirely blocked by the way these vendors operate. Android has had its fragmentation issues because the vendors aren't using the stock Android, and aren't upstreaming the drivers and tweaks needed to actually run Android on their hardware. There is usually an economic incentive to not do so (if a custom ROM can be made for their phone, they won't get the ad and deal revenue from the garbage they've preloaded into the phone). That's a really long-winded way to say "Violate GPL of Linux Kernel". Compiled in closed source modules is explicitly against terms of GPL2, and yet billions of violating portable computers. And people wonder why I pirate? Our rights are constantly shat on by the same interests that would imprison us for copying software or movies.

gsich 3y ago

The Android shitshow has a major problem: Qualcomm