[Cerowrt-devel] resuming the right to repair fight in particular

[Dave Taht]

On Sun, Jul 25, 2021 at 7:48 AM Dave Taht <dave.taht at 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 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