On the other hand, implementing proper AOSP support for a device not intended for it and without support from the OEM would be far more difficult than nearly any option that's available... and you're talking about hardware missing so much functionality particularly security-wise.
Conversation
No amount of work would be able to make it fully functional and software work won't address hardware/firmware deficiencies. Don't understand how throwing in a TPM (i.e. a really bad take on a general purpose security chip challenging to use for anything valuable) fixes anything.
1
You talk about these couple weeks of difficult work that has to be done once a year to quickly migrate and continue following along with the upstream security updates as if it's worse than having to do everything from scratch while never having full security support at all.
2
It's not just a couple weeks of work. The work being done is cutting huge corners because there is just not time to do it right and we all know it.
android-prepare-vendor is a gargantuan hack and we end up tossing in tons of blobs we -could- build if there were enough cycles.
2
I feel like current efforts are doing some amazingly useful research (like hardened malloc remote attestation etc) however vendor is a massive can we keep kicking down the road with no clear path to resolve.
1
Then I look at projects like PostmarketOS where the entire OS is less than the footprint of the stuff we are currently forced to blindly pullover from vendor for lack of time to properly sort through it, let alone the 250GB+ of AOSP code most people lack the hardware to build.
1
1
This leaves me concluding that long term Android may not the right solution for those of us that want to maximize security and privacy.
Start with much leaner Linux that is basically a feature phone, then eventually rip out Linux too.
1
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.
1
3
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...
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
If I am being inaccurate, then please set me straight.
My conclusions are based on my current understanding of the risks of each stack as it pertains to my threat model.
...and of course verified boot is something perfectly possible on i.MX8MQ and planned to be used on the Librem 5 by PureBoot.