How workable is it today and how well would it work on a phone like this?
How workable is it today and how well would it work on a phone like this?
Murena also sells it preinstalled: https://murena.com/shop/smartphones/brand-new/murena-fairpho...
https://murena.com/shop/smartphones/brand-new/murena-fairpho...
I think "hardware security" of Google phones sounds nice on paper but you never know if these is some NSA chip or some other exploit build in that the Graphene OS devs never know about. I do not trust Google AT ALL and would love for them to support different Phones, because /e/ is does not sound very secure in comparison, they build on Lineage OS and they actually lowered security to widen compatibility AFAIK and I guess /e/ OS is just copying + de-googling.
What were these issues?
The developer is gone, so no need to avoid the project completely, but CalyxOS is an interesting alternative anyway.
The parent comment brought up the dev originally, but seems it's no longer an issue. Different commenter than the person you're replying to though.
The GOS team has done very thorough work to audit the supported devices, including the hardware, firmware and software components, to make sure they reach their high standards. They've made upstream contributions to AOSP, Linux and other projects with features and bug fixes to improve security and privacy of users. The project is well regarded in security circles, and I have no reason to distrust the team.
As much as I dislike Google, I wouldn't mind using their products if they respected my rights and freedoms. The GOS project ensures that more than any other modern smartphone, and I wouldn't change it for anything else.
Which means that these requirements are at least partly informed by the capabilities of Google pixel phones.
I have to say though that the timely security update thing is really a weak point of Fairphone. Yes they have years of support but they often delay updates for many months or skip major upgrades altogether.
GOS is reliant on work upstream like most products and projects are, it's why they stop supporting phones once the SoC and it's associate blob code fall out of support of the manufacturer. Fairphone doesn't do this, they keep pumping out new versions filled with unpatched vulnerabilities while pretending the software they're producing for the hardware they're supporting is up to date when it actually isn't. It's not a weak point, it borders on fraud.
That leaves backdoors created by and for Google, concern for which I suppose your comment still applies. It seems less likely to me though...
I wouldn't be surprised if there were some backdoor in the Qualcomm chip the fairphone 5 uses or the radios in other phones. Without open hardware you really can't trust anything. Not when we know we're all being constantly spied on by the state and by the corporations who design/manufacture our hardware.
Worse than that, most apps use random google stuff that they don't need, and the developers inevitably forget to check for NULL when they ask for the optional google service. At that point, the app fails with a null pointer exception at startup. Most apps fix this in a week or so, but they don't add de-googled android to the regression tests, so they end up breaking it again in a month or so.
The final straw was standing outside my car in 40F driving rain and staring at a java stack trace that was preventing the charger from turning on. At that point I pulled my work iPhone out of the glove compartment. If I didn't have it with me, I would have been stranded.
On the bright side, my Pixel 6 Pro got something like three times longer battery life than advertised until I broke down and installed the Google crap in a sandbox. At that point, battery life immediately plummeted back to advertised.
I wonder if politicians would intervene if more people realized that 66% of the battery usage of an Android phone is Google surveillance crap running in the background.
I say this as someone who's not a big fan of Google. If it's anything like iOS development, there’s a good chance it never dawned on them.
On iOS, there's a slew of things you want to check for as dev due to permissions and the like, but there's so much more we simply assume is there based on the frameworks Apple ships with the OS.
If ever there would be an option to de-Apple iOS, I wouldn't even know where to start to check for nil values, if only because Apple has significantly moved to abstract things away to make it easier on us, and they never allowed direct communication with components to begin with, everything runs through an Apple provided delegate.
The only one that didn't work was a podcast app with in-app purchases, which isn't supported.
Everything else just works.
The whole process was easy and painless.
The turnkey is right there, who will turn it?