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, 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 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel