So then if I am giving up on Android for my needs, I feel I might as well forge ahead on simpler hardware with fewer blob requirements and dramatically lower my expectations to what best-effort feature-phone type setups are achievable on pinephone/librem5 type hardware today.
Conversation
And in the mean time push vendors for at -least- a TPM to do coreboot-heads type measured boot or at best SoC level secure boot like Pixels have.
That said, stopping evil maid attacks is not the most important thing for my mobile device threat model.
1
1
If I can give up stopping evil maid attacks and in turn get a feature phone in the very short term with a very small footprint easy to maintain/build OS... then that starts looking like something I could maintain as just one person until maintainable AOSP-first hardware emerges.
2
1
Verified boot is one of MANY missing hardware security features, not the only or even the primary one, as stated earlier. You're not accurately representing what is lost, including ongoing security support and in one of the cases, an OEM not actively hostile to security...
2
1
Evil maid is the obvious risk I understand.
I will again say here I would be very interested in specific remotely exploitable hw or fw vulns present on the Pinephone or Librem5.
Please detail them as it would no doubt impact how I and others are weighing risks.
2
1
> Evil maid is the obvious risk I understand.
Verified boot is again one of many core hardware-based security features. I don't think it's anywhere near the highest importance among them. You're missing a lot more than verified boot. I don't know where you get the idea that's
1
the major piece of the puzzle that's missing. In particular, the Librem 5 has gone out of the way to prevent full firmware upgrades, and has used hardware with very lackluster security and serious security issues. The OS is just a piece of the privacy/security stack as a whole.
2
I don't like your attitude and how you approach this in terms of communicating and the kind of dubious / false claims you make. I'm not going to give you long-form write ups of my knowledge / research especially on Twitter. You can do what you want but don't try to make false
1
claims about it and misrepresent the compromises involved as you are repeatedly doing. My recommendation to you was to at least use the Pinephone and avoid worse problems. If you want to ignore that recommendation, that's fine, but don't expect me to spend more time on this.
1
Also, verified boot is PRIMARILY not about defending against physical tampering. The primary threat model is persistent compromise. So even when it comes to that feature, which is dwarfed by the importance of other aspects of hardware security, you present it in a warped way.
2
1
I don't really think engaging with you on these topics is productive. Doesn't seem to go anywhere and it's not going to become an in-depth discussion if you're just jumping being different things in way that's very misleading / inaccurate and unfocused on anything in particular.
I can't tell what you actually want to do anymore or what you're talking about / comparing. You were talking about porting AOSP to those devices, then presenting issues with making an OS for Pixels using the official vendor support as issues with AOSP, etc. Can't follow it.
1
I am weighing risk pros/cons of three short term paths.
1. Blindly trust endless vendor blobs and do constant reveng work for Pixels.
2. Try to port AOSP on more OSS friendly H/W Librem5/Pinephone
3. Build minimal feature phone Linux on Librem5/Pinephone.
2
1
Show replies