The FCC wants to require device makers to lock down the software and firmware on computers with radio devices (wifi, bluetooth, etc) and we need to stop them.
- Here are the proposed rules from the NPRM that we are goign to comment on: Save_WiFi/Rules
- Here is the list of all specific request for comment the FCC has made in this NPRM: Save_WiFi/RFC
- Here is where we are drafting specific language for our letters and comments to the FCC: Save_WiFi_letter_language
- Here is joint letter we're creating to submit to the FCC on the NPRM: Joint Letter
- Send your comments to the FCC.
- Comment deadline: October 9, 2015
- Reply Comment Deadline: November 9, 2015.
More info
The FCC has proposed rules (ET Docket No. 15-170) that will require device makers with WiFi and other Radio Frequency (RF) devices to cryptographically lock down the RF-controlling software on those devices so as to prevent users from installing the software of their choice. This means not only routers, but also many phones, tablets, laptops, and any number of new devices that are wifi capable would now be required to implement a low level DRM system that prevents users from re-flashing or modifying the operating system and/or firmware on those devices.
We have been fighting for years the unjust laws that serve to protect companies that use DRM to restrict users. This new regulation goes beyond protecting those who use DRM, this would be a law requiring device makers to implement low level DRM technology to restrict users from upgrading the operating system and/or firmware of many devices.
Fortunately, the FCC is accepting public comments on this issue. The deadline for comments is September 8th, so we need to act quickly.[1] Thanks to people from OpenWRT, ThinkPenguin, LibreCMC, and elsewhere, we already have some momentum building around this issue. But we need to come at this problem both singularly and together by growing a coalition that helps spread a more unified message to the FCC as well as encouraging supporters of those organizations and groups to submit comments to the FCC.
Bad precedent for FCC
The FCC is going beyond what is fair or reasonable with these requirements. While their intent is to prevent users from being able to make use of the radio device in ways that violate FCC rules, they have imposed a set of requirements that are far broader reaching than preventing use of the radio device alone.
We should find out: Does the FCC have authority to impose such a broad rule? Are there legal objections we can cite?
How this is bad for individuals and disrupts the market
These regulations are especially oppressive to small companies and to free software developers. Individuals and small companies wanting to make changes to their own products, or want to build custom devices, or provid custom services will not be forced out of the market if they don't wish to use proprietary software or if they will be required to pay licensing fees to those who control the DRM signing keys that allow the upgrading of software and firwmare on the devices.
Talking points
These talking points have been expanded into language which could be used for jointly crafting letters. See: Save WiFi letter language
These are a set of talking points against the proposed rules. Once improved (and verified!), they can be used for crafting communications.
- The rule prevents device owners from fixing their device in a case where the device is transmitting in an illegal manner. Since they are liable for operating a device that is violating the law, their only choice to is to stop using the device.
- The rule prevents security fixes if a router is found to be insecure. This could manifest itself through intentionally created backdoors used for industrial and national espionage.
- Firmware from manufacturers is often full of holes. Security experts recommend installing third-party firmware[2]
- A manufacturer isn't required to provide fixes to the user even if the device is found to be insecure or operating outside of authorization
- Manufacturers will often not patch routers with serious security holes [3]
- Prevents companies from buying US routers and reflashing with custom firmware to then sell or rent to an end user, a somewhat common occurrence.
- Discourages innovation and research in the US in wireless technologies, such as mesh networking
- Community implemented the fq_codel algorithm for eliminating bufferbloat-based network congestion by using a version of OpenWrt [4]. The fixes for this are now in the Linux kernel [5].
- Mesh networking research depends on low-level access and modification of kernel on the router.
- Vendors have not developed mesh networking support; instead it's been done primarily by the community on open and modifiable drivers and firmware/ [6]
- Research into wireless networking requires low-level access to drivers and firmware.
- Nearly 7,200 academic articles related to open drivers and firmware. The research cannot occurred without the ability to modify the device's software.
- (I think) Ham radio operators are allowed to operate at a higher power in portions of the unlicensed spectrum than non-licensed operators. This requirement prevents them from modifying low cost routers for operating long range wifi networks, such as would be useful in a disaster situation.
- The law permits amateur radio operators to increase the transmit power on commercial routers beyond its regular limits, where the wifi frequencies overlap with frequencies. This system works particularly well for emergency communication. See Broadband-Hamnet.
- Broadband-Hamnet uses a mesh networking protocol so this interacts with the issues on innovation
- No FCC complaints about improper usage of routers were related to flashing third-party firmware. Most were related to commercial wifi providers breaking the law. In some cases, the official router web administration for the routers used in the complaint had a UI for operating in an illegal fashion. For example, it was possible to turn off all DFS or allow test operation on all possible channels which are both wildly irresponsible to place in a standard router UI.
- The key problem necessitating the rule change, the need to make sure DFS is running near airports with Terminal-area Doppler Weather Radar (TDWR), is primarily relevant for those operating a wifi router outside within a mile or so of 45 airports in the US.
What this mean for you as a user:
- your choices will be restricted
- you have to stick with the features provided by your router vendor's firmware
- you have to stick with the factory firmware which uses outdated software. you most rely on your router vendor for security fixes
- you will have no way to verify, what's running on your device. you could be under domestic or foreign agencies surveillance
What it means you as a business:
This ruling will force you to spend additional money and resources on:
- locking down all future devices
- locking down all current devices before June 2016
- recertify all current devices before June 2016
- either have special US version of your devices or loose marketshare elsewhere
- this raises serious competition and innovation concerns on the industry
- replacing any GPLv3 Software like Samba because of "Tivoization"
Who is with us?
Organization plus point of contact
- Free Software Foundation, Joshua Gay
- LibreCMC, Bob Call
- OpenWRT, contact?
- American Radio Relay League, Chuck Skolaut or Dan Henderson
- Software Freedom Law Center (SFLC), J.D. Bean
- Telecommunications Industry Association, April Ward (Note: They're against us)
- Note: the rule change also simplifies how a number of pieces of hardware are certified which probably explains their support. Are we sure they're actually in favor of the changes we're opposed to?
- prpl Foundation, Eric Schultz
Organizations we want to support this
Hams
- Adam Leibson, KC1EDT
- Chip Rosenthal, KE5VHV
- Martin Rothfield, W6MRR
Resources
We propose to modify the SDR-related requirements in Part 2 of our rules based in part on the current Commission practices regarding software configuration control. To minimize the potential for unauthorized modification to the software that controls the RF parameters of the device, we propose that grantees must implement well-defined measures to ensure that certified equipment is not capable of operating with RF-controlling software for which it has not been approved.
Related
These are different NPRMs or discussions which are unrelated but might help us better understand the NPRM we have on hand.
News and Blogs