I mean, vulnerabilities and contributing code are pretty different things. But most of what I know about AI finding vulnerabilities is that their abilities and achievements are hugely overhyped, as evidenced by the fact that there hasn’t been any consequent mass-hacking, I’ve seen a few niche things unveiled, but at no particularly faster rate than usual.
I’ve no idea about GrapheneOS or the people that run it.
Four months ago a vulnerability was found using an LLM on the piefed instance and that caused a massive shit show. It is definitely not just hype. The implication here is that anyone can throw the source code of an open project to an LLM and look for vulnerabilities
GrapheneOS recently got into a controversy because of their use of AI in the defense and identification of threats. The reality is that when your opponents are using AI to attack, you need AI for defense too
While contributing code is different, what does this actually mean for projects? How are you going to enforce and verify not using AI among your coworkers or contributors? It seems the keepass devs already realize the futility of this practice so they just have them specify which code was written by AI
Don’t get me wrong, I’m not defending vibe coding, I’m just realizing that fighting this is just a losing war
I don’t see anything here that counters the idea we should be fighting or discouraging AI use in software. I’ll be honest and say I’m struggling to understand what your point really is.
One vulnerability found four months ago is nothing new. Random script kiddies who know nothing have been finding exploits since the invention of the computer. When this becomes actually notably more of a regular occurrence, I’ll be more worried.
Again, I don’t know about the GrapheneOS lot. I really don’t think their position or use of AI is relevant. Thousands of ubiquitous software projects don’t use AI for “defense”, despite many people looking for exploits, yet there’s no big uptick in issues. So I’m not convinced AI is useful for “defense” either, but that’s a separate question.
You don’t need a magical oracle to ban stuff. Some people will secretly use it; if/when that becomes apparent, you can enforce it. We ban fascists from Hexbear, not by mind-reading, but by just… banning them when they behave fascistic. Same deal.
I mean, vulnerabilities and contributing code are pretty different things. But most of what I know about AI finding vulnerabilities is that their abilities and achievements are hugely overhyped, as evidenced by the fact that there hasn’t been any consequent mass-hacking, I’ve seen a few niche things unveiled, but at no particularly faster rate than usual.
I’ve no idea about GrapheneOS or the people that run it.
Four months ago a vulnerability was found using an LLM on the piefed instance and that caused a massive shit show. It is definitely not just hype. The implication here is that anyone can throw the source code of an open project to an LLM and look for vulnerabilities
GrapheneOS recently got into a controversy because of their use of AI in the defense and identification of threats. The reality is that when your opponents are using AI to attack, you need AI for defense too
While contributing code is different, what does this actually mean for projects? How are you going to enforce and verify not using AI among your coworkers or contributors? It seems the keepass devs already realize the futility of this practice so they just have them specify which code was written by AI
Don’t get me wrong, I’m not defending vibe coding, I’m just realizing that fighting this is just a losing war
I don’t see anything here that counters the idea we should be fighting or discouraging AI use in software. I’ll be honest and say I’m struggling to understand what your point really is.