There is a significant difference between coordinating community members to brigade and notifying community members about threads which contain factual inaccuracies about the projects technical work or history.

As an open-source project and a non-profit foundation, there is not a PR team or firm. It is perfectly normal to have an opt-in notification role for community members who wish to help clarify technical misconceptions in public discussions. It is a transparent and not uncommon practice.

HN has built-in protections against external voting and flagging. Comments that end up being flagged are rarely (if ever) substantive criticisms related to the OS or foundation. In nearly every case they are comments serving to derail technical discussions into personal attacks, armchair psychology, or unsubstantiated accusations against contributors and community members (like repeatedly calling community members "sycophants" and "pathetic").

Constructive technical criticism of the project happens every day, and is welcomed without issues. Expecting those discussions to remain focused on technical aspects and factual realities rather than personal hostility isn't "crashing out".

You seem to be conflating the ecosystems (which I concede are largely profit-driven), and the platform architecture. The security models that include sandboxing, MAC/SELinux, Verified Boot, and many more; are unequivocally pro-user.

I get it seems like we're speaking of totally different things but hopefully I can bridge that. You having "freedom" to have runtime root access means that any malicious actor, rogue binary, etc. also has that freedom to run amok on your machine and that access cannot be so easily taken back.

I don't know how to respond to your comment about rules other than to say that it's incredibly easy to demonstrate being wrong.

Mobile OSes like AOSP have a much better ability for you to set rules. Access permissions for microphone, camera, other sensors, network, filesystem, are HEAVILY gated by the system which enforces the rules that you choose to set.

Desktop platforms are largely ill-equipped to handle this and are highly permissive. In fact, desktop OSes are frantically trying to copy mobile OS architecture: MacOS SIP, flatpak, Wayland, Windows Virtualization based security, the list goes on and on.

Runtime root access would allow a malicious app to silently bypass every rule that you think you've set. It does the exact opposite of guaranteeing those rules.

Fully supporting and using AVB grants protection against persistence of *all* kinds. If an attacker gains privilege escalation through a remote attack, persistence become much easier if the system is not cryptographically verified every time the device boots.

Keystore and Attestation also rely on the bootloader being locked. If the hardware root of trust reports the device as untrusted, there is a broken chain of trust for biometrics, encrypted app data that uses the hardware keystore, and any form of attestation checks (like AOSP's Hardware Attestion API) will report the device as untrusted.

Going back to the first point, if it is possible to modify the system and gain persistence, there is also the possibility of modifying the kernel, which would allow an attacker to rewrite or patch the kernel, rendering AOSP's sandbox useless.

This would also make it more vulnerable to downgrade attacks because rollback protection is tied to a locked bootloader and AVB.

This could all be accomplished through remote exploitation. The "software side" you speak of is built atop AVB as a minimum requirement to assure that the software you're running is unmodified and intact.

Exposing root to userspace does not make you the owner of it, and serves to erode the guarantee that the OS is enforcing the rules you set. The way it is used is a hacky shortcut to achieving functionality that should be written into the OS itself so that the security model can be maintained.

https://discuss.grapheneos.org/d/10150-not-your-average-why-...

the tl;dr:

- There has never been any evidence found of any hardware backdoors in Pixel devices. - Those would be quickly noticed. - Those are poor and inefficient methods for any sort of data collection.

To answer your question they are not "just hoping for the best".

Desktop environments can't/don't because there is an inherent expectation of users that they should work a certain way and they are built upon decades of neglectful security practices.

Mobile OSes are the attempt to change that and provide better security models from the ground up. AOSP being open-source is what gives you the actual control to modify your platform as you see fit, not having runtime root access exposed to the user.

The idea of "control" that you are describing is illusory and only serves to actually undermine your real control. If you expose root access in that way, you have a much lower guarantee that the rules and permissions that you set are going to be able to be enforced by the system, because you have allowed the system to be modified. If something malicious gains that access, you have lost that guarantee.

He is a serial fabricator and charlatan.

https://nitter.space/GrapheneOS/status/1894511926962446670#m

https://forum.f-droid.org/t/brax2-alternatives/22469/6

There is also no statistics resulting from surveys, studies, reports, etc., that would indicate such a conclusion about user demographics.

Feel free to look at the AOSP SDK changes for each major version that's released and you will see many of these examples.

Apps that failed to keep up with these changes, regardless of licensing, should be avoided and ultimately removed from availability.

The deprecation of 32-bit apps is another example of this.

A couple of the tenets of computing security are:

- Defense in depth - Principle of least privilege

It is a foundational reality that software (especially in unsafe languages) will invariably have vulnerabilities. Defense in depth and least privilege have compounding effects by forcing attackers to chain multiple exploits to achieve a compromised device, rather than a single vulnerability.

GrapheneOS shows how much can be accomplished on top of relatively secure platforms to begin with (AOSP, Pixel Stock OS, etc.) without sacrificing nearly any usability to the end user (barring manufactured hurdles like Play Integrity). It makes it more damning that many "privacy" OSes and devices cannot even meet the baseline level of privacy and security that AOSP provides, but degrade it.

Firmware and driver neglect and the lack of secure element utilization is not "reasonble security for the price".

You would be missing out on:

- Minimum Target SDK Enforcement Blocks installation of apps that target ancient versions of Android and legacy APIs.

- Restricted settings for sideloaded apps

- Null-Cipher rejection and 2G disabling

- Cell Network Surveillence Alerts

- Platform Rust Migration

- Scoped Media

Among many many unpatched Med and Low severity CVEs that don't get backported.

The protection is achieved through security. The major goal of something like GrapheneOS is privacy, which needs solid security as a prerequisite.

The blobs, while proprietary, are not opaque. They are able to be examined and they are.

The security of a device should not be dependent on what you choose to run on it. You should trust and be able to verify that the platform on which you are running the software prevents something malicious from accessing data which doesn't belong to it or otherwise violates the rules set by the platform (OS).

In this respect, the Librem 5 would do a horrible job compared to even stock AOSP. Thinking that you are secure because you only run "trusted" software on an insecure platform is cope.

That device, and the Debian derivative it runs, are not private or secure.

https://grapheneos.org/features#sandboxed-google-play https://grapheneos.org/faq#hardware-identifiers