security features including the hardware-backed keystores used by the OS and apps, support for real verified boot and attestation, modern mitigations, proper IOMMU integration / setup for the components, hardware key derivation support, Wi-Fi anonymity beyond just MAC rand, etc.
Conversation
But to get all those you also have to trust yet another closed stack of components and piles of privileged binary blobs you have to sort through tediously on every single new device.
All current options suck in very different ways.
2
The Librem 5 and Pinephone are closed hardware with closed firmware. The complexity in the entirely closed source SoC and other hardware components / firmware completely dwarfs the complexity in userspace libraries. You're also grouping things that are open source in with blobs.
2
You think wpa_supplicant and all of the other largely open source code in vendor is closed source? Lack of interest from people in building code from source let alone replacing the closed source components (many of which have working open source alternatives already) says a lot.
1
I never thought wpa_supplicant etc was closed. After going through the actually closed blobs in the pixel 4 I realize they just keep adding more and more. It is a very time consuming task and so far no one has the time.
I truly hope that changes. You are the closest of anyone.
1
You're inaccurately treating the division of code into the vendor image as being based on open vs. closed source. It isn't and a device with fully open drivers has everything involved in device support contained to the vendor image. You're confusing Pixel issues with AOSP issues.
1
That is fair. Hardware vendors Google chooses for their flagship devices and their endless blob requirements are the problem, not AOSP.
They become hard to separate as I don't know of any current gen devices with IOMMU/secure boot that can run blob free.
1
The proprietary code in userspace can be inspected/audited (it even has symbols), fuzzed and hardened with a subset of the techniques used elsewhere. This is about ideology, not so much privacy or security, especially when the far more complex SoC underneath is closed either way.
1
That code is not obfuscated and has debug symbols. You get all the function names, etc. even though you don't get the source code. It's not a black box. In reality it's not really any harder to inspect it for backdoors than any of the open source code. People don't do either.
1
People want to, but few but you have the life setup to do it full time.
If I do manage to hit escape velocity one of the first things I would do is double down on helping people like you and supporting open hardware targets.
Until then it is deciding what is most tolerable.
2
The Librem 5 and Pinephone are not open hardware targets though. Librem 5 is even closed in ways that the Pixel hardware is not. Pinephone at least doesn't do destructive things making things substantially worse to play stupid semantic games to get a meaningless certification.
Pinephone is also actually affordable. I want a low cost blob free phone with 4 apps. You would think that is an easy ask, but in reality it is a massive one.
1
1
The firmware for the SoC and other components is closed source whether or not updates are available and shipped for it. You shouldn't call this hardware open source or blob free when it is not open hardware or open firmware. Makes those companies untrustworthy among other things.
The librem laptops/desktops ship coreboot/heads firmware, neutered ME, and run with no OS blobs.. Give me that in a 5 inch form factor even without a cdllular modem and we are getting closer... But no such luck yet.
1
So, still entirely closed hardware / firmware, just with some bits of the firmware supposedly disabled. Pure security theater incomplete form of verified boot / attestation that's there for marketing instead of as a meaningful or usable implementation (it's neither).
1
1
Show replies