FCC's WiFi Rule-Making: Making It Fair For Both Open Source and Proprietary (fcc.gov)
Bruce Perens writes: The FCC wants to be sure that WiFi drivers don't cause interference with airport weather radars, but their proposal to lock down WiFi firmware, won't fly. Many commenters in the proceeding have made it clear that Open Source firmware for WiFi devices must remain legal. While an "alternative" proposal to the FCC that would require that all WiFi routers be Open Source is getting most of the publicity today, I have proposed another alternative that would be fair for both Open Source and proprietary software. It requires approval of the source code of a WiFi driver by a person with a technical license from FCC, the GROL+Radar, if that driver is to be mass-distributed in binary form for use by RF-naïve users by either the manufacturer or Open Source. The license assures that the responsible person actually understands how to protect radar systems in a WiFi driver. It's pretty easy for someone competent in radio engineering to pass the license test, and many thousands of people hold the license today. Vendors and Open Source are treated the same. It doesn't place restrictions on testing and development, or conversion of WiFi equipment to other radio services. And it includes an explanation of the problem, for those of you who don't know what the uproar is about.
Bruce,
Is it your experience that people at the FCC even understand what Open Source is and that not all software is made by some huge entity like Microsoft and Adobe? It seems to be in my travels there are so many people making important decisions on the governmental level that either don't care about the greater Open Source community because of close ties to big corporations or don't have the background to understand why open software is important.
Wow, a reasonable and fair solution for all parties! Yes I read the comment and this is a good compromise solution that would work! So of course it will be rejected out of hand, sad to say ...
Can the FCC point to any specific instances of aircraft radar interference, and especially, instances of interference caused by routers running Open Source software? Or is this another case of a Gov't agency using a bogy man (It's to prevent terrorism, It's for the children, etc) to assert control over a market segment that it didn't previously control.
Wondering which.
Steve
The only proposal so far to actually make sense. No corporate is going to open-source their Wifi code if they haven't already, especially those multi-channel directional systems. And binary- and official-only firmware has obvious problems as well.
This is the proposal to get behind, to reinforce to the FCC in the public consulations. It lets the corporates keep their trade secrets and allows open source firmware to exist at the same time.
Trying to become famous by taking photos. Visit my homepage please.
What exactly does Open Source have to do w/ something being locked down? Are we entering the 'TiVoization' argument again? Open Source simply means that the source code should be made available to the person who has the executables. Nowhere is there the requirement that the customer has to have the capability to actually modify the in-system code.
There are several good reasons to lock down firmware, regardless of where one stands on open source vs closed source. I am generally in favor of open source b'cos it allows an organization to maintain its own software investments, regardless of the status of support by suppliers, and not being forced to migrate on the schedules of suppliers. But for things like firmware, there are several good reasons to lock down firmware, be it providing it on a PROM, or even on a Flash but w/ the device being locked except at the manufacturer's site. Those include things like warranty claims: since your average Grandma or Suzie ain't a coder, leaving the firmware in a condition that they may accidentally alter its contents and make their routers unusable ain't a good idea, and Grandma & Suzie far outnumber your average /. user who may well be able to flash a router w/ DD-WRT or pFsense, and recode it to convert an 802.11g into an 802.11n.
As far as the FCC goes, their proposal to lock down WiFi firmware has nothing to do w/ whether the code in the firmware is FOSS or closed. It just forces WiFi devices to have a limited set of codes that don't muck around w/ air weather RADARs.
What's the best process to add support behind this proposal? At the linked the FCC page it isn't clear to me how I might add support to this proposal as a consumer.
It all starts at 0
Your fcc makes me laugh they ask for stuff and we hide it but it's trivial to change
Are you guys serious ?
If someone is interfering with a licensed station, why doesn't the FCC investigate the source of the interference? In the old days, if you were being a nuisance to a licensed station, you were in for a world of hurt if being intentionally malicious. At the bare minimum, and idiot user would have had their equipment confiscated for being clueless.
Is it too hard for them to actually go out and do the one thing they unquestionably have the authority to do? Or is this just another power grab by the FCC and the administration to quash tech freedom wherever they see fit in the name of "safety".
I've got the relevant licenses. Also amateur radio license KG6IIM
AC (although not that A if you know how to look up amateur radio license callsigns)
The General Radiotelephone Operators License (with Radar endorsement) isn't really the right license. It's an *operators* license for shipboard use, not a designers license, and while the test (20 years ago for me) had some theory, like modern amateur radio licenses, it focuses more on regulatory and installation issues than on design. The radar test had questions about 1/4 wavelength waveguide stubs for TR switches, but not a lot about the kinds of modulations, EMI/EMC issues, etc.
I would suggest, rather, that someone who is licensed as a Professional Engineer might be a better choice for independent review. The PE exam *is* about design and it requires 6 years of engineering experience (as well as references, etc.) to get the license. PE's have professional liability exposure and a variety of laws and regulations to ensure that they consider the public over their customer.
Ultimately, though, this isn't so much an FCC issue as a manufacturing cost issue. Most of the people complaining here want the freedom to modify the *router* part of the software and to consider the radio as a black box. That's counter to modern manufacturing practice: combine everything in one chip, so we can continue to buy $30 WiFi access points.
Hams (who do care about playing with the radio) are up in arms, and claiming "but we won't be able to modify cheap routers for use in ham bands". That's a pretty niche market, and basically a complaint that hams will have to spend a few hundred dollars to experiment with 2.45 GHz radios instead of $20. That, to me, is not a compelling argument. Besides, hams have always scrounged up and modified old gear, and there's plenty of old WRT54s laying around to supply hams for the next 30 years. I fully expect to see articles in QST in 2050 (should I live that long) about "how to restore a 20th century WiFi access point" much as there are articles about repurposing WW2 and Korean war radio equipment today. And they'll be on the 2050 equivalent of eham complaining about these new kids with their 100 GHz links carrying gigabit/second not knowing the real ham radio back when we had 2 Mbps on one channel and thought it was cool. (by then, the guys who pounded brass in the military, or shipboard with their GROL, will have died, so the code vs no-code dispute will have died down)
The only way to ensure the frequencies is to lock the transmitters into a specific frequency set.
software can always be changed - either malicious changes, ignorant changes, or just erroneous changes. The only way to prevent those problems is to have the transmitters themselves locked. The interfaces to those transmitters can then be used in any way desired, proprietary or open source.
FAA is phasing out radar anyway in favor of ADS-B. After 2020 there will be no more radar in the 5GHz band to contend with.
I thought that the issue that the FCC had was that the driver / firmware can be modified. If the stuff is open source even if the original source is approved by someone with a license (which may be problematic as they may not be a code expert), it still doesn't stop an individual from changing the source (something like "powerLevel = PWR_MAX" or setting the software defined radio channel to one that causes interference) and thus invalidating the approval and causing the exact problem the FCC wanted to avoid. So why would this be considered by them to be a workable solution?
Ok, I know nothing about radios, or how wi-fi works, or what the issue is. (Assume for the moment that I'm also unable to use google.)
Clearly though it's a Big Deal. Could someone in the know explain why the necessary restrictions to prevent abuse inherently can't be implemented the hardware, such that the software (open or closed) just can't do whatever it is that's causing the problem?
I imagine the pay to the license holder for certifying would be very low, and the potential costs if there's a vulnerability they'd not discovered would be so high that very few (good) people would be willing to carry out the certification.
Nice, but there is one big problem: FCC does not give a fuck about open source. Manufacturers piss on one source as well. And Mr Perens has zero influence on either of them.
> There are several good reasons to lock down firmware [...] Those include things like warranty claims
Oh, no. *This* tired red herring again. There should be legal impediments to letting your modded hardware (be it a modem, a car or a forklift) out in the wild. The *technical* impediments discussed (be it DRM or whatnot) don't make sense.
Afer all, my good old kitchen knife doesn't come with a hardwired anti-murder device.
And no, Grandma & Suzie ain't going to hack their WIFIs.
It's the usual regulatory overenthusiasm. Basically trying to criminalize perfectly ordinary actions that might lead to actual criminal actions.
You can be penalized for emitting interference in a regulated frequency, or for using a regulated frequency for some other purpose. That is correct, and it is all that is necessary. Whether I my device is interfering because it is a cheap piece of crap, or because it is broken, or because I have flashed it - the reason doesn't matter, the result does. On the other side: if my device isn't interfering, there is no reason for the FCC to care how much I paid for it, whether it is in working condition, or whether I have flashed new firmware.
The bureaucrats need to justify their petty little empires, so they seek new regulations to write.
This is like a "pre-crime" unit: If you flash new firmware, you might be doing so with the intent to misuse spectrum. It's no different from stupid crimes like "structuring" that aren't actually (in a sensible world) crimes at all. They may, in rare cases, be evidence that a crime has been, or will be committed. That is no reason to make them illegal in and of themselves. Did you know that European eggs are illegal in the US, and vice versa? It would be perfectly fine to stick with "don't poison your customer", but that's too simple, and doesn't require enough bureaucrats. So in each case, over-eager bureaucrats have dictated a particular egg-cleaning method, and the two contradict each other.
tl;dr: The FCC needs to concentrate on its actual job. Maybe they should downsize by about 90%, so that they don't have time for dumb ideas.
Enjoy life! This is not a dress rehearsal.
The Friendly Candy Company should just require weather radar to operate in a different band. Like what used to be TV stations. There'll be a lot more available frequencies after the re-pack and conversion to ATSC 3.0 (which makes every TV you have completely useless).
Is it really an issue that radar is or can directly affected by WIFI?
People can already interfere with "airport weather radars" in a variety of ways. What evidence is there that custom WiFi firmware is a problem, and that locking things down would fix this?
Dear Bruce:
...which is why I have tried to initially limit the call to merely opening up the binary blobs going into wifi, particularly as getting the current 802.11ac trends towards doing so have failed so dismally and wifi far less safety critical than many other things.
In your slashdot posting today you mischaracterized our efforts as attempting to "open source" all routers. (as have multiple other reporters and people)
I lost sleep for years trying to create a third not "open source" or "closed source" *option* for making society's safety critical source code *public* vs what is currently buried in inauditable binary blobs - and in this letter, tried to shift the core fcc licensing requirements to mandating that the source code at the lowest layers of the network stack be "public, maintained, and regularly updated".
What license is slapped on this "public" code I totally do not care about - it could mandate you have to sell off your first born child, or slit your throat after reading, for all I care.
I care only that the sources be public, buildable, maintained and updated.
http://www.bufferbloat.net/pro...
Open source and closed source alike have been doing a terrible job of maintenance, and in the embedded market - aside from higher end devices like android and mainline OSes like redhat/ubuntu - are not being updated. That is the *real problem* here that we are trying to solve.
thx in advance for any efforts you might make to correct your messaging, particularly when talking about our efforts! I have been busting my b**ls to make these points with every reporter I've talked to.
Aside from that... I think extremely highly of your characterization of the problem's stakeholders, the quality of your letter is even better than ours overall, and your proposed solution quite possibly one that could succeed (although I would shoot for a new licensing regime that made the git committer more responsible, perhaps - it is very worthy of discussion!)
I am totally willing to discuss restrictions on "how public" things become - and how fast they become so! particularly as I am well aware dismal code quality in many mission and public safety critical pieces of software that is out there. Mandating that all that be made public all at once would induce a terrifying amount of risk to society as a whole, and a staged approach towards making the core blobby bits public would be best.
I would dearly like, also, to fix the dsl drivers and firmware worldwide, at least in part, because I strongly suspect quite a lot of it, in light of snowden's revelations, is compromised already, and they just need 50 lines of code or so, and a firmware update, to eliminate the bufferbloat in them - and verify, it really is doing what the authors say in the tin, to the FCC.
Sincerely,
Dave Taht
lead author, the cerowrt project's letter to the fcc
http://fqcodel.bufferbloat.net...
A single person has a surprisingly limited amount of bandwidth. They would quickly find themselves overwhelmed by the job.
Chas - The one, the only.
THANK GOD!!!
This makes the most sense of all the proposals I've seen. How can we help encourage the FCC to consider this? Is there an email address at the FCC for taking comments (e.g., to encourage it)? I'd like to send a "me too" so that the FCC knows to consider this proposal carefully.
- David A. Wheeler (see my Secure Programming HOWTO)
but their proposal to lock down WiFi firmware, won't fly
Can we have some legislation against people misusing commas instead?
systemd is Roko's Basilisk.
Bruce Peren's suggestion is an interesting one, but I think misses the point of something being open source in the first place.
File under 'M' for 'Manic ranting'
Anything with a link on a website someplace will be considered "mass-distributed" for regulatory purposes. So in effect that would mean that only peer to peer sharing of open source code would be allowed which undermines the whole point of open source.
I think "commercially distributed" might cover it, so that people can't sell software or hardware without certification. But basically I think some simple disclaimer that comes along with the code that indicates that the code is intended for experimental use or research and not for widespread deployment in a production setting. That should allow individuals to utilize the open source code while dissuading enterprise use. But "mass-distributed" is the wrong wording.
What the hell is the FAA doing running a safety critical (so they say) radar system in an ISM band? And why is the FCC defending them?
No license is required to operate within these bands, making the proposal that a person holding a technical license approve router firmware an exception to current policy. Furthermore, equipment using these bands must be tolerant of interference caused by other in-band transmissions.
As far as I can tell, the FAA is violating FCC rules by operating their radar within these bands. The FCC should immediately order them to move to a licensed band and allocate a frequency specifically for this kind of public safety use. And the FCC should order that a person holding a technical license verify the proper design and operation of the radar system. Because whoever set it up initially wsn't smart enough to get it right.
Have gnu, will travel.
That is some serious ignorance. We need dedicated, clear spectrum for modern technology and infrastructure to work.
Based on that, I'd say giving someone your two cents is equivalent to saddling them with a $10K debt.
The real answer to the issue that concerns the FCC is to have the chipset manufacturers add write-once registers that can be used to lockout frequencies and power levels that are illegal in certain regions. That way, the manufacturers can make one hardware design, and still ensure compliance with regional regulations. This is such an easy solution to implement, and would completely eliminate the "need" to DRM the firmware.
--- Generation X: The first generation to have SIG lines inferior to their parents... ---
If source code is on a website, it's not "mass-distributed in binary form." I assume that by "binary form", Mr. Perens meant a form other than "the preferred form of the work for making modifications to it" (GPLv3). And if source code is specifically marked as experimental, it's not "mass-distributed [...] for use by RF-naïve users."
FCC just whacks people that are violating the current laws regarding over powered broadcast and over the air interference instead of locking down the ability to innovate.
it should be the operator that incurs any liability
The legal theory here might be secondary liability for interference with weather radar. If a company profits from an unlawful act (crime or tort) committed by another that it has power to prevent, it has vicarious liability for said other's act. If a company distributes tools that it knows will allow another to commit an unlawful act, it has contributory liability for said other's act.
where else do we have random porn-surfing wackos interfering with a life-safety system?
so don't do it here, either. prohibit the overlap frequencies.
if this is supposed to be a new economy, how come they still want my old fashioned money?
That is so. I hold two different USG RF licenses (old commercial first class with radar endorsement, amateur extra class.) And I blitzed all the tests (there were a series off them in both cases) so yes, not all that difficult for me.
However, the set of people competent to do what was described about must meet the above criteria, and be of the set of programmers that understands exactly how every layer of wifi is supposed to work and the set of programmers that is conversant with data- and code-hiding / obfuscation techniques. I'm a good programmer -- (about 45 continuous years of experience with many types and sizes of successful projects under my belt), and my debugging skills are right up there as well. I'm very good at seeing that vulnerabilities in my code are minimized. I'm also a good EE, and know RF backwards and forwards. Heck, I write some of the most advanced SDR software out there, so I pretty much eat RF for breakfast.
But I wouldn't be competent to do this job because first, I don't have the hiding / obfuscation chops (and the reason I know that is because I'm a good programmer and realize that's a skill in and of itself... :), nor am I intimately familiar with how wifi works at every level (and I also know that becoming so is non-trivial, because I've skimmed some of the specs.)
So this really doesn't sound like much of a "solution" to me. In practical terms, it doesn't seem achievable. I just don't think there is likely to be a pool of qualified persons being available to fill this kind of role. I suspect that for the workings of a router, you will almost always find a team underneath who (more or less) trust each other for some reason(s), and now we're talking about more risk if we, in turn must trust them and only them.
Closed source opens the door for closed attacks from uncheckable sources, like the NSA. And we know the NSA has been doing things outside the law and outside the acceptable constitutional bounds (and some laws are, in fact, also outside acceptable constitutional bounds.)
So open source for all routers seems to me to be a lot better path to follow. If you're going to mandate anything, I'd say it should be the ability to read the binary out of the depths of the various SOCs that are, or will be, at the core of many routers, as well as from the various types of external ROMs, flashable storage and so on for the types of systems that use them.
This means the router code can be compared bit-for-bit against the code we have been told it is running, and any number of people can then have looked at said code, and in such groups we are much more likely to bring together all the skills required: Joe says there's no obfustcated functionality, Larry says the relevant wifi specs are met, Linda says the networking protocols are okay, Fred tells us that the code itself isn't vulnerable to buffer overruns, Shannon tells us that it isn't going to transmit over the FAA's portion of the 5 MHz band, Mergatroid says what he built from the code that's supposed to be in the router matches every bit of what was actually lifted out of the router. (mind you, that's not perfect either, because a really sneaky team [cough, NSA, cough] could design the hardware to read out one set of code while the router runs something else entirely, but any such "prove it's okay" mechanism has those kinds of limits. Although perhaps Beverly who knows silicon foundry stuff and has access to the right kind of microscope and so forth might be so kind as to look at the die under the microscope and perhaps let us know that it doesn't look like there is a primary/spoof code storage mechanism in there. That, I think, would be one very difficult undertaking, but I'll allow for the possibility, anyway.)
Open source's key strength in re "trust" has almost always been, in a nutshell, "more than one person looks at this." Focusing all trust through one person doesn't leverage that.
IMHO
I've fallen off your lawn, and I can't get up.
What if vendor is FCC licensee. The system would fail as now vendor can willfully do anything. Open sourcing the firmware is the only REAL solution.
The problem will be that the bureaucracy will cause 'FCC licensed drivers' to be utterly outdated except for a few proprietary ones because someone could line someones pockets to get it pushed through.
The unlicensed firmware will still be shipped on most cheap routers however since they're coming from China where the FCC has no jurisdiction and the resellers don't care much about import requirements.
Be careful what you wish for if you let a government agency get involved with your plans. Your plans however good will be overburdened with legalese and pork, in the end you'll get a law that is ripe for abuse by those in power and those with money.
Custom electronics and digital signage for your business: www.evcircuits.com
While in fact you can write your own code, do what you like, etc. up to the point of radiating RF isn't really the problem.
As you say, it's the equipment manufacturer who is responsible for the emissions. And the way the law is written, that manufacturer is liable forever, so they, legitimately, need someway to prevent unauthorized folks from modifying their "box" (containing both hardware and software) from violating the law.
It's that the FCC would like to have *something* in place to prevent everybody and their brother from loading that hacked up code into a radio and emitting illegally. This is nothing new: they've always had stuff like "no trivially modifiable circuitry".. originally, it was jumpers or dip switches, then the FCC said, no, that's too easy. Then it's things like reverse polarity connectors. As each "difficult to casually modify" scheme comes along, it's eventually overtaken by events, and the FCC asks for something better.
This is what they are asking for.
The gripe people have is that due to increased integration, cheap hardware that is readily available and used widely has no convenient way to separate "radio stuff" (regulated by FCC) and "network stuff" essentially unregulated.
I imagine that it's workable because it becomes easier to pinpoint an offender: a single user rather than all users of a particular make and model of transmitter.
It's not so much that the PE is per-se the correct license. It already exists, which is convenient. It already has legal aspects of "proper ethical behavior" (do bad things and they take your license away, and for most PEs that means loss of income).
I think the GROL is a bit too easy to get to have significant weight in this thing. You want a "certifying authority" to actually care about what they're certifying: e.g. if they do a disreputable job, they suffer significant consequences. My impression is that most GROL holders don't depend on their GROL for a living (except shipboard radio operators). This unlike back in the days when a 1st class radiotelephone was required for some jobs. Back in the day, you had to have a 1st or 2nd phone to do things like service land mobile radio or CB. Today, it's more about manufacturer certification of technicians (because you have to be manufacturer approved to have access to the service information).
If you look at other radio certifications, you go to a registered test laboratory of some sort. Just as with the PE, they have an incentive not just "certify based on payment", because their continued existence depends on their reputation.
You could just as easily set up some new "WiFi certification" mechanism, with sufficient teeth and consequences for "casual certification". But why do that.. use existing certifications: registered test lab, PE, etc.
i built me a big-ass linear amplifier feeding 2500 watts rf into an array of yagi pringle cantennas on my rooftop. you should see them fuckers glow. shit i can hit my home network from 25 miles out with my cellphone. got tired of them LTE broadband plan charges. suck it verizon.
Even if I had the required licensing, I would not sign off on a code change in this context. I don't think any sane engineer would. As this proposal is stated, how am I protected legally? Would there be a "community benefit" legal waiver for signers?
The first time there's an accident determined to be caused by errant wifi, and they find out who signed off on the radio change, the signer will be held liable. There's no way I'd volunteer my life for that, knowing how the defect could be created by something unrelated to what I approved.
not sure how this fits into this thread, http://nist.gov/el/isd/cs/wpsm...
mfwright@batnet.com
Cell phones, xbox, and other devices have the claim that the device accesses their networks and therefore they must retain control. There is no such argument for a wifi router firmware which is in almost every case 99+% modified open code and 100% the property of the end purchaser.
There is a huge security risk, with radar interference the least of it, and no upside to locking people out of their devices to which the manufacturer has no access right after the point of sale.