Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.

[Isaac David]

interesting discussion. I apologise in advance for replying to many
mails at once.

David Craven <address@hidden>:
> We want to be able to exercise our freedoms in all parts of our
> computing systems.

correct, all of them.

David Craven <address@hidden>:
> Taylan Ulrich Bayırlı/Kammer <address@hidden>:
> > David Craven <address@hidden>:
>
> > >  Solution:
> > >  [...] focus on the following:
>
> > >  1. The firmware is freely redistributeable
>
> > Being freely redistributeable doesn't make a blob free software
> > obviously
>
> The requirements I proposed for the definition of free firmware is
> already more than most companies are willing to do. Any company
> willing to do these things should IMO get a medal pinned on their
> chest and not be disadvantaged.

they should be encouraged to go further!

this is in contradiction with your opening remark. the freedom to copy
and share is necessary --and better than no freedom at all--, but it
isn't sufficient. the four freedoms are the inexorable standard. they
correctly characterise which software has a shot at acceptability and
which doesn't, and there are reasons we can discuss as to why this is
the case.

David Craven <address@hidden>:
> This leads to two models of loading the firmware that runs on the MCU.
>
> 1. The peripheral does not contain persistent storage and the firmware
> is loaded by the linux kernel through a standard API.
>
> 2. The peripheral contains persistent storage containing the firmware
> and uses a separate interface for flashing the firmware.
>
> Problem:
> Today as an example, a WiFi card using option 2 is considered more
> free than one using option 1.

it shouldn't. the current situation is to be interpreted as saying:
"in case 2 firmware is non-free but the OS remains ethical, whereas in
case 1 both OS and firmware are wronging."

this of course assumes that no. 2 isn't actual ROM. otherwise, the
question of using that device boils down to trusting what an immutable
piece of hardware is doing.

> Implications on Security:
> While in the first case we can check the hash of the binary blob and
> be certain that the binary blob we are providing is what is running on
> the device, in the second case we do not even have that guarantee. A
> malicious party can reflash the firmware and no one would ever know.
> Security through obscurity is no security at all.

I would argue both are cases of security through obscurity when the
firmware is a binary-only blob. what good is a checksum when we don't
know the contents? it provides no protection against the biggest
threat: the vendor. by the same token, what good is bad source code
that we cannot fix and distribute thereafter?

> With the second model there is no simple way to fix
> vulnerabilities even if the vendor is aware and willing to fix it.
>
> This also makes it much harder to write, debug and distribute free
> firmware if such where available.

I agree that loading firmware from within the OS comes very handy for
a majority of users and distributors, but that doesn't mean external
re-flashing is untenable. I would rather have free firmware and a
clumsy external programmer board than proprietary firmware handled by
the kernel.

a final unimportant note: EEPROMS that are flashable solely from the
OS are a thing. Aren't they, hardware gurus?

--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Tox: 
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C