I don't see it that way at all. They're incredibly dishonest, not at all transparent, and do not really have the goal of making open hardware. They are explicitly anti-security and anti-privacy in many ways too. It's not a good hardware target and they won't ever make a good one.
Conversation
They do not share the goals or concepts of GrapheneOS at all. It is a bad target, they will always make bad targets for it, and they are not a viable partner or collaborator with an actual privacy/security focused project. Been burned already, others have too. No thanks.
2
1
You're bringing it up at the same time as Pine64 which has similar technical issues but without nonsense from the company / leadership including lots of harm. It's also a bad target, with no sign of ever wanting to make a good one, but at least they don't lie and cause harm.
1
1
IMO Librem5 has better hardware but the marketing and misrepresentation of it is a black eye to be sure.
Still if forced to pick between them or Google right -now- while we spend a few years making long-term sustainable/secure hardware I take Purism.
2
You can't make a device with decent security based on it and it's far from being able to run a fully functional AOSP particularly with the security features supported (but far beyond that) so not sure what you plan on doing with it.
1
At least Pine64 doesn't have deliberate anti-security measures and anti-security policies / ideology. It's just not technically advanced in that regard so it's far behind the status quo / industry standards (applies to both) but the reasons are better (lack of resources).
2
Put another way, 90s tech I can readily grab sources for, build, and know it will boot without weeks of work... is something I and others can rapidly improve software privacy/security on while we wait for better hardware to arrive.
Anon wifi issues etc can be fixed.
2
> know it will boot without weeks of work
Yet it won't. Good luck with functional AOSP on it, with them being hostile towards what you're doing too.
> Anon wifi issues etc can be fixed.
Nope, you can't magically fix hardware and firmware security issues.
2
The hardware and firmware plays as much as a role in overall security as the OS. You can live in fantasy land and deny that all you want. Hardened OS on insecure hardware / firmware especially on a device from people with an anti-security ideology / approach sabotaging it...
1
If that's what you want to do, it indicates that there isn't going to be much overlap in the way I want to approach custom hardware. I really can't see the use case for it as a stopgap, and it's hard to see the future path being compatible if that's what you want to do right now.
2
Also, if I didn't care about compatibility with existing apps and complex software stacks, I definitely wouldn't want to use a complex CPU and with an OS built around the Linux kernel on it. If the goal was building something secure without compatibility that's way different.