updating it to 'protect your freedom' however that works by not having the ability to update firmware. It may be possible to use JTAG, etc. in some cases to bypass it. They deliberately chose components where they could block firmware updates in some way. That's the main concern.
Conversation
So, in some cases, maybe they just didn't wire up all the data lines, in others they've configured it to prevent doing it, etc. So, sometimes they'll not configure security features (same case on their laptops), but they're also fine with just setting it up to block updates.
1
So, regardless of whatever is wrong with the Pinephone, they want to make something good and aren't sabotaging it, and they can improve it in future generations.
1
They don't have a weird ideology driving them to use loopholes to make a device where firmware can be considered 'hardware' by preventing updates to it. That's the only reason they can claim they avoid it: by preventing updates to it. It's still all there, including for the SoC.
1
1
And they don't consider it enough to simply not ship firmware / microcode updates. They consider it a problem for it to be possible for operating systems to do it, including the user going out of the way to do it via the OS. I think it's probably also considered an issue for it..
1
... to be possible with some out-of-band debug cable, etc. but just not nearly as much of one and I doubt they care about going out of the way to prevent that as they do with stopping updates via the OS. This is not the only issue with it. It is one of them, and representative
1
of the other issues with the device and why it is the way it is despite being quite expensive. So, yeah, the Pinephone is very low end hardware, and you get what you would expect for the price, including problematic hardware / firmware security, but future ones can be better.
1
They aren't explicitly anti-security and making design decisions based on stuff like that. Rather it's largely based on price. I think you are better off with that especially with the potential of future versions with higher end, more modern hardware. They won't sabotage it.
1
I don't expect them to set up security features for the SoC, setting up all the peripherals in a secure way, etc. and it can be problematic because public tools are generally not available to do stuff like flashing fuses in the SoC, even if it's still in development mode.
1
But they are not going to sabotage it, and they probably just leave it in the development mode, so perhaps you could theoretically set up various security features on it. They haven't gone out of the way to block you from doing that and to block you updating firmware/microcode.
1
So, would you rather have bottom of the barrel, very cheap hardware without the OEM doing higher level security integration work, or essentially all those problems along with explicit sabotaging of security and the ability to build something a bit more secure with it as a base.
Or you know, you could always just use the mainline kernel drivers and software stack on a mainstream phone without this issues and that's popular enough among developers to have steady work on it including from Linaro, etc. Don't see why you settle on these 2 platforms only.
1
There is nothing more open about the components they're using, and you could be using open drivers on other hardware too. It's not going to be great either way and there will be missing functionality, stability issues, etc. You just seem to be going entirely based on marketing.
1
Show replies