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.

We largely disallow making posts entirely based on AI model output. For example, we get a lot of forum threads from people with concerns based on AI model output and will typically provide a quick answer followed by locking the thread and then eventually removing it.

It isn't permitted to submit pull requests or issue reports created by an AI model without fully understanding it. It's fully allowed to file issues found by an AI model if there's a human who understands it and writes the report.

We do not want issue reports entirely generated by an AI model or which were written by a human and passed through an AI model to provide analysis. It's usually incredibly inaccurate and we would greatly prefer the user's explanation of what's wrong. We want a description of what happened, a crash traceback if one is available and optionally a subset of logs emailed to logs@grapheneos.org if people are comfortable doing that after triggering the crash or another issue. We sometimes request it.

It can sometimes be useful to analyze an issue with an AI model but it usually isn't. It also definitely isn't useful to do it with a free or cheap model available without either paying for it or running it on very expensive hardware. In general, users do not have access to anything useful to analyze it. We don't want people to keep converting their issue reports into slop. We want what a user pasted into the AI model interface rather than what an AI model produced as output from that.

Frontier models are very good at finding bugs but it requires an experienced developer to babysit it and extract the useful portion of the output. Important bugs are often found but mixed in with a bunch of low quality output. The details on the issue and especially proposals to fix it are often wrong. It's still very useful and finds many real issues. The volume of real vulnerabilities being found this way in Linux, Chromium, Firefox, Postfix and countless other projects is quite scary.

It isn't a good idea for people to point a model at an open source project and then start submitting bug reports to it. People need to be able to confirm the issues themselves with relatively high confidence before reporting it. It's okay to make some mistakes but it should not be the majority of what's reported. We do want people to report these kinds of security bugs to us but the signal to noise ratio is far too low right now. Even frontier models spew out contrived nonsense and fabrications.

We want people to report very serious Android Open Source Project security bugs to us but we can't handle a lot of minor issues. We don't generally need Chromium security bugs reported to us because they handle those far more quickly and have a far better system for releasing it. Linux kernel security bug reports are useful if they refused to fix it (arm64 kASLR) or it didn't get backported to the LTS. GKI LTS being behind the LTS is a separate problem we'll be addressing ourselves again soon.

We have high standards for code being merged into GrapheneOS, especially for code in critically important parts of the project. Most of the changes made to the OS are to critically important parts of the code. It takes a long time to get features to meet our standards. There's usually a lot of back and forth review with many improvements requirements for anything significant. External contributors shouldn't try to take on major features without talking to us and planning that out with us first.

Going from having a working implementation of a feature to code we can merge often takes a long time. It can take months or even more than a year. It doesn't always work out. Sometimes we decide a feature ended up being too invasive or risky for other reasons and don't want to include it. We'll often do rewrites. Contributors need a full understanding of what they've submitted and need to be prepared to make substantial changes including fully rewriting it multiple times. AI slop isn't accepted.

We don't forbid using AI models for writing code but pull requests largely created that way will typically be rejected or skipped due to not meeting our requirements. It needs to be well written code which appears to be regular code written by a human regardless of the level of AI assistance involved in making it. It should not look like AI generated code. We do want to know if AI models are being used and how they're being used rather than people using it but not telling us they're using it.

GrapheneOS is based on projects heavily using AI including the Linux kernel. Cellebrite, NSO and other exploit developers are using it to exploit these projects. They currently have a major advantage thanks to AI which will likely be turned into a major disadvantage over the long term. It's getting a huge backlog of bugs fixed and creating enormous pressure to make systemic improvements.

Here's what Debian adopted, which is a similar idea but much more permissive:

https://www.debian.org/vote/2026/vote_002#texte

@GrapheneOS many of your users spent a number of years recommending others to specifically avoid projects like calyx and "/e/" due to all the technical, security, and privacy reasons tirelessly documented by you, and use grapheneos instead, if they're able, *because* of your higher standards.

and now you keep saying on here that you can't avoid the upstream slop anyway.. others are doing it too, and that somehow makes it ok to use and "carefully" cook your own? this is wrong, and you know it

@ludonaut That's the direct opposite of what we've said. We're primarily using it to improve the quality of our code through additional passes of code review. We started doing that after multiple external contributors used AI to find a bunch of issues throughout our code. Most of those were issues like crashes but some were more important. Some of our low-level hardening features were not providing as much security as they were meant to be. We began using it proactively to catch issues early.

@ludonaut As you're well aware if you use GrapheneOS, there are a bunch of abandoned AOSP apps which haven't had any active development for years.

Those apps are stuck in the state they were in back in Android 5 or even earlier. Many even regressed. They've had bare minimum maintenance for years which gradually ended upstream.

The issues with those apps include them not being overhauled with privacy and security improvements applied elsewhere. It includes outdated dependencies missing patches.

@ludonaut We're in the process of overhauling these apps by rewriting nearly all of the code in phases. It's becoming much higher quality code with many bugs getting fixed as part of it. That includes fixing upstream privacy and security issues which have been around for years.

Vast majority of experienced developers working at tech companies are using AI. Most of the people applying to us are using them. We have to filter through people who can pass our tests but are too reliant on AI.

@ludonaut People using AI models doesn't imply the end result is lower quality. We hired the people who we decided are capable of producing high quality code and being productive with their usual approach to development. For people who made it past our initial screening, we gave test projects and we learned a lot about what they'll produce for us from it.

All of the work they're currently doing is clearly massively raising the code quality compared to the starting point of that AOSP app code.

@GrapheneOS "additional passes of code review", you keep specifying "frontier models", why exactly do you believe this would make any difference, and how much of that donated money did you or the people you've hired spend on those death cult motherfuckers? how many tons of co2 do you think this took? how many liters of water ruined? how many lines of plagiarized code do you think? don't you love "not now/later" consent dialogs too?

actually, here, real simple, let me quote @jwz for you:

@GrapheneOS please, i'm begging you to consider that people might be sad and angry and disappointed because they've put a lot of trust in you that they feel is being betrayed. it is actually a betrayal because how are people supposed to trust their operating system, or any computers, now that it's all top to bottom compromised by torment nexus chatbots that make you feel good

@GrapheneOS
i for sure feel like a huge idiot now for ever recommending grapheneos to others, and i really don't know what i'm supposed to do now about my privacy except throw my phone into a river and walk into a forest. i don't know how many more bad news i can take, i just really wish you hadnt joined the llm bozo parade

@ludonaut @GrapheneOS I somewhat have to agree with GOS. Most of people who hate on LLM use environmentally are not vegans and the meat/dairy industry does much more damage to the environment (and is also a literal holocaust of living beings).

I don't think LLM use is good, but I also don't think most people should speak up this harshly about it when they don't do the single easiest thing for the environment (and animal rights ofc) which is just going vegan.

I hate big tech as much as the next guy, don't get me wrong, but all the leftists are focusing on LLMs right now, because it's easier to blame a corporation than do something yourself first.