Save WiFi

From LibrePlanet
Revision as of 13:45, 11 December 2015 by Cwaid083 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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. #savewifi

Comments have been filed and we are now working on reply comments, which are due November 9, 2015

  • Here are the proposed rules from the NPRM that we are going 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 that want to make changes to their own products, to build custom devices, or to provide custom services will be forced out of the market if they don't use proprietary software or if they are required to pay licensing fees to those who control the DRM signing keys that allow the upgrading of software and firmware on encrypted 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 lose 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
  • EFF, Nate Cardozo

Organizations we want to support this


  • Adam Leibson, KC1EDT
  • Chip Rosenthal, KE5VHV
  • Martin Rothfield, W6MRR


 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. 


These are different NPRMs or discussions which are unrelated but might help us better understand the NPRM we have on hand.

There are also reports of similar rules of concern in other regulatory jurisdictions:

Publicity, News, and Blogs

Media contacts / groups we should contact to get publicity / organizations

  • IEEE Spectrum contacted, they are investigating
  • Off The Hook on Wednesdays at 7PM-8PM EST, contacted them by email, phones have been non-functional for some weeks
  • Linux Action Show, contacted, waiting for reply
  • Bad Voltage, done, unknown URL
  • Hacker Public Radio, scheduled, unknown air date
  • Going [GNU]Linux, contacted, waiting for reply
  • [GNU]Linux Game Cast, contacted, waiting for reply
  • Android Central, need to contact still
  • Knight Wise, contacted, waiting for reply
  • Admin Admin, need to contact still, looks like UK show
  • System AU, need to contact still (overseas show)
  • XDA, need to contact still
  •, contacted, waiting for reply
  •, contacted, waiting for reply
  •, contacted a Peter Biello @ NPR who wrote an article on DHS intimidating a library operating a Tor relay, see if he maybe wants to do a story on this
  • nyt, contacted and waiting for reply

This page was a featured resource in August 2015.