Hacker News Reader

Comment by ChrisCinelli | Hacker News Reader

Openwrt is not the best example. Community sucks, some routers are full of bugs and the security is not great either.

In general even if I like open devices and having the option to use my own software, this is not a solution for most of the consumers.

It is not a solution even for the enthusiast that know how to flash their own firmware. Because even if they may do it a few times initially, eventually they stop doing it.

You need a system that can update automatically even when you are busy in another project.

View on HN

openwrt is surely lacking in many aspects, but all the points you brought forward also apply to the manufacturer firmware but those are even less user friendly and cannot be modified.

there are a lot of open and closed firmware projects building upon openwrt

> but all the points you brought forward also apply to the manufacturer firmware but those are even less user friendly and cannot be modified.

That's more than a reach of a claim. All manufacturer firmware are buggy with poor security? That's very obviously false. With closed manufacturers the history is that it's a mixed bag, not a blanket. Some are excellent, some are very poor.

Openwrt has been mediocre and all the negatives about it do not equally apply to all closed manufacturer firmware.

> All manufacturer firmware are buggy with poor security? That's very obviously false.

guess we have a difference of opinion then

I am not clear how "all the points you brought forward also apply to the manufacturer firmware"

There is absolutely no scenario where I want the firmware of any of my infrastructure devices updating without my say so. Even if there are dire security consequences of not updating.

If a firmware update on my smart watch bricks it, who cares? But if my entire house/office is without internet connection because of a bug in the router update, then I don't want to waste time determining if its my ISP, my physical connection, my local hardware, or the firmware update that just occurred silently. I want to send the "update" command, note that network response did not resume within 5 minutes, and revert from there.

A lot of folks tend to think of firmware updates as identical in complexity and risk to any other software update. I submit that if it can't go wrong in such a way that it requires an in-system-programmer to fix, its a software update, not a firmware update.

In that sense, I think true firmware updates (e.g. BIOS updates and the like) require a different set of regulations than your standard IoT security updates.

I see two essential points (that might have been addressed in another comment somewhere else in the thread, but I can't read everything) regarding pushed firmware updates:

• It happens, especially if the update has been a "quick fix" to a security issue, that the update introduces unexpected behaviours, or incompatibilities. Supposing this was just a "security-only" update that doesn't change any features, I would approve it, and then discover it breaks something in my installation (e.g., compatibility with a specific device or software I'm using). In that case, I need to be able to rollback the update and run the previous firmware version (possibly mitigating the security issue in another way, if it's properly documented) to avoid serious issues that, depending on the device, might prevent important equipment from being operated.

• For firmware updates that include more than security fixed, approval and the possibility of rolling back is even more important. It's quite common that updates remove seldom-used features a minority of users depend on. It even happens that some features get removed and replaced by subscription-only services, which is even worse.

Reply on news.ycombinator.com