[ymyms]

Great points! As an addendum to this, if #2 becomes untenable for whatever reason (such as a vulnerability in the factory firmware image), then this #3 would be good to strive for as well:

3. have a set of conditions to mark the running firmware image as "safe" and have it become the new fallback firmware image for this scenario. That way you can have a recently up-to-date firmware version constantly trailing the new ones

[Zenbit_UX]

IMO this is a terrible idea for many reasons but the most important of which is: As a consumer I should have the right to have my device revert any b.s. update and get my setup to how it was the day I bought it.

So many companies have begun rolling out updates that makes the device I purchased call home before allowing any user functions and if/when that server goes down my device becomes a brick. This behavior essentially invalidates my ownership of the product and renders it to a service, provided at will by the manufacturer.

Your idea ensures my device will one day become a brick as soon as the manufacturer decides to mark their update requiring internet check-ins “safe”.

If you think I’m exaggerating check out Louis Rossmann‘s YouTube channel.

[ymyms]

FWIW, my background is in B2B hardware and that's the perspective I am coming here with. Out of curiosity though, how do you weigh your value of control vs. security vulnerabilities? Modern speaker systems allow some form of wireless connectivity, so there is bound to be something and not all consumers will be savvy enough to keep up with security updates on their own.

[Zenbit_UX]

My thoughts on security vulnerabilities is that they exist on any out of date firmware and that should be expected. I’ve never rolled back to factory settings and assumed that this device is now exposable on a DMZ.

Specifically I’m talking about consumer devices, which are almost always behind a NAT config + firewall. If your soundbar has a vulnerability it’s pretty much irrelevant if someone has already breached your network.

If we’re talking about enterprise networking equipment, I still stand by my concerns that the the owner should be able to revert back to stock but the burden of responsibility is on the technician configuring this device, not the manufacturer.

[Zak]

It seems to me the mentality has become that since end users tend to be bad at system administration, they shouldn't be allowed to do it, for their own good.

I reject this mentality. I don't think it's necessary or desirable to make it impossible for people to do things that have negative consequences for themselves. Put a "here there be dragons" warning on the firmware rollback, bootloader unlock, or similar dangerous operation and let people take responsibility for the outcome.

In the case of consumer devices, most people won't even try those things; those who do risk further problems for the chance of a better outcome. In the case of enterprise networking equipment, there's an IT department that, in theory has the skills and resources necessary to make good decisions about technology.

[pc86]

There will always be security issues, so "but security" is not a reason to prevent a consumer from doing whatever they want with a thing that they purchased from you (I'm of course just speaking morally/ethically here since there's no legal provisions preventing that in most places).

If I pay you for a product, you have no moral right to tell me what I can and cannot do with that product, up to and including messing with the firmware, installing known-bad firmwares, wiping it and building my own firmware, whatever I want. It's mine, I paid for it, stop violating my private property rights.

[echoangle]

I think I agree with you generalle but just from a logics perspective, this is a bad argument:

> There will always be security issues, so "but security" is not a reason to prevent a consumer from doing whatever they want with a thing that they purchased from you

Just because there will always be security issues doesn't mean you shouldn't try to take care of the low hanging fruit.

[gopher_space]

Not the person you replied to, but I'm literally pulling wire again to avoid dealing with that dichotomy. And hardware developers that think OTW firmware updates are a neat idea >:(

[bmicraft]

Unfortunate you'd need to weave that all the way through the whole product stack in order not to end up in a state that looks like it's working at first glance but actually isn't doing what it is supposed to - like everything running but not showing an image, or everything running except networking is dead (-> also no further updates possible), or (remote) input devices, etc etc

[gavinsyancey]

From the manufacturer's point of view, a sufficient "safe" state is "can receive and apply a firmware update" -- worst case scenario you can always push out a new re-signed and renumbered version of the older working version.

[ymyms]

Network connectivity would need to be in the set of checks to determine if an update was successful. Also, there should hopefully be QA. If you only have one smoke-test for a firmware image it should be whether or not it can upgrade/downgrade a new image from that one.