This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for users, and also a net security negative. This whole rhetoric that updatability matters, or that somehow lack of source code means "only the manufacturer can update it" and that somehow "makes things less free for users" needs to stop. Users are still in control of updates, the thing isn't magically phoning home (corner cases of stuff with network access notwithstanding). Having access to the blob is a net positive on all fronts for users. This whole policy keeps trying to use this excuse as a rationale, but the reality is the only thing it achieves is convincing people that they aren't running blobs at all by condoning devices where the blobs aren't evident to users because they're not in their filesystem.
This was all brought to its logical extreme of silliness with the Librem 5, which actively engineered an obfuscation mechanism for their RAM training blob to put itself in compliance with RYF, for absolutely no benefit to users: it's still running the same blob as it would've otherwise, and it's still updatable (you can even ignore the entire obfuscation and just flash your own bootloader that does it the normal way).
There is a distinction between blob 'is in ROM and cannot be updated', 'is in EPROM and might be updated', and 'it is in RAM and must be provided at boot'.
While one can argue about the second case, the third case is problematic for practical and legal reasons, as handling (using and distributing) requires accepting licence of the firmware, which affects distribution infrastructure of free Linux distributions. Some firmwares also do not allow redistributing, so they have to be downloaded from vendor website, which further complicates practical and legal matters and have privacy issues.
The second case (it is in EPROM nad might be updated) does not have such effect directly, but leads to it indirectly, by allowing vendors to depend on cheap post-purchase fixes by firmware update, so they can offer less tested products, where firmware update is practically necessary due to original firmware being buggy, so essentially moving to the third case.
So we both say the same thing with different words. I agree, which is why there is a call to FSF for change.
Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
I thought you were saying that hardware is whatever "cannot be updated". That's the argument the FSF uses to say ROM firmware is OK because it's not software. I'm saying that's not okay, because updatability is a plus, not a minus, and ROMs are still software.
> Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
The obfuscation in the Librem 5 did absolutely nothing to isolate the proprietary blob in any way, shape, or form. It would always run on a dedicated CPU, from the get-go (and that CPU is part of the RAM controller, so it is a security risk for the entire system either way). They added a third CPU in the loop to load the blob, because somehow touching the blob from the main CPU gives it the digital equivalent of cooties in the FSF's view, but adding this extra step of indirection makes it all OK. And then they put the blob in a separate Flash memory so it wouldn't live in the same flash as the main open firmware, because that somehow helps freedom too? Seriously, that whole story is just utterly stupid no matter which way you look at it.
Yes, I'm saying that. But if you intentionally prevent users from updating it, then it does not turn software into hardware in my opinion.
Do you have any link saying that the blobs are still being executed on the main CPU after the RAM training is finished? Upd: you replied here: https://news.ycombinator.com/item?id=29842166.
RYF certification is absolutely meaningless, both from the freedom and security/privacy perspectives. It is actually actively harmful to freedom, as it encourages manufacturers to hide blobs to get through its backdoors (ROM blobs are OK, RAM blobs are not), when doing the opposite is actually more accountable and open, and allows for user-controlled replacement of blobs with free versions in the future.
Also, Stallman had personally said he wouldn't give the Novena open hardware laptop RYF certification unless they permanently fused off the GPU, "because otherwise users might be tempted to install the (optional, not distributed with the product or endorsed in any way) GPU blobs". Literally the same product segmentation nonsense we're bashing Intel for here. This was before open drivers became available, which they eventually did. Imagine how wrong the situation would've been if bunnie, the creator of Novena, had actually listened to this; "RYF" certified Novena owners would own crippled machines unable to use 3D acceleration, while the rest would own machines capable of running a 100% libre desktop including 3D acceleration.
> Libreboot disagrees with that
You do realize that that post is Leah politely saying that RYF sucks and is completely broken, and she's given up on strict compliance, right? FSF policy is indeed that you shouldn't upgrade your microcode (see e.g. endorsing linux-libre, which censors kernel messages telling you about important microcode updates).