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.
Conversation
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.
1
1
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
What's the point if it's far worse than the alternatives? It's not open hardware. It's still closed hardware with closed firmware. Matching the security offered by Apple and Google's security teams is not easy, and when an OEM doesn't even try to do the basics and meet basic
1
1
industry standards, that's a disaster. Hardware and firmware plays as much of a role in overall security as the OS. No point focusing solely on the OS. No point in having an extremely hardened OS running on easily compromised hardware, particularly if it lacks security updates.
1
1
Why bother with so much work in software exploit mitigations with an SoC without the basics? Can't see the point.
What's the point in GrapheneOS for a device with an incredibly insecure baseband, Wi-Fi / BT radio, GPU, etc. and lack of proper security updates for them? Etc.
Don't really see any alternative to being an OEM or working very closely with an OEM. There is no future for GrapheneOS as an aftermarket OS for hardware not made in collaboration with the project. It's just a stopgap to keep the project alive and offer something decent today.
2
Targeting an outdated platform with lack of full security updates, lack of many important industry standard security features / mitigations, active hostility towards what we want to do, etc. is not a recipe for success. The concept of using the Librem 5, etc. is dead on arrival.
1
1
Show replies