Hacker News Reader

I agree that the FCC is concerned—as to some devices, in its present rules and guidance, and as to all certified equipment, in the proposed rules I mentioned in another comment—only with software that can affect radio compliance characteristics.

For many devices, however, the practical result is likely to be the same as an outright prohibition on software modifications. Manufacturers of devices for which there is limited market demand for compatibility with third-party software have few incentives to incur the extra costs and certification risks of designs that provide for tamper resistance only where required, rather than for the software and firmware as a whole.

The situation in Verizon is distinguishable because the handsets involved were already designed to support third-party applications with limited privileges, and also because Verizon was a Block C licensee with network access obligations, not an equipment grantee.

The software would not be preventing non-approved transmitter behavior if the software supported the loading of custom firmware that can implement non-approved transmitter behavior. Here is the full paragraph from which you quoted:

  Manufacturers must implement security features in any digitally
  modulated devices capable of operating in any of the U-NII bands, so
  that third parties are not able to reprogram the device to operate
  outside the parameters for which the device was certified. The
  software must prevent the user from operating the transmitter with
  operating frequencies, output power, modulation types or other radio
  frequency parameters outside those that were approved for the device.
  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 and must describe the
  methods in their application for equipment authorization.

Thanks for the analysis. We shouldn't treat the baseband CPU code any differently than the user OS. Inherently we loose software control of one of CPU's, often with DMA, and arguably the radio is the the most important hardware.

For cost-saving reasons, on most WiFi access points the radio is part of the main SoC and is controlled by code running on the main CPU. So it's going to mean an end to router firmware modding in practice.

But that's not the FCC's problem.

Regulators who don't take into account possible unintended consequences of their regulations should be stripped of regulatory authority.

Because they are OMNISCIENT and can foresee every possible unintended consequence right?

You don't have to be omniscient to realize an action might have a consequence that wasn't intended. I don't go 100MPH on city roads because I don't have to be omniscient to realize I might end up killing someone even if I don't intend to.

So OF COURSE regulators should consider ways in which their reulations might cause unintended harm. This is a major reason why US Federal regulators almost all have mandatory public comment periods -- third parties might be able to point out some of these unintended consequences. Regulators might not always make the right decision, but they should at least be making informed decisions.

The attitude should be "We considered that possible outcome and the benefits outweigh the harms (or not)", rather than GP's "well that shitty outcome sucks, but guess what? Not my problem".

I honestly cannot believe the idea that regulators should be considering both positive intended and negative unintended consequences of regulations is controversial.