Our long-term goal is to be targeting custom hardware in collaboration with organizations like Calyx, where hardware is produced to suit the needs of multiple projects. Would no longer have these issues regardless of how much SoC vendor code is open + can take time to migrate.
Conversation
+ even if SoC vendor code isn't open, at least we'd still get to audit, modify and build most of it internally including a lot of the SoC firmware. Maybe there would be an SoC vendor with decent security and open source device support code at that point - right now, not really.
1
1
I mean Librem5 and Pinephone type hardware with the only chailnge being the addition of a proper TPM stack for secure boot stuff would still mean a very small number of blobs and worlds easier to maintain AOSP for than anything that exists today.
2
2
I am finally realizing trying to run open software on hardware whose vendors never intended for you to do that is backwards.
I would rather run latest upstream patched AOSP on a Librem5/Pinephone-ish h/w than always lagging behind w/ blob hell Pixels. Evil maid be damned.
1
We won't target a device with serious remote and local code execution vulnerabilities in firmware and drivers, along with very sub-par exploit mitigations, no verified boot, no attestation, lack of Wi-Fi anonymity, etc. Not going back to the stone ages of privacy and security.
2
1
We want our own hardware to avoid having Google as a middleman between us and the vendors. Either way, components are closed source hardware with closed source firmware. Avoiding closed source libraries often means making major sacrifices like using very insecure / outdated hw.
1
1
And as an OEM, you have the sources for those libraries. It's not the same situation as ripping them from the factory images of another vendor. They don't just get a package of binaries. They get a source tree to build the vendor image which is a mix of open source and NDA repos.
1
1
Years ago, OEMs even got the source code for the Qualcomm baseband, but they stopped sharing it and allowing modifications. Anyways, SoC vendor choice becomes something in our control if we have our own hardware. It doesn't have to stay the same between generations either.
1
1
We can choose what we think is the least bad compromise and then that choice can change as the situation changes. We hardly have any issues AOSP and it has rapidly improving privacy/security itself. Our issues are with the OEMs (Google as the Pixel OEM) and their hw vendors.
1
1
I don't think targeting devices made by other vendors is viable in the long-term. I haven't thought it was viable after the first couple years working on this in 2014-2015. I quickly realized having our own hardware was crucial. If my business partner hadn't been a sociopathic
1
1
narcissist solely interested in making money via the path of least resistance and with no concern for ethics, perhaps we'd already be in the position where we'd have our own hardware platform. I do not really see much of a path forward ATM. I continue because I have to continue.
Need a hardware vendor that is security focused and wants to support AOSP with open source drivers. Not going to get that from Purism or Pine64. It will be even harder to accomplish anything of value and provide a secure phone that way. Doesn't get any closer to controlling own
1
1
destiny and not depending on incredibly flawed OEMs with incompatible goals. You're treating the device being made with using open source drivers as a core goal as if that's the hardest and most important aspect. It's one of many aspects, and is far from the hardest thing to do.
2
1
Show replies