4 ms·

If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse

If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one. 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).

fsflover 5y ago
> If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. 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.
- marcan_42 5y ago
  > So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. 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.
  - fsflover 5y ago
    > I thought you were saying that hardware is whatever "cannot be updated". 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 https://news.ycombinator.com/item?id=29842166.
zajio1am 5y ago
> 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. 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.

fsflover 5y ago

> If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. 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.

marcan_42 5y ago
> So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. 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.
- fsflover 5y ago
  > I thought you were saying that hardware is whatever "cannot be updated". 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 https://news.ycombinator.com/item?id=29842166.

zajio1am 5y ago

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