Pinephone and open source firmware for baseband

[zetabeta]

Pine64 appears to be quite honest. They plaster the store page with disclaimers saying the Pinephone is not a consumer-ready product and give customers the right expectations. The worst I found was an off-hand comment on the marketing page saying the Pinephone is for you if you "work in a security-focused field", which isn't really true because of how far behind Linux is compared to both iOS and Android.

i tend to disagree little bit. i have heard that gnu/linux is lower on security than ios or android, probably mostly on app isolation, in gnu/linux world, ordinary user has quite wide permissions, where in android and ios every app is isolated more or less. however, in android and especially in ios, user are dependent on apple and google for security, it is centralized. maybe in android it can be circumvented somewhat by modifications, but still relies on google's eco system indirectly. so in gnu/linux world, if user knows the flaws, they can be fixed or circumvented, and not being dependent on apple's or google's policies.

in short, i don't think centralization bring security in longer term.

What the posts by GrapheneOS complain about are that even in Biktorgj's modem firmware, the DSP firmware is still the same proprietary blob as in the completely proprietary firmware, and they claim that this is not properly communicated by Pine64. In the end, it all amounts to disagreeing on what "modem firmware" and/or "baseband firmware" really means (and whether they are the same thing or different things).  Biktorgj himself is pretty upfront on what his firmware replaces with Free Software and what not, in any case.

in my view, graphenos has technical truth over there, i just don't see how pixel is better on this area (or most other devices). so, it is how this technical truth is used.

graphenos boasts heavily about signing keys for graphenos. but they use google's pixel's bootloader for that. so it's dependent on google for that. even with signing keys, graphenos has control or google with bootloader, not necessarily the user. can someone build a android kernel with own signing keys and upload those keys into pixel, i think it is possible, who would do that. anyway, bootloader code is still google' code and control.

what i learned from android over the years, is that "oem unlock" is not total unlock. fastboot and bootloader may still have limitations for users. so, oem unlock is more like partial unlock.

just theorizing, if re-button is physically blocked. someone could do a special bootloader for the spi memory, and it asks either a password or has signing keys. so it guarantees secure boot for a user. and if re-button is blocked, it cannot be overrided. weirdest part is, user can vefiry spi code and flash it. this starts to sound de-centralized. (off course the re-button). personally i don't need this, but i think bootloader needs to be controlled by users.