The goals are completely different, and the actual implementations are miles apart. They aren’t comparable apart from a common AOSP ancestor.
The goals are completely different, and the actual implementations are miles apart. They aren’t comparable apart from a common AOSP ancestor.
Open source or source availability is not a requirement for auditing a system. There would be evidence that would have almost certainly been found by now if this was the case. It is up to you, or the claimant, to prove their claims. I can say that there has not been any evidence of data collection by hardware components found, despite years of Pixel devices being tested by security researchers and mobile forensics companies. Not only that, the actual technical capabilities of the hardware (isolated component without networking capabilities) backs that up.
What do you have except fearmongering?
GrapheneOS (like any other AOSP fork) is technically a Linux based OS. They run a modified version of the Linux Kernel. What matters is the changes they have made to the kernel, as well as enforcing AVB, SELinux, etc. etc.
“Linux” phones that run modified desktop Linux distros are hugely insecure devices that lack many basic security and hardening features.
CalyxOS is not hardened in any way and is in some ways less secure than stock AOSP. They are also on a hiatus and have discontinued updates: https://discuss.grapheneos.org/d/24791-departure-of-calyx-calyxos-leadership-and-discontinuation-of-calyxos-updates
There is no “hole”. It has nothing to do specifically with being from Google, only that no one else but Google is manufacturing devices that meet the hardware requirements and have full support for alternate OSes.
It is an isolated component without networking. This is not evidence that unknown data collection is occurring. You need to provide actual evidence that it is.
This is definitely not true. GrapheneOS is focused on privacy, security, and usability. It has many features that are solely for increasing privacy and control and implemented in very robust ways. For a couple of examples, see the Contacts and Storage Scopes features.
This is a common misconception people have as a result of misinformation being spread.
They have officially stated that they can support the 10 now, but it will have to wait until after the port to QPR1. https://xcancel.com/GrapheneOS/status/1960792610114511190#m
That device didn’t meet the requirements for GrapheneOS even when it was supported by the OEM. As of now, it is an EOL device and is highly insecure. https://grapheneos.org/faq#future-devices
LineageOS also significantly regresses security compared to barebones AOSP.
Tracker blocking uses flawed heuristics. The only methods that are typically used are static lists which is just badness enumeration. There is nothing stopping the app/service from sending the data down a different domain that isn’t blocked or a domain that can’t be blocked without breaking the service.
Adding to that, how do we even decide what is a “tracker”? What is the definition? Some might say it includes all telemetry or crashlytics. Are those inherently malicious?
I don’t think it would make sense for GrapheneOS to include something flawed like a “tracker blocker” that lulls people into a false sense of security. They use robust and meaningful methods for improving the privacy and security of the OS.