Open Source Software and Regulatory Compliance

Last week, I mentioned the tendency of some parties to drag extraneous issues and personal hobbyhorses into policy debates. This was a throw-away observation, but two issues in the news this week highlight how far it can go. In the Volkswagen case, some interest groups are insisting that auto manufacturers should publish the source code for their automotive control and navigation systems, and a group of Internet engineers are pressing the FCC to force similar disclosures on the part of Wi-Fi chip and home router vendors. The Internet folks cite the VW case as evidence in support of their cause.

The argument for open source in both cases rests on the belief that exposing the code to millions of eyeballs will ultimately make it more secure and just plain better overall. In the VW case, anti-copyright groups such as the Electronic Frontier Foundation are pushing for open source and an end to DMCA anti-circumvention provisions. In the router case, the Internet crowd insists that every piece of code in home routers should be made public, including the radio control part that relates to compliance with FCC regulations:

Not even the small and specialized portion of the firmware that is related to radio operation should be locked down.

This is quite idealistic and may in fact lead to the development of better home routers. But it also permits anyone and everyone to adjust the transmit power levels above FCC-specified levels.  EFF’s demand that all the code in your car should be made available to the public also enables anyone with an itch to hot rod to alter ignition timing, fuel/air ratios, and emission control parameters outside the current legal limits.

So the hackers are effectively asking the FCC and Congress to exempt them from laws and regulations that have been carefully worked out by regulators over the course of decades, because, well, because they have good intentions and want to make cars and routers work better. Part of the argument is that source code inspection can used to verify compliance, but that’s weak. Source code is neither necessary nor sufficient to prove compliance with emission limits. We have external tests for that, even if they need improvement.

In the hackers’ defense, there’s a lot of room for improvement in both cars and home routers. Most of the car issues that I’ve seen don’t relate to the engine controls as much as they do with human interfaces, smartphone integration, navigation, and the softer sides of driving. If I could hack my car, one of the things I’d do is make it stop for red lights and stop signs the way it does when a stopped car is in front of me. I’d then do some other stuff related to iPhone integration, and next I’d overhaul the voice command system which seems to only work for people who are speaking Serbo-Croatian.

And yes, I’d make the code more secure because I don’t want some eager hackers to break in and take over my braking system, even if they’re willing to invest three years in the project.

All of these things can be done without opening up the engine controls to malicious hackers, so I’m suspicious of the motives of any organization that insists that the whole system has to be opened up to entire public, including the criminals. So we can safely scale these demands back a great deal.

The Wi-Fi router issue is similar. Routers aren’t terribly secure, don’t do IPv6 very well, and don’t appear to do DNSSEC at all. DNSSEC isn’t such a big deal because the hard part is handled by the ISPs, but there’s a lot of room for improvement.

I’m skeptical of the letter sent to the FCC in the home router inquiry by a group of Internet insiders insisting on complete freedom to hack routers because it fails to offer a way to ensure compliance, and generally betrays a fairly superficial understanding of Wi-Fi standards, protocols, and development processes. Several of the signatories use Wi-Fi routers that contain code I personally wrote, which reinforces my skepticism.

There’s a project afoot called CeroWrt that aims to make routers run faster, primarily by getting rid of bufferbloat. Bufferbloat degrades TCP performance, but there’s a lot more going on inside Wi-Fi than bufferbloat. Wi-Fi has security issues, power management issues, and an inefficient MAC protocol. CeroWrt aims to correct the first two but does not have a very clear focus on the unhappy marriage between TCP and the Wi-Fi protocols. The goals document for CeroWrt makes some very poorly informed charges about Wi-Fi standards development and doesn’t even date Wi-Fi development’s initiation to the right decade.

Wi-Fi protocols have two big problems that need to be addressed by standards or by alternatives to standard Wi-Fi like LTE-U: poor coordination between Wi-Fi access points on the same channel, and too much dead air time. The CeroWrt design proposes using airtime even more inefficiently in order to make TCP work better:

One core and non-intuitive finding – by Andrew McGregor – that optimizing for best “average” throughput on WiFi is not as effective as optimizing for the best minimum variance in jitter when dealing with TCP – thus those that try for the best bandwidth on UDP, are actually hurting TCP.

This means transmitting at a reduced rate, which consumes more airtime than transmitting at the optimal rate. Killing time, in other words, to make TCP happier. The rationale for this move is quite thin:

[Andrew McGregor] discussed this with Van Jacobson once, and he nodded vigorously through the whole explanation. He also pointed out that anything vaguely resembling TCP will show the same behaviour, including Harald Alvestrand’s congestion control for websockets, SCTP, multipath TCP, QUIC, LEDBAT and many others.

They don’t consider that “hurting TCP” may be preferable to hurting an entire neighborhood by dragging the speed of each router down and extending the time it’s on the air. So I’m not holding my breath while I wait for better Wi-Fi in home routers, but despite this unhealthy fixation on bufferbloat the hackers should be able to make routers more secure and more compliant with IETF standards.

But I don’t want to give them the ability to alter the power levels in these Wi-Fi chips above the maximums established in regulation for each channel in each country. I am also sensitive to the concerns of chip vendors who don’t necessarily want to expose every detail of their queuing algorithms to the prying eyes of the simply curious. There’s a lot of money invested in chip designs, and chips can be reverse engineered from source code pretty easily.

So how do we create a sandbox for eager open source developers without compromising auto safety, pollution standards, and radio emission standards?

It’s not really concerning that the open source people don’t offer a solution because the solution comes from a type of hardware/software interaction that is apparently outside their areas of expertise. We can create the sandbox the hackers want as soon as we can produce some hardware that protects critical controls from modification by downloaded code. This means restricting access to sensitive chip parameters to less trustworthy code but allowing trustworthy code to access them, one time, after power is applied to the chip and before downloaded code is allowed to run.

That means setting-up the sensitive parameters and then locking them down before CeroWrt or its automotive equivalents are executed. This is something that hardware has been able to to for several decades; Dave Farber and I discussed it (“security rings”) on our first podcast.

But this will not allow hackers to re-program power controls in legacy home routers. The old stuff will need to be replaced before hacker perfection can come in.

The desire of hackers to redesign Wi-Fi protocols is commendable in its own right. They may not have the skills to get a redesign right, but I’d be happy to see them try. It will provide some good data on an old dilemma: Does TCP work poorly over Wi-Fi because Wi-Fi is weak or because TCP is poorly conceived? Or do both need to be redesigned into a more comprehensive wireless solution? And if the latter is true, where’s the design?

This is multi-year project according to the organizers, so no option should be off the table. In the meantime, let’s stick to emissions testing for regulatory compliance. The open source demands are more of long-term project that needs hardware support to get off the ground; it is not a pretext for abandoning patents and copyright.