Comment by yc-kraln

7 years ago

This is a very PC centric article, but the same can be said about any connected device--from cars, to baby monitors, to buttplugs. If it has an internet connection, the firmware should either be open source or in open source escrow, so that if the company dies or decides to not support their device anymore, the hardware itself can continue to live.

9 comments

yc-kraln

Reply
jraph  7 years ago

A concrete argument for this: Qualcomm recently released a patch for a vulnerability that makes it possible to access private data stored in the TrustZone of many of its SoCs: https://www.nccgroup.trust/us/our-research/private-key-extra...

The patch needs to be provided by phone and tablet manufacturers. Except that many otherwise capable phones are not supported anymore and will not be fixed.

Were the firmware of these devices open source, the community could fix this (given that the firmware does not have to be signed, or a signing key can be added). But no, many devices will remain forever vulnerable. Including my phone, 4G RAM, 32G internal storage, excellent battery and screen, great computing capabilities, in a excellent physical shape. Will probably last a few years more. Last updated on November 2017 by its manufacturer. Some parts will never be updated again and there is no way to audit this stuff. This is a shame.

Edit: and I'm lucky my phone resembles an Android One phone, so some stuff can be taken from this phone to update mine.

  • woliveirajr  7 years ago

    Perhaps software in general shouldn't be provided _as is_ anymore. The idea that someone provides a software and it's your problem if it doesn't work is really... _too easy_.

    Company A sells you a cell phone. In a reasonable time (5 years? 10?) a flaw is found. You, the costumer, can fix it? No, because it depends on proprietary code, a key, some DRM, whatever.

    So company A should fix it or be accountable for the problem. Being sued, paying for it. Or open the hardware so that user can fix it.

    • jraph  7 years ago

      Right, and anyway, when you get some software, you should be able to fix/improve it yourself if you want to and need to, and redistribute the fix to other people who might be interested. You also should be able to study the software provided to you before running it if you want to.

      Most people don't want to actually do that, but could anyway benefit from the inspection and fixes coming from third parties.

      And when I buy some piece of hardware, I expect the manufacturer to fully support the device, as you said, when used the way it was intended to, but let me use it another way if I want to (which the reliance on closed binary blobs does not allow).

      Moreover, it's time we consider it mandatory that the user has access to the code running on their device. People are not dumb. More and more, people want to know where their food come from and how it is produced. The same transparency should be obvious for what the computer do and how it is built.

      If some things theoretically require the user not to see the code, maybe these things should not exist in the first place. "Oh, here is a product! But for your own good, you do not get to know how it works and what it does or does not do behind your back." This does not follow.

dTal  7 years ago

Source escrow is an interesting concept. My initial thought it that would create huge perverse incentives. A company might continue to release small, nonsense updates to products they otherwise don't care about, just to avoid giving the source away. Meanwhile, as the owner of a device, I would be eagerly awaiting the death of the company, so I can get my hands on that juicy source code. I certainly wouldn't recommend their products! Anything to make them die more quickly.

It gets even more interesting when the "secret sauce" is in software. Say I market "SmartButton 1.0", which is nothing more than an ESP8266 connected to a button, but with some cunning algorithms and proprietary protocols that make it useful. Under an escrow system, I'll have a competitor on my hands the second I stop supporting SmartButton 1.0. Even if I'm already on SmartButton v19.

  • ptx  7 years ago

    The SmartButton scenario is exactly the incentive we want, isn't it?

    If you have made genuine improvements in versions 2-19, releasing version 1 shouldn't hurt too much. If, on the other hand, your versions 1 and 19 are still substantially similar, you shouldn't stop supporting version 1 to save a small cost and completely destroy the value of the product for your customers.

iamnothere  7 years ago

One of the biggest problems is the lower-level chip vendors, who often require NDAs and won't allow their code to be shared publicly. The device maker has to comply with this or find another chip, which may not be available in sufficient quantities or at a realistic price point. The chip vendors don't necessarily go out of business, even if the device maker does.

Considering the global impact on security, this is an area that would make sense for regulation. At some point, the chip vendors should have to release their code to maintainers. I'd even be fine with limiting this to after the chip goes EOL! Perhaps it could come with guarantees reducing patent infringement risks, which may be where much of the vendor reluctance comes from.