5 ms·

What about a law the forces vendors to either provide security updates or publish the source code? That seems like a reasonable trade off between consumer right

by planb 5y ago

What about a law the forces vendors to either provide security updates or publish the source code? That seems like a reasonable trade off between consumer rights and ip protection.

WhyNotHugo 5y ago
Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel. By the time the hardware actually ships, those changes don't work any more with the current Linux kernel. Trying to make those work 2 years later is a huge effort -- probably worth less than just replacing the phones. Mind you, I agree with you in principle, but I can see how in practice in might all go to shit.
- titzer 5y ago
  I guess they gotta stop doing that then, huh? I don't see how consumers and society benefit from rushed, vulnerable crap software. Oh, right. Time to market. Race to the bottom. That's what we need more of.
  - dmitrygr 5y ago
    > I don't see how consumers and society benefit Actually, you do see. The price of your phone would be higher if Qualcomm had to hire competent engineers to make properly designed kernel changes for their hardware.
    - TeMPOraL 5y ago
      How much higher though? If you were to take the total extra expenditure on increased salaries for those engineers, and divide by the number of phones produced, the result is what? A dollar?
      - mathstuf 5y ago
        Sure, but when applying Marketing Math™, remember that all prices need to end in "49" or "99" to "sound cheaper" than the next incremental bump. So you'll end up with a device that is either $50 or (more likely) $100 more than otherwise. Or they'll eat that $1 from their profit margins…eh, who am I kidding?
        Dylan16807 5y ago
        If they're rounding to the nearest $50, they're doing it based on the final cost. They're not going to base it on a what-if scenario of having a cheaper development team. So it's more or less a 2% chance of the price going up $50.
    - goodpoint 5y ago
      The price of your phone would be much lower if the software stack was truly Open Source, allowing distribution to remove clutter and spyware, and make older phones perfectly usable again. Planned obsolescence is designed to increase TCO
  - TeMPOraL 5y ago
    Magic of compartmentalization of concerns. It turns out that getting a bunch of programmers to do careful modifications to some C code base over a couple of months is more work than getting great many thousands of people across multiple companies to manufacture, distribute and sell new hardware to millions of customers.
  - WhyNotHugo 5y ago
    > I guess they gotta stop doing that then, huh? Why would they? They get paid to put out crap, so they'll continue doing it. Bottle water continues to come in plastic bottles, even though glass if far cheaper/easier to reuse or recycle. Plastic bottles are literally trash, yet it'll continue being produced if people keep buying it. Near-disposable phones (both hardware and software) won't stop being manufactured if they continue being in high demand.
- nicoburns 5y ago
  If the code were open source, I'd be willing to bet quite a lot that this kind of code would get cleaned up and mainlined. Certainly for popular handsets from major manufacturers which probably account for the majority of handsets sold.
  - danhor 5y ago
    Thanks to the GPL this is already often the case (at least for the kernel). But vendor code is so abhorrent in quality, upstream efforts are few and far between.
- londons_explore 5y ago
  > Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel. SoC makers deliberately do this as a way to force phone manufacturers to buy new chips. For example, if they release a chipset in 2020, it will ship with Kernel 4.14 (released in 2017). Why ship such an old kernel on brand new hardware you say? Well Android 11 (also shipped in 2020) supports Kernel 4.14, but you can be pretty sure that Android 12 won't support 4.14. So that means that OEM's can't make android 12 work with that chip without a massive engineering effort (and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible). So, the main reason to use a deliberately outdated kernel is to prevent last years chips running next years android release, without the chipset manufacturers permission and a share of the profits.
  - zozbot234 5y ago
    > and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible Binary drivers can be reverse engineered and reimplemented for the new kernel. This takes a lot of effort since it requires following a "proper" clean-room methodology when doing so for interoperability purposes, but is otherwise doable. A complementary approach is to forward port the minimum set of features that's required for Android 12 to the older kernel, in a way that carefully preserves the portions of in-kernel ABI that the binary drivers depend on.
    - google234123 5y ago
      Reversing engineering is hard. It would be nice if the kernel didn’t trash it’s ABI all the time for ideological reasons. Hopefully a new OS (fuscia) will fix this.
  - 908B64B197 5y ago
    Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity. I can see why Android was so popular with OEMs!
    - 5y ago
enriquto 5y ago
Why not both? There is no compromise needed here. Both things benefit the public interest which, after all, should be the author of the law (in a democratic country at least).
- JoshTriplett 5y ago
  > Why not both? There is no compromise needed here. You're assuming that it's actually feasible to keep old devices up to date for that long. It may well not be. It gets substantially harder to maintain old branches the further mainline has diverged from them. The original engineering team has typically long since moved on. The magnitude of the issue, here, can be on the scale of "we now need several times as many engineering teams". This isn't a matter of "security updates would be better than no security updates". This may potentially be a matter of "security updates for four years is economically feasible, security updates for seven years isn't". (I'm not saying it is infeasible, just that it may well be.)
  - enriquto 5y ago
    Thus a neat effect of such a law would be that SOC manufacturers would not purposefully break compatibility as much as they do now. Sounds like a win-win to me!
    - JoshTriplett 5y ago
      Or, much more likely, they'll continue building new hardware as they do now, and let the length of software support for old hardware in one particular market be a software problem for the vendors selling into that market. Don't assume that attempting to solve a problem with a law can only have one possible outcome, and can't possibly have a different outcome instead.
JoshTriplett 5y ago
I think this is much more reasonable as well, for many kinds of devices. Either give people the ability to update the device themselves, or you have to supply updates. (I think 7 years is a bit much, but the duration is a quibble over a minor detail rather than a fundamental principle.)

