If there is a security feature that they see as reducing 'freedom' (with a very odd way of defining freedom) it will be deliberately left either not set up or permanently disabled via fuses. They see it as failure if there is any signed or closed firmware that can be updated.
Conversation
And the 'solution' which is applied is preventing it from being updated. This is the MAIN CRITERIA for their choice of components: whether they can block firmware from being updated. So for example, if there are separate data lines for firmware updates, that's perfect to them.
1
Doesn't matter if it's horribly outdated and/or insecure. The decision making is based on whether they can technically have an OS without proprietary components and no way of updating proprietary components from the OS. That is the goal - and not just a transitional one, really.
1
They'll pay lip service to actually open hardware and firmware but it's not really part of what they want to achieve. End goal is RYF certification and they want to obtain that through making the firmware count as 'hardware' by preventing updates to it to make it out of scope.
2
2
There is nothing more open about the components, and it leads to choice of components that is actually quite problematic for privacy and security reasons. Blocking firmware upgrades is very problematic separately from that. It may be possible to bypass in some cases with physical
1
1
access by connecting directing to a component via JTAG, etc. particularly since they're not going to be setting things to production mode and disabling debug features. They may actually lock things into debug mode in some cases. This is the company's approach, not just 1 product.
1
2
Anyway I don't really see the point of listing out vulnerabilities and flaws with components and the SoC along with the specifics of what they have done wrong. The specifics are not the issue here but rather how they operate. With Pine64, you could convince them to do things
1
differently and you could at least theoretically set up a device for production after receiving it, although you'll be missing nearly all the tooling and documentation for it without a partnership with the hardware vendors yourself. Probably many issues to address, but I doubt
1
that there are more issues overall, and you avoid the issue of having the OEM sabotaging the device entirety. I would like to know what Purism actually does that makes them any more truly privacy or security focused than Pine64. In fact a lot is counterproductive and harmful...
2
Zero concern for privacy and security but rather simply making a device intended to be useful (including component choices made based on quality:price) would really be better than the status quo. Using mainline kernel + driver stack does not require sacrificing so much...
1
in fact you will find that there are older generation mainstream devices that are highly functional with the mainline kernel + driver stack and offer substantially better privacy and security properties. Or, buy a new, expensive device that's far worse + deliberately sabotaged...
You're in the same situation of components with neglectful vendors, etc. regardless. In one case, because the hardware is old. In the other, because it's new hardware shipping with more problematic + outdated components from the outset. In all cases, it's fully closed source.