Comment by gruez
19 hours ago
You still need to rely on the OEM to properly configure the bootloader, not leak the keys, and provide updated vendor blobs.
19 hours ago
You still need to rely on the OEM to properly configure the bootloader, not leak the keys, and provide updated vendor blobs.
It should be doable with cooperation between the two, right?
If we add that FSF aims to provide free alternatives to some vendor blobs the landscape begins to look promising.[0]
One party to provide needed specs for hardware, one party to free the hardware from vendor blobs and another party to merge this into a working product.
[0] https://www.fsf.org/campaigns/librephone
[flagged]
> I guess, my attack model for my personal phones doesn't really account for "my phone got stolen", I'm far more worried about impersonation and remote phone hijacking than needing to be safe from confiscation from feds.
Even if you only care about "remote phone hijacking", not being able to provide timely vendor blob/drivers/kernel means you're wide open for EoP exploits.
As for why they take such a hard line on physical security, well it's their project and they can have whatever high standards they want, especially if they want to project an image of being an absolute secure phone. The code's all open source so it's not too hard to port to another device, especially nowadays with AI.
[flagged]