skorp01

Hello,

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".

The expectations of desktop platforms to behave the way they do is a holdover of early computing not giving much regard to malicious actors. Having a system where you can run a binary and grant it admin/superuser permissions, giving it widespread and dangerous access across the entire system, isn't how I personally want to do my computing.

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.

You have a fundamental misunderstanding of what AVB is used for.

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.

It absolutely is. You can fork GrapheneOS, modify it, and sign the images with your own key; all to your heart's content.

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.

There is a nice little post here from one of the GrapheneOS project members/moderators.

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".

You are expecting and hoping that it will act the same as desktop environments do.

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.

Robert Braxman's provisions have ranged from highly insecure devices, EOL devices, charging for TOR as a service, an "e2e encrypted" chatroom that sends the key in plain text, etc.

He is a serial fabricator and charlatan.

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

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

It is not the OS "used by drug dealers". The vast majority of criminals use the stock OS on whichever device they purchase. It is pure make believe to think that people are installing any alternate OSes to commit crimes.

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

Minimum Target SDK is the opposite of user hostile. Privacy and security changes are added to the SDK consistently. Apps that fail to comply with that SDK are much more of a privacy risk.

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.

This is not an apt analogy.

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".

This is largely untrue.

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.

Maintaining one's data as private requires that it is protected as a baseline. Privacy violations do not solely exist as telemetry or data offered up by the platform to some other party.

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.

I have bad news; Do you know who is a major contributor to the Linux kernel? (It's Google)

This is a personal anecdote and you are making up an absurd conclusion. No one said things would collapse. Security can be evaluated objectively, and the better the security, leads to fewer instances of exploitation. I'm certain the actual data around InfoSec would support that idea.

You have the ability to do what you want on your device. Root access in AOSP is just used as a hacky shortcut to achieving specific functionality. To do it properly while maintaining the security model would be to build it into the OS itself. The same concept applies to desktop platforms and the Librem 5. This isn't related to freedom.

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

That absolutely is not the point of the project and completely misses out on the many general privacy improvements that GrapheneOS makes, as well as the huge privacy improvement offered by running Play Services in the untrusted and unprivileged user-app sandbox.

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