Notices by GrapheneOS (grapheneos@grapheneos.social)

@antlers @thestrangelet @xyhhx @chu Here's Rossmann's verified Kiwi Farms account where he regularly rants about the GrapheneOS and Asahi Linux developers:

https://kiwifarms.st/members/larossmann.132201/

The video you're referring to was directly based on Kiwi Farms style fabrications and talking points including baseless claims about someone's mental health, with the clear goal of directing harassment towards them. Rossmann has done the same with others including recently targeting Linus Tech Tips in a similar way.

@antlers @thestrangelet @xyhhx @chu Can see in your feed that you're stating this is because you watched content from a far right Kiwi Farms user heavily involved in directing harassment towards both us and other people through fabricated stories, spin and Kiwi Farms talking points. Calyx organization and their community have been extensively involved in this too. It was a Calyx supporter who did the severe swatting attacks aimed at killing one of our developers shortly before Rossmann's video.

@antlers @thestrangelet @xyhhx @chu CalyxOS is not a hardened OS like GrapheneOS. It's similar to LineageOS, not GrapheneOS. CalyxOS reduces security compared to the Android Open Source Project rather than improving it. It does not provide comparable privacy or security improvements to GrapheneOS but rather largely the opposite.

https://eylenburg.github.io/android_comparison.htm is a good third party comparison between different Android-based mobile OSes.

Shouldn't believe the fabricated stories people spread about us.

The functionality provided by Google's new Android System SafetyCore app available through the Play Store is covered here:

https://security.googleblog.com/2024/10/5-new-protections-on-google-messages.html

Neither this app or the Google Messages app using it are part of GrapheneOS and neither will be, but GrapheneOS users can choose to install and use both. Google Messages still works without the new app.

@MediaActivist @MediaActivist /e/OS is genuinely a highly insecure OS without basic privacy and security intact.

Gael Duval is scamming people and is involved in harassment towards our team. They even personally used a bunch of sockpuppet accounts to spread misinformation about GrapheneOS and engage in harassment. We aren't interested in communicating with someone like this.

@MediaActivist

/e/OS is an entirely different kind of thing from GrapheneOS and is nearly the complete opposite of it. LineageOS already greatly reduces security compared to the Android Open Source Project and the /e/OS fork of LineageOS completely destroys it.

GrapheneOS is a hardened OS with substantial privacy/security improvements:

https://grapheneos.org/features

It doesn't just preserve baseline privacy and security but rather massively improves both. They're not at all similar projects.

@MediaActivist

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

Their services are also not private and are far worse than the services from Apple with end-to-end encryption support.

/e/OS and Murena are putting people in danger not providing the most basic aspects of privacy and security. It's just a lot of false marketing to sell products.

@MediaActivist That comparison table shows the delay for partial security patches and full security patches on the devices where they're least behind. The delay is usually much more than what's shown there because for most devices they're much worse than that.

Strongly recommend doing research based on what actual privacy and security researchers/engineers have to say about /e/OS. Don't believe the marketing from /e/OS and Murena. They want to sell their highly insecure products.

@MediaActivist The products you're promoting are genuinely a scam harming people. You can confirm this with basic research to confirm that they have a year or more delays for privacy and security patches across devices. On many devices they don't really provide them at all. They mislead users about this by setting a fake Android Security patch level and making inaccurate claims about what's provided or the impact of what's missing. They don't preserve basic security features either.

Our features page now has a section listing the features added by our Vanadium browser and WebView:

https://grapheneos.org/features#vanadium

It explains the approach to content filtering, anti-fingerprinting and state partitioning including current limitations. Major improvements are coming.

The only other browser we can currently recommend is Brave. It preserves most of the security of mobile Chromium while adding more state partitioning, anti-fingerprinting and the most advanced content filtering engine. Vanadium is more secure but needs to catch up in those areas.

@MediaActivist /e/OS is highly insecure and lacks the most basic privacy and security. It does not keep the Android privacy and security model intact or provide proper privacy/security patches. They lag at least a year behind on full privacy/security patches, months behind on providing partial Android Security Bulletin backports and driver/firmware updates are not provided properly. It's genuinely not a safe option at all. The hardware lacks basic security too. Way worse than an iPhone.

@dalias @lispi314 Seccomp-bpf can't inspect strings including paths. That's why they came up with landlock, which was initially trivial to bypass but should work properly now. Android does heavily police access to devices, procfs, sysfs and ioctls via SELinux. Linux kernel has very limited capabilities for doing a lot of that itself without an LSM.

POSIX DAC doesn't really forbid access, just directly opening, and more importantly the policy is very dynamic and spread out in a bunch of places.

@lispi314 @dalias We mean that it would be possible to run an isolated Linux kernel to run the Linux kernel ext4, f2fs or exFAT driver, another for a Linux kernel Wi-Fi driver, another for a GPU driver, etc. and turn it into a swarm of Linux kernels acting as a poor man's microkernel. It would be far higher overhead than an actual microkernel but it's a possible approach, at least as a higher security mode. Running groups of applications in virtual machines would be a separate thing from that.

@dalias A vulnerability in a GPU or Wi-Fi driver shouldn't compromise the security of the whole OS because it should be isolated. Filesystems should at least be possible to run isolated. Linux is fundamentally opposed to that design. Still feasible to coerce it into working that way by running separate Linux kernels isolated from each other side-by-side. It will add a bunch of overhead vs. it being designed that way to start.

They also have problematic attitudes towards undefined behavior, etc.

@dalias Access control is primarily for securing userspace rather than the kernel itself. SELinux offers a large amount of capabilities for securing userspace which aren't available through other access control mechanisms. Linux doesn't have any modern object capability system and there would still be a need for static, declarative policies if it did. Android also heavily uses SELinux for kernel attack surface reduction too. There isn't any serious alternative upstream. It's the only option.

@dalias Linux kernel maintainers have both accepted and rejected dozens of little access control features for providing inflexible versions of what can be done through writing declarative SELinux policies.

Access control is a very small part of defending the kernel itself against attacks. The main issue with the kernel is that it's a massive monolith with no sandboxing for drivers, filesystems, etc. and increasingly immense complexity for core kernel components for max scalability, etc.

@dalias Linux chose performance over security and correctness from the start. It continues choosing performance and scalability over security and correctness today. It's a massive mess. The userspace APIs and access control aren't really a big part of what we consider wrong with it. POSIX permissions, ACLs, etc. and layering on a bunch of hard-wired special cased policies and complex MAC/MLS are a terrible approach compared to a more modern system but it's not really a huge problem.

@dalias There's nothing we can do to change how much of a disaster it is in terms of the kernel being exploited to escape sandboxes or as the main attack vector to exploit the device. We have hardware memory tagging for the kernel enabled now and we can work on adding deterministic guarantees similar to hardened_malloc and other allocator hardening but it's still going to be disaster. We also have to do something about GPU drivers doing insane things with memory which bypass this hardening.

By default, GrapheneOS blocks new USB connections when the device is locked in the Linux kernel and at a lower level via the USB-C and pogo pins controllers to defend the firmware and lower-level Linux kernel code too. Data is blocked in hardware once connections end.

https://grapheneos.org/features#usb-c-port-and-pogo-pins-control