A few days ago we wrote about the latest news of the FCC’s proposal to control how home routers are developed, and as a by-product, limit people’s ability to write and use third-party router software. This proposal was met with a response from members of the internet community who believe that the proposal would limit innovation and force large parts of the internet to run on software that is known to be problematic, buggy and vulnerable to malicious attacks. The response to the FCC was signed by a group of 260 concerned experts who were led by Vint Cerf (the acknowledged co-inventor of the internet) and Dave Taht (co-founder of the Bufferbloat project).
We were quite surprised to receive a note from Dave Taht responding to our post. The response was in reference to something that we had written about the group’s list of recommendations:
As we read these recommendations two things immediately come to mind. First, these seem like a good set of rules to follow in order to achieve a better and more secure infrastructure. Second, the people writing these recommendation don’t know (or perhaps don’t care) how home router software actually gets written. Do they really think that router vendors follow good established software engineering practice such as being able to completely build their executable from scratch? Ha!! Think again. Not that it shouldn’t happen, but holding router vendors to this standard will cause a great deal of change in how consumer networking products are developed and delivered.
Dave wanted us to know, in no uncertain terms, that he and the others were most certainly aware of the primitive ways in which router vendors develop their software. His exact words were:
&#!%, yea, we know we are so &#!%ing &#!%ed, and to what detail we are &#!%ed, and this is the only way we could come up with to start fixing it
And he’s right. It is no secret at all that the development of commercial router software often ignores many of the basic software engineering principles that are commonly accepted. What is delivered as stock router firmware is often a Mulligan Stew of custom code, open source software, and assorted hardware drivers (often without the source code) all cobbled together with no regard to maintainability. Of course, this leads us to the situation where finding security vulnerabilities in home networking products is the acceptable norm.
So yes, we were wrong in saying that those guys don’t know how router software is built. What we were trying to really say (but failed at) was that suggesting that the router vendors stop what they’re doing and suddenly start doing things the right way was a bit overly-optimistic. How these devices are developed really all comes down to economics. Companies try to cut corners in development costs any way they can, so if a certain chip that you want to use requires you to abandon good software practices, vendors will do it to stay competitive.
This unfortunately will lead us into a state of status quo that will be difficult to escape from. No one vendor will unilaterally adopt better development processes on their own. Fortunately, the seeds for escape have been sown. If the entire industry is forced to reevaluate how they operate, we’ll all win. The FCC does have the power to legislate, so they could enact rules that contain objectives that could not be met unless the companies begin to adopt better software practices. Of course, the initial FCC proposal does not do this, but seeing how much attention this topic has generated, we feel optimistic that change for the good can occur. The opening salvo has been fired by the 260 pioneers to help nudge the FCC towards a rational conclusion. We anxiously await seeing what will happen next.