On Sun, Jul 25, 2021 at 7:48 AM Dave Taht <dave.t...@gmail.com> 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 WiFi 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 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
