2 ms·

I think it's a gray area. If I'm not grossly mistaken, only worst case radio performances are tested and documented, and the rest of required technical document

I think it's a gray area. If I'm not grossly mistaken, only worst case radio performances are tested and documented, and the rest of required technical documents are more of rather detailed brochures like high level block diagrams and theory of operations than modern full design documents like PCB manufacturing files and firmware build scripts. They hardly acknowledge existence of firmware. And there is at least one good reason: certified and unlicensed radio equipment, like Wi-Fi(or unlike HAM) are expected to be tamper resistant, for public good. And so last time FCC discussed certification requirements for Wi-Fi routers, they naturally considered extending it to software in form of mandatory Secure Boot - for every ultra vulnerable garbage Wi-Fi routers! That was a horrible idea and was scrapped. For now, I think, IANAL, this is semi-legal or semi-illegal unless resulting firmware clearly generates out-of-spec emissions.

AnthonyMouse 2y ago
> And there is at least one good reason: certified and unlicensed radio equipment, like Wi-Fi(or unlike HAM) are expected to be tamper resistant, for public good. This is such an own-goal. The way manufacturers implement this is by locking out third party firmware. Then the device goes out of support a decade before people stop using it, but because nobody else can update it either -- and the manufacturer has higher internal support costs because there is no community submitting patches they could just adopt and ship -- the device gets full of public unpatched security vulnerabilities. Which at scale is a significant threat to national security. On top of losing whatever other benefits the public would derive from the community being able to fix firmware bugs or add features. Meanwhile the purpose of the requirement is supposed to be to keep users from modifying the radio parameters to exceed regulatory limits. Which, first of all, hardly anybody is going to do anyway, because the vast majority of people don't even know how and most of the remainder aren't interested in risking huge fines just to avoid buying a second access point. But the people who are going to do it, because the devices don't get patched, can just use the vulnerabilities to root them and then modify the radio parameters anyway. Which makes it a pointless rule that compromises the public good.
- numpad0 2y ago
  What you've said is why a lot of people voiced concerns to that suggested changes, leading to it getting safely cancelled, while the same cohort of people were and are fine with existing anti-tamper requirements. I guess it's another anecdotal datapoint that shows disastrous state of the field called software engineering, especially relative to other professional fields of engineering(cf. https://xkcd.com/2030/ https://xkcd.com/2030/).
  - AnthonyMouse 2y ago
    The requirement also feigns innocence. As far as I can tell there is no actual requirement to block third party firmware, merely a vague rule that says they have to do something. But designing hardware specifically to enforce the regulatory limits even if the firmware requests otherwise would cost money whereas blocking third party firmware just screws over the public, so in practice that's what they pick when you force them to check the box. On top of that, using that method is also the least effective because then any firmware vulnerability still allows regulatory limits to be exceeded. And if you're okay with that then there are plenty of alternative measures that could be used to check the box at low cost as long as you don't care that they're not very effective. But somehow that's a failing for the alternatives whereas with software it's just expected to be rubbish.

AnthonyMouse 2y ago

> And there is at least one good reason: certified and unlicensed radio equipment, like Wi-Fi(or unlike HAM) are expected to be tamper resistant, for public good. This is such an own-goal. The way manufacturers implement this is by locking out third party firmware. Then the device goes out of support a decade before people stop using it, but because nobody else can update it either -- and the manufacturer has higher internal support costs because there is no community submitting patches they could just adopt and ship -- the device gets full of public unpatched security vulnerabilities. Which at scale is a significant threat to national security. On top of losing whatever other benefits the public would derive from the community being able to fix firmware bugs or add features. Meanwhile the purpose of the requirement is supposed to be to keep users from modifying the radio parameters to exceed regulatory limits. Which, first of all, hardly anybody is going to do anyway, because the vast majority of people don't even know how and most of the remainder aren't interested in risking huge fines just to avoid buying a second access point. But the people who are going to do it, because the devices don't get patched, can just use the vulnerabilities to root them and then modify the radio parameters anyway. Which makes it a pointless rule that compromises the public good.

numpad0 2y ago
What you've said is why a lot of people voiced concerns to that suggested changes, leading to it getting safely cancelled, while the same cohort of people were and are fine with existing anti-tamper requirements. I guess it's another anecdotal datapoint that shows disastrous state of the field called software engineering, especially relative to other professional fields of engineering(cf. https://xkcd.com/2030/ https://xkcd.com/2030/).
- AnthonyMouse 2y ago
  The requirement also feigns innocence. As far as I can tell there is no actual requirement to block third party firmware, merely a vague rule that says they have to do something. But designing hardware specifically to enforce the regulatory limits even if the firmware requests otherwise would cost money whereas blocking third party firmware just screws over the public, so in practice that's what they pick when you force them to check the box. On top of that, using that method is also the least effective because then any firmware vulnerability still allows regulatory limits to be exceeded. And if you're okay with that then there are plenty of alternative measures that could be used to check the box at low cost as long as you don't care that they're not very effective. But somehow that's a failing for the alternatives whereas with software it's just expected to be rubbish.