IEEE Computing Now, Oct. 1 – by Eric Schultz, prpl Foundation Community Manager
Over the last few weeks a discussion has flourished over the FCC’s Notification of Proposed Rule Making (NPRM) on modular transmitters and electronic labels for wireless devices. Some folks have felt that the phrasing has been too Chicken-Little-like and that the FCC’s proposal doesn’t affect the ability to install free, libre or open source operating system. The FCC in fact says their proposal has no effect on open source operating systems or open source in general. The FCC is undoubtedly wrong.
I want to make something entirely clear: I believe the FCC has the best of intentions. I believe they want to protect the radio spectrum and implement the E-LABEL Act as required by Congress. I believe they want to protect innovation in the technology industry. I also believe that their proposal harms innovation, endangers the free, libre and open source community and is generally anti-user.
Just the basics
Before we get into the exact regulations, it’s important to understand some background material. The FCC exists in part to provide rules and regulations for managing the radio spectrum. Since the spectrum is a finite resource, the FCC acts as the referee to try to make sure all users can use the spectrum for communication and experimentation. While difficult, the FCC manages the needs of different classes of users, such as amateur radio operators, unlicensed users (like for Wi-Fi, Bluetooth, NFC, etc.), commercial operators, armed forces and safety personnel, and air traffic control. Each of these classes of users has a right to operate in particular areas of the radio spectrum as long as they behave in an appropriate manner.
The rules on appropriate usage vary by class but they mostly relate to making sure users aren’t operating in a way which prevents other users from using the spectrum. As an example, users may be limited to a certain power-level in order to guarantee their transmissions only cover a small area. In the case of Wi-Fi users, the power of the transmission is limited to a small amount. While it varies by band and channel, in all cases the allowed transmission power for a Wi-Fi device is no more than 1 watt.
What happens though if a number of people were to violate these rules and run their Wi-Fi network at a much higher power level, say 1 kilowatt or 1000 times more power? In the event the users had the hardware to support this, this network would have an extreme range. At first blush that sounds great, but there’s a problem. Remember: the radio spectrum is a finite resource. In the case of 2.4 GHz Wi-Fi, there are under 14 channels and, in the US, only 11 channels are effectively legal and only three are not overlapping. Each channel can have more than one Wi-Fi network on it but the bandwidth must be shared between the networks. If multiple networks were running at 1 kilowatt, none of the networks would be usable since there’d be potentially dozens of networks on each channel. By keeping wattage low and the range of Wi-Fi networks small, the spectrum can be more easily shared.
While regulating users helps protect the spectrum, imagine if the devices themselves caused interference. For example, let’s say your router in its default setup occasionally started transmitting unexpectedly at 1 kilowatt. This lack of reliability would have many of the same effects of users intentionally operating at 1 kilowatt. More importantly users may only operate devices in the manner in which the user is authorized. If the device may only be operated at say 1 watt and it instead operates at 1 kilowatt, the user is operating “outside of authorization” even if they don’t intend to do so. While the FCC may take intent into consideration when assessing penalties, they are not required to do so. Additionally, penalties for operating outside of authorization can be quite substantial. Since the user can be held liable for this, making sure devices are reliable is important.
In order to protect users and the spectrum from unintended damages, the FCC requires all devices sold in the US meet certain standards to assure reliability. This is called “equipment authorization.” During the equipment authorization process, the manufacturer must submit information about the device to the FCC, or someone working on their behalf. In many cases, an independent laboratory must test the device to ensure unintended, unauthorized transmission doesn’t occur. If the manufacturer does not receive equipment authorization, the device may not be sold in the US.
What is a “device” anyway?
When we use the word device in the context of equipment authorization, it’s important to know the term “device” is a little broader than developer parlance. In the terms of the FCC and wireless radios, the term device includes the hardware used for making the wireless transmission, primarily the wireless radio, as well as any software which can control aspects of the radio transmission such as frequency, transmission power, type of transmission, etc. This is implied by the rule at 47 CFR 15.407(i).
How does an operating system kernel interact with a wireless radio?
While the particular interaction varies by operating system, many of them follow a design somewhat similar to the Linux kernel. In the Linux kernel, there is a wireless subsystem which manages all the wireless radios on the system. Each one of these radios has a driver specific to the model of radio. The driver acts as a layer for translating the structures in the kernel for using the wireless radio into the structures expected by the wireless radio firmware. The wireless driver API requires every driver implement a set of functions which include getting and setting the transmission power, changing the channel, finding new access points and others.
While the drivers are unique to the radio, Linux in particular provides shared implementations of common wireless radio driver functionality. As an example, regulatory subsystem interacts with a shared implementation for properly managing regulatory rules for different countries, such as which channels are available, how much power is allowed, etc. Drivers don’t have to use the shared implementation. However, in most cases they’d then have to reimplement that functionality on their own. In the case of a driver using the shared implementation, the driver would verify with the regulatory subsystem that a change to the transmission power is legally allowed in the current regulatory domain (A regulatory domain represents a geographic area with a set of legally mandated rules for radio transmissions. For example, the US would be a regulatory domain while Canada is another.) If the regulatory subsystem says the increase in transmission power is not allowed within the regulatory domain, the driver would reject the request for the change, signal an error and not pass it along to the firmware.
As mentioned previously, the driver interacts with the wireless radio firmware. Firmware is the software created by the wireless radio manufacturer that makes the commands and receives responses to the physical wireless radio. It may be free and open source software such as the firmware for Ath9k-htc but in many cases is not. Wireless radio firmware is OS agnostic. The exact functionality and the design of the firmware is very dependent on the design of the physical wireless radio.
How much of the software is included in the term “device?”
It’s not entirely clear. That said, the FCC seems to interpret software control rather broadly. In the FCC’s interpretation, the firmware is undoubtedly part of the device. The driver is also likely part of the device. In fact, in 2007, the method of protecting the regulatory domain information in the Linux kernel which passes information to the driver was relevant to the FCC’s regulation of devices. Additionally, the FCC’s implemented rules on U-NII (see more below) require manufacturers to explain how they’re preventing the flashing of third party software onto the device and uses DD-WRT as an example. This implies that the FCC’s powers to regulate the software that controls a wireless radio are rather broad.
So what parts of the NPRM should we actually be worried about?
There are two areas which the NPRM is concerning: banning modifications of software control of the device and banning modification of the electronic label.
What parts of the NPRM ban modification of software control?
2.1033 Application for grant of certification. Paragraph 4(i) which reads:
For devices including modular transmitters which are software defined radios and use software to control the radio or other parameters subject to the Commission’s rules, the description must include details of the equipment’s capabilities for software modification and upgradeability, including all frequency bands, power levels, modulation types, or other modes of operation for which the device is designed to operate, whether or not the device will be initially marketed with all modes enabled. The description must state which parties will be authorized to make software changes (e.g., the grantee, wireless service providers, other authorized parties) and the software controls that are provided to prevent unauthorized parties from enabling different modes of operation. Manufacturers must describe the methods used in the device to secure the software in their application for equipment authorization and must include a high level operational description or flow diagram of the software that controls the radio frequency operating parameters. The applicant must provide an attestation that only permissible modes of operation may be selected by a user.
2.1042 Certified modular transmitters. Paragraph (8)(e) which reads:
Manufacturers of any radio including certified modular transmitters which includes a software defined radio must take steps to ensure that only software that has been approved with a particular radio can be loaded into that radio. The software must not allow the installers or end-user to operate the transmitter with operating frequencies, output power, modulation types or other radio frequency parameters outside those that were approved. Manufacturers may use means including, but not limited to the use of a private network that allows only authenticated users to download software, electronic signatures in software or coding in hardware that is decoded by software to verify that new software can be legally loaded into a device to meet these requirements.
Wait, what’s a modular transmitter?
It’s a legal definition for an approved wireless radio which can be added to another piece of hardware in such a way that doesn’t mean the combined hardware needs a new approval. Think of it like an add-on in software.
Okay, that sounds a little like they’re recommending Digital “Rights” Management (DRM).
Sure does.
So why does this mean you can’t install your own OS?
Remember a device includes the software which controls radio frequency parameters. In the case of Linux, radio frequency parameters are controlled in drivers which are part of the kernel. The only way to guarantee that a third party outside of the manufacturer’s control, which includes the user who owns the device, can’t modify these parameters is to prevent unauthorized modification and replacement of the driver which is in the kernel. And remember, in Linux the driver may use shared functionality inside the kernel. So how do you do that without restricting modifications to the operating system itself?
Are you sure this interpretation is correct?
Pretty sure. Routers which implement similar rules for U-NII devices already are locking down their devices. It’s the simplest and clearest way to guarantee the device meet the requirements for FCC authorization.
A number of people involved in open source software and digital freedom have stated that this interpretation is likely correct. These include lawyers from the Electronic Frontier Foundation, the Free Software Foundation, software developers involved in working in OpenWrt/LIbreCMC and CeroWrt and management impacted companies such as Qualcomm and ThinkPenguin.
Note: organizations included for identification purposes only.
Could companies design hardware that would allow modification?
Maybe, but they probably won’t. There’s minimal advantage to them in doing so, and the easiest method of ensuring the rules are followed is to simply prevent modification. After all, they’ll have to rewrite drivers, redesign firmware and create new wireless radios with the hope that the design they’ve come up with will meet the requirements of the FCC. If you’re rushing to market to beat your competitors, why not just take the easiest method and lock everything down?
Possible other interpretations
What if the driver and firmware had to be signed to prevent modification? That wouldn’t be so bad would it?
(In this case we’re assuming the driver and firmware are the only parts of software that are considered part of the device.)
It actually would. Drivers created by hardware manufacturers often only support financially valuable functionality. In particular, while they support the standard Wi-Fi functionality, they may not have support for advanced scenarios. As an example, mesh networking support is rarely included in official drivers since it’s not a common use case. Communities of developers have worked together to build high quality mesh networking implementations into open source Linux drivers. These drivers are used to create mesh networking for expanding internet access to low-income communities and used for data communication by amateur radio operators responding to natural disasters.
Additionally, the ability to experiment with drivers is vital to academic research into wireless technologies. Nearly 7,200 scholarly articles on wireless networking technologies reference a particular brand of open and modifiable hardware which would be banned under these rules.
Alright, but what if only the firmware is part of the device?
(In this case we’re assuming the firmware is the only parts of software that are considered part of the device.)
A number of important innovations in wireless research depend on access to the firmware. User-access to firmware source code has led to bug fixes, security enhancements, and features that were not part of the original code base. In one instance a user was able to fix a critical bug impacting all Wi-Fi adapters based on a particular set of Qualcomm Atheros wireless chipset(s). As users were frequently being disconnected under certain conditions one user took it upon himself to track down and fix the bug http://lists.infradead.org/pipermail/ath9k_htc_fw/2014-April/000388.html. This bug was then submitted to QCA to be considered for inclusion in their firmware which is shipped to millions of people. This would not have been possible had the source code for the firmware been unavailable, or had these devices otherwise been locked.
This only affects routers right?
No it affects anything that includes a modular transmitter. This potentially could affect computers, phones, routers… anything.
E-LABEL Act
What’s the E-LABEL Act?
The E-LABEL Act seems like a well-meaning act of Congress to require that the FCC create rules that allow the certificate of conformance for an authorized device to be displayed on screen.
Certificate of conformance?
Every device has gone through and been approved through the equipment authorization process must include a Certificate of Conformance when sold to the end user. One of those pieces of paper you probably recycle after you open the device’s box, the Certificate of Conformance lists information about the device’s authorization and approval as well as some related FCC rules. The law says the equipment manufacturer must provide you with the certificate of conformance when you get the device.
So what’s the problem with making that electronic?
Nothing, it sounds like a good idea to me.
Then what’s wrong with the NPRM?
The NPRM includes 2.935 Electronic labeling of radiofrequency devices, paragraph (d) which reads:
(d) The necessary label information must be programmed by the responsible party and must be secured in such a manner that third-parties cannot modify it.
What does it mean to “secure” the “necessary label information” against modification?
It’s unclear. One potential example of compliance is to have the information written at the factory on write-once ROM to be read out when the software asks for it to be displayed. This wouldn’t inherently imply that any sort of restriction on modification to the software is required.
So we’re cool, right?
That’s only if the manufacturer chooses to implement it that way. The manufacturer could put the information on the main storage medium and then lock down the device to prevent modification. That’s quite possibly cheaper.
Additionally, it seems unclear to me how this rule would make sure the label information is always accessible. Let’s say the label information is viewable on an Android device from the settings menu. Does the manufacturer have to make sure that the device isn’t reflashed so that the label information can’t be removed from the menu? I really don’t know, but I think this could be possible.
U-NII rules
One topic that relates to the NPRM are rules which have begun to be enforced related to U-NII devices, primarily wireless routers.
What is U-NII?
Unlicensed National Information Infrastructure. The short answer is U-NII devices are devices for unlicensed users operating in the 5 GHz band, which is required by the 802.11ac standard and supported by 802.11n. Most routers are U-NII devices.
How does this relate to the NPRM?
The U-NII rules already require device manufacturers prevent modifications of U-NII devices and we know how they’ve been implemented. Since the U-NII rules are defined similar to the rules in the NPRM, we can assume that the implementation will be similar.
Wait, what are these U-NII rules?
The FCC’s application for authorization of a U-NII requires a manufacturer describe the overall security measures and systems that ensure that:
- Only properly authenticated software is loaded and operating the device, and
- The device is not easily modified with RF parameters outside of the authorization
Additionally, in the application, one of the questions which must be answered by the manufacturer is:
What prevents third parties from loading non-US versions of the software/firmware on the device? Describe in detail how the device is protected from “flashing” and the installation of third-party firmware such as DD-WRT.
Whoa, you mean I can’t install OpenWrt under the U-NII rules?
Generally no. You could if the manufacturer created a signed fork of OpenWrt. If it’s made by the OpenWrt project or if you made it yourself, the rules specifically prohibit that.
Are you sure that router companies would ban all modification of the device?
Yes. There are numerous examples of companies which have done just that in order to get their new devices approved.
These U-NII rules are serious; why aren’t we fighting them?
The problem is the U-NII rules are in place already. This makes them much more difficult to address. The NPRM is simply a notice that the FCC wants to make rules but they haven’t finalized anything. If we can make clear that the DRM aspects of the NPRM are unacceptable then we’ll have a stronger claim to change the U-NII rules.
Arguments against stopping the NPRM
A number of arguments have come up regarding the NPRM. I’d like to discuss them in turn.
“The FCC spokesperson says this doesn’t have an effect on open source software.”
It doesn’t matter what the FCC’s spokesperson says; it matters what the proposed rules say. Taking into consideration the wording of the proposals, the breadth of current rules and the design of hardware and software, the proposed rules have a potentially disastrous effect on the ability of users to control their devices. I believe users who want to install open source operating systems will be at the whim of device makers even if they want to operate fully within the law.
I want to make very clear: I think don’t the folks at the FCC mean harm to anyone or any use case. They’re just not seeing the full picture of what they’re proposing and what rules already exist.
“You just want people to ignore FCC regulations and operate in an illegal manner!”
I actually don’t. I think the FCC rules on power output, frequencies available, etc. are important and should be obeyed. Additionally, I believe the FCC should fairly and equally punish those who willfully make decisions that lead to them operating outside of authorization. These rules exist for very good reasons and we should follow them.
“But if the FCC doesn’t prevent modifications, people are going to accidentally break the rules!”
That can only happen if the software already on the device is so poorly designed that a user wouldn’t know that they’re at risk of breaking the rules. The shipped software on the device should not, under any circumstances, allow the user to put the device into an unauthorized state from a user interface.
Additionally, a warning could be displayed if a user attempts to install a custom operating system. This warning could tell the user that they’re installing unverified software and that there’s no assurance that the device will operate in a legal manner. In such a case the user is taking their “life” into their own hands.
“The only way to guarantee that no one will break the rules is to require manufacturers to prevent the users from modifying the device.”
No method will be 100% effective at preventing people with bad intentions from violating the law. Even if the proposed NPRM rules are implemented, we’d still have the billions of modifiable devices that already exist. Users would still be allowed to import devices from other countries for their own modifications (although companies may choose to lock down everywhere to lower design costs). And bad actors could still create transmitters from scratch for a few hundred dollars that interfere with law-abiding citizens.
We’re not debating a proposal that’s guaranteed to fix a problem versus one that isn’t. These are proposals which make certain behaviors more or less likely.
“Users aren’t responsible enough to be allowed to modify their devices.”
I firmly and respectfully disagree. The user always knows their life better than anyone else. Linux exists because users could modify their device. OpenWrt exists because users could modify their device. CyanogenMod exists because users could modify their device. Ultimately, a software community which believes users are fundamentally unqualified is a broken community. I trust users to take responsibility for their own actions.
There will always be bad actors, but even so there already existed a system to reduce the problems to a manageable level, and the recent rules won’t stop those whom are determined to break the rules/cause interference from doing so.
“So you’re saying nothing should happen?”
I believe the most effective way to reduce the small number of instances where users are modifying their devices AND breaking the law is to discourage the law breaking through social norms. We need users to understand the harm that can come from disobeying regulatory rules and that we as a community do not support their actions. Additionally, the FCC should address this law breaking through firm and fair enforcement actions. Violators can receive fines of $20,000 or more and those fines should continue, particularly for willful violations.
This effort should be inspired by the fight against drunk driving. Over the past 30 years, drunk driving deaths have decreased 60%. Much of the effect came from influencing drivers through education and changing social norms. These social changes were reinforced by increased penalties for drunk driving offenses. Most notably, this decrease did not require extreme restrictions on the freedom of law abiding drivers, such as mandatory breathalyzers in every car.
Next Steps
As we move forward, there are two things we can do to protect the rights of users to control the devices they own.
We can speak out
You need to contact the FCC and tell them that you value the ability to control your devices. Tell them you feel their NPRM is dangerous and overly broad. Tell them you care about protecting the wireless spectrum, but not at the expense of law abiding citizens. Tell them you believe there’s a better way.
We organize to self-regulate
As mentioned before, I believe social change in the technology community will be extremely effective at protecting the spectrum while still allowing the ability of users and companies to experiment and innovate. Over the next few weeks, I propose we formalize a coalition based on the following principles:
- We support the continued ability of users and researchers to control all the software on their devices for all legal purposes.
- We will not create software to intentionally violate the rules of any regulatory domain.
- We will not precompile base images containing a user interface allowing violations of the rules of the regulatory domain for which it is created.
- We will not include source code in our public source code repositories which allow users to trivially violate regulatory domain rules.
- As technologically feasible, we will warn users attempting to modify the software controlling radio operating characteristics that they are responsible for their actions and that those actions could violate regulatory domain rules.
- We will educate users on the potential legal and safety dangers of modifying the software controlling radio operating characteristics.
- We will not provide assistance to members of the community attempting to violate regulatory rules and will actively discourage members of the community attempting to do so.
- We will serve as forum for education and collaboration between regulatory agencies, industry, FLOSS and proprietary software developers, and users.
Every member of this coalition should commit to behaving in accordance to these principles. If you agree with these principles and want to work together to improve our community, please email me at [email protected], post a comment below or join the Save Wi-Fi email list at http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/fcc.