by planb 5y ago

What about a law the forces vendors to either provide security updates or publish the source code? That seems like a reasonable trade off between consumer rights and ip protection.

WhyNotHugo 5y ago

Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel. By the time the hardware actually ships, those changes don't work any more with the current Linux kernel. Trying to make those work 2 years later is a huge effort -- probably worth less than just replacing the phones. Mind you, I agree with you in principle, but I can see how in practice in might all go to shit.

titzer 5y ago
I guess they gotta stop doing that then, huh? I don't see how consumers and society benefit from rushed, vulnerable crap software. Oh, right. Time to market. Race to the bottom. That's what we need more of.
- dmitrygr 5y ago
  > I don't see how consumers and society benefit Actually, you do see. The price of your phone would be higher if Qualcomm had to hire competent engineers to make properly designed kernel changes for their hardware.
  - TeMPOraL 5y ago
    How much higher though? If you were to take the total extra expenditure on increased salaries for those engineers, and divide by the number of phones produced, the result is what? A dollar?
    - mathstuf 5y ago
      Sure, but when applying Marketing Math™, remember that all prices need to end in "49" or "99" to "sound cheaper" than the next incremental bump. So you'll end up with a device that is either $50 or (more likely) $100 more than otherwise. Or they'll eat that $1 from their profit margins…eh, who am I kidding?
      - Dylan16807 5y ago
        If they're rounding to the nearest $50, they're doing it based on the final cost. They're not going to base it on a what-if scenario of having a cheaper development team. So it's more or less a 2% chance of the price going up $50.
  - goodpoint 5y ago
    The price of your phone would be much lower if the software stack was truly Open Source, allowing distribution to remove clutter and spyware, and make older phones perfectly usable again. Planned obsolescence is designed to increase TCO
- TeMPOraL 5y ago
  Magic of compartmentalization of concerns. It turns out that getting a bunch of programmers to do careful modifications to some C code base over a couple of months is more work than getting great many thousands of people across multiple companies to manufacture, distribute and sell new hardware to millions of customers.
- WhyNotHugo 5y ago
  > I guess they gotta stop doing that then, huh? Why would they? They get paid to put out crap, so they'll continue doing it. Bottle water continues to come in plastic bottles, even though glass if far cheaper/easier to reuse or recycle. Plastic bottles are literally trash, yet it'll continue being produced if people keep buying it. Near-disposable phones (both hardware and software) won't stop being manufactured if they continue being in high demand.
nicoburns 5y ago
If the code were open source, I'd be willing to bet quite a lot that this kind of code would get cleaned up and mainlined. Certainly for popular handsets from major manufacturers which probably account for the majority of handsets sold.
- danhor 5y ago
  Thanks to the GPL this is already often the case (at least for the kernel). But vendor code is so abhorrent in quality, upstream efforts are few and far between.
londons_explore 5y ago
> Frequently SoC manufacturer make quick and dirty changes to a fork of the Linux kernel. SoC makers deliberately do this as a way to force phone manufacturers to buy new chips. For example, if they release a chipset in 2020, it will ship with Kernel 4.14 (released in 2017). Why ship such an old kernel on brand new hardware you say? Well Android 11 (also shipped in 2020) supports Kernel 4.14, but you can be pretty sure that Android 12 won't support 4.14. So that means that OEM's can't make android 12 work with that chip without a massive engineering effort (and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible). So, the main reason to use a deliberately outdated kernel is to prevent last years chips running next years android release, without the chipset manufacturers permission and a share of the profits.
- zozbot234 5y ago
  > and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible Binary drivers can be reverse engineered and reimplemented for the new kernel. This takes a lot of effort since it requires following a "proper" clean-room methodology when doing so for interoperability purposes, but is otherwise doable. A complementary approach is to forward port the minimum set of features that's required for Android 12 to the older kernel, in a way that carefully preserves the portions of in-kernel ABI that the binary drivers depend on.
  - google234123 5y ago
    Reversing engineering is hard. It would be nice if the kernel didn’t trash it’s ABI all the time for ideological reasons. Hopefully a new OS (fuscia) will fix this.
- 908B64B197 5y ago
  Meanwhile in Windows land: You can run 20 years old drivers, no problems. Hardware is a commodity. I can see why Android was so popular with OEMs!
  - 5y ago

enriquto 5y ago

Why not both? There is no compromise needed here. Both things benefit the public interest which, after all, should be the author of the law (in a democratic country at least).

JoshTriplett 5y ago
> Why not both? There is no compromise needed here. You're assuming that it's actually feasible to keep old devices up to date for that long. It may well not be. It gets substantially harder to maintain old branches the further mainline has diverged from them. The original engineering team has typically long since moved on. The magnitude of the issue, here, can be on the scale of "we now need several times as many engineering teams". This isn't a matter of "security updates would be better than no security updates". This may potentially be a matter of "security updates for four years is economically feasible, security updates for seven years isn't". (I'm not saying it is infeasible, just that it may well be.)
- enriquto 5y ago
  Thus a neat effect of such a law would be that SOC manufacturers would not purposefully break compatibility as much as they do now. Sounds like a win-win to me!
  - JoshTriplett 5y ago
    Or, much more likely, they'll continue building new hardware as they do now, and let the length of software support for old hardware in one particular market be a software problem for the vendors selling into that market. Don't assume that attempting to solve a problem with a law can only have one possible outcome, and can't possibly have a different outcome instead.

JoshTriplett 5y ago

I think this is much more reasonable as well, for many kinds of devices. Either give people the ability to update the device themselves, or you have to supply updates. (I think 7 years is a bit much, but the duration is a quibble over a minor detail rather than a fundamental principle.)