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.
You know what source code is open to criminals? The encryption libraries used by almost every Internet server in the world.
You cannot limitlessly turn up radio power in a router because it will distort the signal and jam the devices it is trying to receive from and overheat the chips. There is a router that allowed radio signal levels to be adjusted and hackers found these limits on their own.
Cars will not run well with more than minor tweaks to fuel delivery and timing unless there is other changes to the intake and exhaust system. And really carful tunning would be needed. Diesel engines are an exception in that blindly increasing the amount of fuel will give you a noticeable increase in power up to a point. But the diesel community already has the ability to override the factory programming in trucks.
Long before you distort the signal so much that your system doesn’t work you create problems for others. That’s why we have xmit power level limits.
We are “toe dancing” around the problem.
We demand that our food is pure and our drugs are safe and effective. Digital programs and the IoT [internet of things] has, or is, becoming the 21st century analog of food and drugs. Even with “trade secret” products such as cocoa-cola we do not allow “secret” ingredients, so why should critical control programs, particularity those involving emissions, vehicles, medical devices, etc. be treated as a “secret sauce.”
As a specific solution to the specific problem of integrated computer vehicle control systems [drive by wire] including emissions, braking, and suspension/accident avoidance, it would appear to be well within the pervue of existing regulations to require that a copy of the entire source code as well as the compiled program be on file with the appropriate regulatory agency such that: (a) the source code can be analyzed for “defeat” subroutines, and generally analyzed to determine that it has at least minimal “fitness for use” such as no possibility of unintended/uncontrolled acceleration [e. g. Toyota]; and (b) the compiled control code from the supplied source code such at low cost field/spot checks can be made by comparing the PROM code in the vehicle with the “official” compiled code, analagous to the verification that approved/suitable tires are being used on new vehicles,and that existing vehicles have not been “chipped” by their owners for better performance, and/or fuel economy at the cost of emissions. Trucking companies should be of particular concern as a small increase in MPG can result in tens to hundreds of thousands of dollars “extra” profit, and many crimes are committed for far less.
How much liability are you willing to accept in return for access to source code that can be hacked in such a way that the vehicle no longer conforms to regulations?
I think that’s a key question.
Whether or not TCP is poorly conceived, it is the universal standard. Replacing it for WiFi would require a large pile of compatibility shims and code rework across an incredible range of programs and products. Do you really think that’s possible? Look at how long it’s taking to get IPv6 in more than niche use.
Sooner or later, TCP/IP will be replaced, because no technology lives forever and there are big problems to address. So it’s a question of when, not if.
It appears as though my comment has been held for review, probably due to containing links. This one is without links. Please feel free to delete this version and add the other.
…
Dear Richard:
Thank you very much for actually doing something of an in depth analysis of the letter to
the FCC and our proposed solutions for, among other things, improving network security, and making wifi much better.
It
will take quite a bit of time to unpack all you said above, but in
terms of factual corrections (such as the actual inception date of wifi –
which I date mostly to the fairly common arrival of 802.11 and more
fully put at 802.11b as to when things settled down for interop) or
making suggestions to the ongoing make-wifi-fast project, the design and
engineering document IS public, and available for your and your
readership’s direct comments on it via the letter to the fcc’s footnote 19.
Which it appears you have commented on already – on oct 20. We were kind of busy that day. 🙂
I have answered your comments there.
Most
of the technical problems with wifi, particularly in the linux stack,
we’ve identified and intend to fix are in that document.
As another note:
The
CeroWrt project effectively ended 2 years ago, and fixed bufferbloat on
dsl, cable, ethernet, fiber, and other isochronous transports. The
fq_codel algorithm is now a quite common shaper/fq/aqm/QoS system in
modern linux based software, and the standardization process in the ietf
is nearly complete. Another similar aqm algorithm, called pie, is now
the standard for docsis 3.1.
Fixing bufferbloat worldwide is not a hobby project. It
consists of hundreds of researchers, developers, and engineers, with hundreds of research papers
published on it in the 5 years of it’s existence.
We have (as
part of make-wifi-fast) been working on applying similar algorithms to “fq_codel” to
wifi, and we are *well aware*, as you will see from the document above,
of many of the other problems wifi has. We do think, however, that with
everyone working together, on all these problems! we can make wifi a lot
better. If you would like to engage us with your experience and
expertise, please join the make-wifi-fast list and for the fcc related discussion bufferbloat-fcc-discuss.
I agree development of what became 802.11 started in 1989, however, first widescale deployments of mostly non-interoperable stuff were not in the later 90s. Also, in that document we discuss airtime fairness as being extremely key to making wifi work better.
I would suggest that the IETF proposal to require regulatory-critical code be publicly inspectable is *dependant* on patent and copyright. Patent and copyright law protect the owners of publicly revealed inventions and publications against copying by others, and are absolutely necessary if the FCC wishes to require safety- or regulatory-critical code be reviewable. Making code publicly available has been critically important to the cryptographic community, where peer review is arguably the best way to find errors. Without copyright, cryptographers and wi-fi engineers would have to depend on trade secret law and perhaps the technical protections of the DMCA, and so suffer a far higher risk that their products would either fail, or break the law.
I think you’re conflating two functions that drivers perform, the low-level radio control functions that have regulatory implications and the higher-level queue management, aggregate construction, and retransmission functions. The former has traditionally be offered to the FOSS community as a binary blob – the Atheros HAL – and the latter is dependent on chip vendors’ willingness to document chip capabilities. IETF can demand all the documentation it wants, but it’s up to the chip vendors to decide how much they want to share.
The decision about protecting chip design with patent or with trade secret is one for the creators to make, not standards bodies and FOSS collectives. There are good arguments for both sides, of course. Patent protection doesn’t always provide a very productive means of protection since it requires litigation that can be very costly. It’s good for me because I work as an expert witness in some of these cases, but it’s not so good for small companies who aren’t sitting on oceans of cash as Google and Apple are.
Let’s unpack: “But it also permits anyone and everyone to adjust the transmit power levels above FCC-specified levels.”
This is a pointless point. All someone has to do, today, to adjust power above FCC levels is:
A) use the wrong country code in the setup of the router.
or
B) attach a higher gain antenna than specified. E.g. a pringles can or perhaps something more advanced.
For many, many years now, there has existed a signed, frequently updated, full database of worldwide power, and other wifi regulatory constraints, with standard software, which is widely used in most linux based software. (I’d link to it, but that would require your approval)
A more complex point is how to ensure wifi radios adhere to DFS regulations or use only allowed frequencies, both of which are handled by the above, also.
I certainly agree, that despite having this software with a simple, verifiable API, that *actual testing* of the hardware, that the values written into the radios’ registers result in the actual result desired, is needed.
Good comments, Dave. I’ll post a detailed response shortly.
OK, it’s a fact that a user can change out the antenna on a Wi-Fi access point or alter the country, but if she does that and creates harmful interference for a licensed service, the user can be held legally responsible; so the same standard applies to a developer who alters the code in a way that transmits excess power, right? As long as FOSS developers are willing to sign their work and be held accountable for all the interference they may create, I suppose there’s not a problem. But the fines can be burdensome, which might discourage some innovation.
It seems to me that barriers to unlawful operation benefit the developer community.
Your arguments are ridicules. We don’t need these restrictions in the first place and multiple issues that are at the crux of the problem didn’t even exist prior to this past year. This isn’t an “open source” battle. It’s a security and privacy battle. Nobody is calling for ‘open sourcing’ anything even. The call is to require that the code be made publicly available. There is no specific licenses attached and if the code is not “open source” or available under free software licenses then it would need to be maintained and fixed by the manufacturer.
There are all sorts of groups involved and most utilize copyright. It’s ingenious to call the EFF an anti-copyright group too. I mean really? The EFF utilizes copyrights itself as do many of the others. If your portraying us as all “open source” fanatics then you fail to understand copyright. Free Software licenses utilize copyright to *require* the release of code. And the EFF is at its heart a group that has an interest in the protection of the rights of us all, not just some select special interest group which wants to grow its parties financial interests.
The only thing endangering us is the lack of publicly available code because the people with the abilities to spot and fix mistakes can’t. The ‘hackers’ who are out to act maliciously can so with or without access to the code, but those experts who want to fix the bugs can’t do so without said publicly available code.
And last copyright was created for the supposed benefit of the arts and sciences. Not for the benefit of corporate and private interests. Copyright today does not do what it was suppose to do when it was created and we should seriously consider its harmful impact that its had. There are arguments to be had that the only justifiable copyright today should be severely limited to works in the public interest. That is to say it would be to protect code that was made freely available for public benefit such that it could not be closed up by downstream parties for financial gain. None of this mean you can’t profit off that code. I merely means the code must be freely distributed and you can’t take advantage of upstream authors good deeds and intents.
Sorry, but the power level restrictions are necessary not only to make Wi-Fi compatible with other applications that share spectrum with it, they’re essential for Wi-Fi to work properly in its own right because they limit propagation. The Wi-Fi MAC protocol has very precise timing.
Thanks, I’ve made a few additional comments on the Google doc. Let me be clear that I’m not opposed to your efforts to make a better fit between Wi-Fi and TCP, but I would suggest you can do a lot of good by tinkering with TCP. Wi-Fi has a very flexible MAC protocol that’s easily tweakable already.