From dave.taht at gmail.com Mon Oct 4 12:54:35 2021 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 4 Oct 2021 09:54:35 -0700 Subject: [Cerowrt-devel] resuming the right to repair fight in particular In-Reply-To: References: Message-ID: On Sun, Jul 25, 2021 at 7:48 AM Dave Taht wrote: > > Early on in the FLOSS podcast ( > https://twit.tv/shows/floss-weekly/episodes/638?autostart=false ) I > harped on what is basically my biggest issue with the world of IoT - > home routers only being a tiny subset - being able to fix the stuff > you bought, and KNOWING that the stuff you bought isn't going to > betray you. The cell phone universe is about as well handled in this > department as seems feasible I take it back. https://www.vice.com/en/article/z3xpm8/company-that-routes-billions-of-text-messages-quietly-says-it-was-hacked >, but the rest... ugh! > > I know our lists are mostly technically oriented but does anyone know > of a site, a forum, a slack channel, a linked in group, a faceboook > group, some legal advisory group... somewhere??, where I, at least, > could vent in something in a productive direction? I'm very happy to > finally be in BITAG but that's just about lag. > > I often look back on our 2015 fcc fight with remorse, as we didn't > have enough capital to capitalize on it, and I just went back to > finishing up our research. We knocked 'em down FLAT with that one > broadside but nobody read the filing itself, just the press release, > and the vogons got up again, like a tarbaby, and resumed bad > governance of the future as usual. > > For the record, if you haven't read: > > http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf > > Our proposal buried on page 12: > > 1. Any vendor of SDR, wireless, or Wi­Fi radio must make public the > full and maintained source > code for the device driver and radio firmware in order to maintain FCC > compliance. The source > code should be in a buildable, change controlled source code > repository on the Internet, > available for review and improvement by all. > > 2. The vendor must assure that secure update of firmware be working at > shipment, and that update streams be under ultimate control of the > owner of the equipment. Problems with compliance can then be fixed > going forward by the person legally responsible for the router being > in compliance. > > 3. The vendor must supply a continuous stream of source and binary > updates that must respond to regulatory transgressions and Common > Vulnerability and Exposure reports (CVEs) within 45 > days of disclosure, for the warranted lifetime of the product, the > business lifetime of the vendor, > or until five years after the last customer shipment, whichever is longer. > > 4. Failure to comply with these regulations should result in FCC > decertification of the existing > product and, in severe cases, bar new products from that vendor from > being considered for > certification. > > 5. Additionally, we ask the FCC to review and rescind any rules for > anything that conflict with > open source best practices, produce unmaintainable hardware, or cause > vendors to believe they > must only ship undocumented “binary blobs” of compiled code or use > lockdown mechanisms > that forbid user patching. This is an ongoing problem for the Internet > community committed to > best practice change control and error correction on safety­ critical systems > > > -- > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw > > Dave Täht CEO, TekLibre, LLC -- Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw Dave Täht CEO, TekLibre, LLC From klukonin at gmail.com Mon Oct 4 14:57:18 2021 From: klukonin at gmail.com (=?UTF-8?B?0JrQuNGA0LjQu9C7INCb0YPQutC+0L3QuNC9?=) Date: Mon, 4 Oct 2021 21:57:18 +0300 Subject: [Cerowrt-devel] [Make-wifi-fast] resuming the right to repair fight in particular In-Reply-To: References: Message-ID: There is a big another issue. Even if we work with softMAC driver, it can ignore or override wireless-regdb. For example, iwlfifi could advertise, but ignore MCS 9-11 according to LAR decision. More then that, LAR can spread it's logic and disable some channels globally for all systems. That's why, for example, if somebody use both QCA and Intel Wi-Fi modules, the last one will force right use it's settings through cfg80211 API. So there is a huge issue in kernel restrictions and rules, I think. Where wireless API is mostly developed by... Intel. More transparency and fairness required there, I think. No kernel module should be able to become a dictator. What about a certification process, well, I saw the dark side. Certification firmwares are very-very-very far from regular firmwares. That's how it works today. FCC can certify a product, but then it's firmware cold be modified without any control from FCC. FCC tries to do the best they can with AFC (I think). But today there are no any mechanisms to 1) Force vendors to use regular firmware for certification 2) Certify firmware updates. We'll have to invent something about that. Best regards, Kirill Lukonin пн, 4 окт. 2021 г., 19:54 Dave Taht : > On Sun, Jul 25, 2021 at 7:48 AM Dave Taht wrote: > > > > Early on in the FLOSS podcast ( > > https://twit.tv/shows/floss-weekly/episodes/638?autostart=false ) I > > harped on what is basically my biggest issue with the world of IoT - > > home routers only being a tiny subset - being able to fix the stuff > > you bought, and KNOWING that the stuff you bought isn't going to > > betray you. The cell phone universe is about as well handled in this > > department as seems feasible > > I take it back. > > > https://www.vice.com/en/article/z3xpm8/company-that-routes-billions-of-text-messages-quietly-says-it-was-hacked > > >, but the rest... ugh! > > > > I know our lists are mostly technically oriented but does anyone know > > of a site, a forum, a slack channel, a linked in group, a faceboook > > group, some legal advisory group... somewhere??, where I, at least, > > could vent in something in a productive direction? I'm very happy to > > finally be in BITAG but that's just about lag. > > > > I often look back on our 2015 fcc fight with remorse, as we didn't > > have enough capital to capitalize on it, and I just went back to > > finishing up our research. We knocked 'em down FLAT with that one > > broadside but nobody read the filing itself, just the press release, > > and the vogons got up again, like a tarbaby, and resumed bad > > governance of the future as usual. > > > > For the record, if you haven't read: > > > > http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf > > > > Our proposal buried on page 12: > > > > 1. Any vendor of SDR, wireless, or Wi­Fi radio must make public the > > full and maintained source > > code for the device driver and radio firmware in order to maintain FCC > > compliance. The source > > code should be in a buildable, change controlled source code > > repository on the Internet, > > available for review and improvement by all. > > > > 2. The vendor must assure that secure update of firmware be working at > > shipment, and that update streams be under ultimate control of the > > owner of the equipment. Problems with compliance can then be fixed > > going forward by the person legally responsible for the router being > > in compliance. > > > > 3. The vendor must supply a continuous stream of source and binary > > updates that must respond to regulatory transgressions and Common > > Vulnerability and Exposure reports (CVEs) within 45 > > days of disclosure, for the warranted lifetime of the product, the > > business lifetime of the vendor, > > or until five years after the last customer shipment, whichever is > longer. > > > > 4. Failure to comply with these regulations should result in FCC > > decertification of the existing > > product and, in severe cases, bar new products from that vendor from > > being considered for > > certification. > > > > 5. Additionally, we ask the FCC to review and rescind any rules for > > anything that conflict with > > open source best practices, produce unmaintainable hardware, or cause > > vendors to believe they > > must only ship undocumented “binary blobs” of compiled code or use > > lockdown mechanisms > > that forbid user patching. This is an ongoing problem for the Internet > > community committed to > > best practice change control and error correction on safety­ critical > systems > > > > > > -- > > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw > > > > Dave Täht CEO, TekLibre, LLC > > > > -- > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw > > Dave Täht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast -------------- next part -------------- An HTML attachment was scrubbed... URL: