4 ms·
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
by 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.
- p_l 3y agoCompiled or not matters nothing to GPL2. What matters is whether the code is derivative. And a lot of the problematic blobs are not derivative of kernel code, hell they often don't run in kernel.