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