The concept of community firmware seems like a huge cop-out that allows companies to externalize costs. And it probably won't help security because 99% of devices will never get the third-party firmware installed anyway.

▲

AnthonyMouse 10 hours ago | parent | next [-]

If they were trying to save costs they would ship the community firmware on the device to begin with because then they wouldn't have to write and maintain their own. The community welcomes them to externalize those costs onto the people with better incentives to improve the software.

What they're actually trying to do is obsolete the devices faster because then they won't add new protocols or other software-only features to older devices so you have to buy a new one, or only expose features in more expensive models that the less expensive hardware would also be capable of doing. Which is all the more reason for us to not have that.

And if they were required to allow anyone to replace the firmware then you would get companies reflashing and selling them that way from the store because the free firmware has more advertisable features. There's a reason you can go to major PC OEMs and pick between Windows, Linux and "don't even install one" and the reason is that if you give customers a choice, they generally don't want their software to be made by the OEM.

▲

sroussey 10 hours ago | parent | prev [-]

It could be part of dissolution of the company to mandate community firmware. But it depends on their licenses…

Anyhow, this is a common enough practice. Many companies that provide infrastructure type software and sell to Fortune 500 companies often have a clause whereby they deliver their software to their customers if the shut down.

▲

AnthonyMouse 10 hours ago | parent [-]

We don't care about their licenses; that's their problem. If they need firmware with a license that allows them to redistribute it there are plenty of free ones to choose from.

And you can't wait until after they're dead to have them do something. By then they're gone or judgment proof because they're already bankrupt. Especially when you're talking about companies that aren't in the jurisdiction because you can't even make them do anything when they're already not shipping products to you anymore. It has to be from Day 1.

▲

walterbell 9 hours ago | parent [-]

> It has to be from Day 1.

There was a promising design from Azure Sphere for 10 years of IoT device Linux security updates from Microsoft, even if the IoT vendor went out of business. This required a hardware design to isolate vendor userspace code from device security code, so they could be updated independently. Could be resurrected as open standard with FRAND licensing.

▲

AnthonyMouse 9 hours ago | parent [-]

The main thing you need is for the lowest-level code to be open and replaceable/patchable because it's the only part which is actually specific to the device. Windows running on Core Boot is a better place to be than custom Linux running on opaque blob, because in the first case you can pretty easily get to newer Windows, vanilla Linux or anything else you want running on Core Boot after the original version of Windows goes out of support, and you can update Core Boot, whereas the latter often can't even get you to a newer version of Linux.

	▲	walterbell 8 hours ago \| parent [-]
		Modern coreboot depends on opaque blobs on CPU (FSP/ACM on Intel) and auxiliary processors (ME/PSP), but AMD is moving in the right direction with OpenSIL host firmware. Arm devices have their own share of firmware blobs. A decade of security updates for routers would require stable isolation between low-level device security and IoT vendor userspace. In Sphere, the business model for 10 years of paid updates was backed by hardware isolation. Anyone know why it didn't get market traction? There was a dev board, but no products shipped.