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

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

[Dave Taht]

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 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

Re: [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@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

Re: [Cerowrt-devel] [Make-wifi-fast] resuming the right to repair fight in particular

[Кирилл Луконин]

[-- Attachment #1: Type: text/plain, Size: 5152 bytes --]

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 <dave.taht@gmail.com>:

> On Sun, Jul 25, 2021 at 7:48 AM Dave Taht <dave.taht@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
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 7440 bytes --]