GrapheneOS imposes a set of restrictions on how generative AI can be used in our project and community. It isn't forbidden but rather we imposed rules based on actual issues.

Posts made in our forum, chat rooms, issue tracker and the rest of our project must be written by humans. There's an exception from this rule for translation and accessibility features. That means commit messages, pull request messages, bug reports and feature requests are expected to be written by humans, not a machine.

Replying to @⁨GrapheneOS@grapheneos.social⁩

@GrapheneOS for an OS project that refused porting to non-PIxel h/w for so long b/c other platforms didn't meet security reqs, this pro-LLM stance is ludicrous.

~all bugs found by LLMs can likely be found by other methods using the same-or-less compute resources, especially w/ the human effort "babysitting" the LLMs to ensure they don't go off the rails.

there just aren't billionaire fascists subsidizing that compute, be honest about it.

stop covering + doing PR-by-action for LLM fascists

Replying to @⁨dasmatus@mastodon.social⁩

@dasmatus

are you serious? what is the relation b/w GrapheneOS taking security so seriously that they wouldn't port their OS to h/w that didn't have Pixel's special sauce, and now being fine using LLM code + bug reports + dedicate human time to "babysit" the LLMs?

my intention is not to "bully" @GrapheneOS. we need folks like you in FOSS building rock-solid projects. I'm merely voicing criticism, and hoping the team explores other alternatives.

leave big (proprietary) LLMs in the bin

Replying to @⁨elle@weathered-steel.social⁩

@elle @dasmatus GrapheneOS is based on Linux, AOSP, Chromium and hundreds of other upstream projects heavily using AI generated code.

Our OS development team hasn't been using any AI code generation but yet the OS is heavily using it because the vast majority of the code comes from upstream projects. Linux and Chromium are both massive projects.

Firefox is heavily using it too, so that isn't relevant to this. It's nowhere close to what we would need to use it as a replacement regardless.

Replying to @⁨GrapheneOS@grapheneos.social⁩

@elle @dasmatus Our policy is only accepting high quality code. We've always had to do careful code review and avoid trusting submissions.

We aren't happy with the flood of slop which gets submitted to us via our issue tracker, security@ email and pull requests. However, a lot is reporting or fixing valid issues.

For pull requests fixing valid issues, we can either get them to improve it to meet our standards or do it ourselves. We often start with rounds of review but finish it up ourselves.

Replying to @⁨GrapheneOS@grapheneos.social⁩

@elle @dasmatus In the past couple months, there has been a massive flood of valid vulnerabilities being discovered by frontier AI models. Nearly all of those are from human written code, often from many years ago.

Linux has heavily shifted away from adding new features and improving performance to fixing the bugs found by these models. They're being forced away from sticking with C and a monolithic kernel design. It's on ongoing crisis and people can regularly grab working exploits off GitHub.

Replying to @⁨GrapheneOS@grapheneos.social⁩

@GrapheneOS right, and one of my points was just imagine if all this compute & resources had been committed to, for instance, funding the Rust-for-Linux devs, the in-kernel testing infra, and paid community reviewers/maintainers (not corpo-backed devs).

it doesn't address the immediate practical need to address the fallout of LLM-found bugs.

@dasmatus

en