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.

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.

LineageOS also significantly regresses security compared to barebones AOSP.

• Userdebug builds
• No locked bootloader or verified boot
• Incomplete backports of patches

This is a blatant and complete fabrication that you are spreading. The project is on good terms with Spender and you have no evidence to support what you are claiming.

It was after GRsecurity became private that they had an issue with people making upstream security contributions, particularly upstreaming anything from the GRsecurity patches. They had disagreements about that, and then moved past it and are on good terms now.

It’s absolutely ridiculous to claim that Micay has anything to do with them making things private.

https://grsecurity.net/announce https://news.ycombinator.com/item?id=10126319

It was Wind River, owned by Intel, which was the main offender for upstreaming the patches. Micay was the one who introduced GRsecurity in Arch Linux and did all the integration it had for PaX exceptions and the start of RBAC support (systemd was an issue at the time). It was afterwards once it became private that it was awkward because they didn’t want people upstreaming or maintaining ports of their work but at the time Micay was maintaining GRsecurity in Arch Linux and GrapheneOS (then called CopperheadOS) was using the PaX subset for kernel hardening, so there were existing uses of it to try to keep going in some way.