Even before the advent of AI the quality of most reports was depressingly low. Most of your reports will quite simply come from folks in lower-wage countries that broadly don't speak English well and that use a shotgun approach to bug bounties. That means you are receiving a lot of them, they will be hard to read (assuming the information you need is in there at all) and if they get one success out of fifty then for them it is a really good return.
The advent of LLMs has made this a hundred times worse. Both because it makes it easier for most people to create reports that sound good (and so are more effort to dissect) and because people who didn't have to work hard to get any amount of competence are usually more entitled and more rude (the stakes are even lower for them).
It is economically no longer a good idea to run a bug bounty program at all. I honestly question whether or not even having a direct input for such things makes any sense anymore. The volume is becoming so great you need a classical spam filter to plow through it. But that won't work, because they all sound reasonable.
> AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.
Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
> Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation
Who gives a shit about reputation when you're the only game in town?
There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.
> Ok but who is going to sift through it all to triage the good bits when you're working on something for free?
Its like anything else in open source. Maintainers will do so if they care. Maybe they decide they don't care. That is always their decision to make but there are consequences for the project. Maybe those consequences make sense. Being a maintainer is all about making cost-benefit trade offs.
> Who gives a shit about reputation when you're the only game in town?
Its up to the maintainers whether they care or not. It depends on what they value.
Ultimately if maintainers make decisions that are at odds with what their userbase want, someone eventually forks and people vote with their feet.
Caring is only part of the problem. If you are inundated by low quality reports, or many duplicates of what turn out to effectively be the same problem, that you have to sift through to find the useful reports, then by the time you have something actionable you have no time left to take action on it.
The amount of reports coming in, particularly the low/zero quality ones, is apparently growing at a much faster rate than the time volunteers have for dealing with them.
Caring does not magically solve problems without enough people with enough time.
Today it's an industry driven by unscrupulous clout-chasers and a commitment to quantity over quality.
There is a difference between going through patches and pull requests vs. the endless stream of LLM-assisted bullshit that has started cluttering security inboxes in the last few years.
There is a difference between a proper vulnerability researcher and a clout chaser calling themselves a vulnerability researcher. Research for a start, to assess the problem to see if it is genuine and if so if there are significant mitigating factors (by default or that can be implemented), and checking if it hasn't already been reported, instead of just copypasting some LLM output with minimal review. And to many clout chasers everything they find is a grade A world wrecking highest possible priority "if you don't drop everything else and fix this now you are a kitten murderer and I'm going to release the information to the world in 24 hours" level issue (they know this because they suggested it to an LLM and it told them they were so right).
No there isn't. The vulnerability is either real or it isn't. How you feel about the researchers doesn't enter into it. People angry about vulnerability research have been making this argument since 1992.
> Yes, and people will sit there and sip tea while waiting for "someone"? For how long?
Until someone cares enough to do it. This is open source software. When it comes to open source, the golden rule is you either do the things you care about yourself or stfu.
Given the libav fork wasn't all that long ago, it can obviously happen to ffmpeg just as much as it can happen to any other project.
I think the internet is the real problem. Infinite choices, and sites designed specificly to keep you hooked. I feel like addictivity falls a lot when you are stuck with just offline things.
I think so too. The restrictions of offline software means it has less ability to nag you or pull you in a specific direction. The software you have at any given time is what you've got.
Same sort of theme I've being going for in my personal intranet. It's calmer offline.
As far as i know, wikilambda isn't really based around the mediawiki template system. And the mediawiki ecosystem itself is turning away from complex wiki syntax templates to lua based templates.
Regardless i do agree with you though. WikiLambda/Abstract wikipedia feels like second system syndrome to me.
WikiLambda is what happens when someone looks at the definition of the second-system effect and says, "Hey, that's cool and all, but I bet I can make a bigger, better version of this."
People have been gamifying war since prehistoric times. Most traditional sports are basically practise for war. While we have moved past it in the last few decades, most toys for boys are war based (tin soldiers aren't being used to act out an imaginary disarmament scenario). We even use the word "game theory" to denote the mathematical study of strategy (which often ends up being about war).
> involving fully autonomous drones set to destroy anything in a given area, with confirmed casualties
I mean, is that really different than a heat seeking misile at the end of the day? If its set to kill everything in the area, its not really using AI for making targeting decisions in the same sense a human would.
> replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix
In open source projects i participate in, "overwhelming" the maintainer gets you banned. It doesn't get your patches blindly merged. In some ways i find this one of the most shocking parts of the story.
As a "new" maintainer myself - how do you decide when to ban someone? I sometimes feel overwhelmed and I can feel a big uptick in huge PRs with huge LLM written descriptions but often I also don't want to be an asshole to my community & reject all their changes.
> As a "new" maintainer myself - how do you decide when to ban someone?
When I want to. I like to describe it using the amusing language from a generic cardholder agreement.
At any time, at my sole discretion, I may ban you from any of my projects; for any reason, or for no reason at all.
My projects exist because I enjoy working on them. My continued enjoyment is the most important aspect to the health and survival of any project. You don't owe anyone anything, you're allowed to donate your work to others, and also enjoy the privilege of setting whatever arbitrary rules you want to make sure you enjoy your time.
Imagine you're running a free ice cream shop. Some random asshole walks in and starts verbally abusing your best employee who has done nothing but try to help. At what point do you kick them out because your employee is more important and worth more.
You should stick up for yourself, I would.
You can't be an asshole to an LLM. They can feel offended.
You don't even have to merge stuff from a human. I've been contributing a bluetooth driver to a certain embedded project which I use. I put a lot of work into it. The fellas have not merged it yet -- they have limited attention and for whatever reason their priorities and mine are not aligned at this moment.
Would I like it to be merged? Sure would, it would stroke my ego, and I would not have to deal with any merge conflicts with whatever else they're cooking up. Does that mean they must merge it? Sure doesn't. They didn't make me any promises. For the time being, I can just use my fork.
Many open-source projects aren't passion projects run for pleasure. Think of it more like ice cream shops sharing recipes, or sharing in the work of running the factory. They just can't kick people out willy-nilly.
My solution is to look at PRs and other requests whenever I actually have time and feel like it, prioritizing contributions from people I trust and those that have put in the effort in making my job easier. That might mean things don't get merged for a long time and some people might get upset but that's not my problem.
> but often I also don't want to be an asshole to my community & reject all their changes.
I know its difficult, and i have no easy answers. I'm bad at it too. But sometimes saying no is the most valuable thing you can do as a maintainer.
That said, i think banning is about behaviour not the quality of the patch. Everyone writes a bad patch now and then, that is not a real issue. If there is an issue with a patch, and the contributor pushes back so hard you feel like changing your mind (not from logic but because you feel beaten down) - that is unacceptable behaviour and should not be tolerated from a contributor, even if they are otherwise a valuable contributor.
I'm not a maintainer but as the quote goes: "I would have written a shorter letter, but did not have the time." I'd suggest you keep a sense of how much effort they've put into packaging their PR to be the minimum change required to achieve its goal vs effort required by you to read it. Reject low-effort or overly verbose work.
IMHO OSS doesn't work if every 1 hr of contributor time spent on a change requires 1 hr of maintainer time to review. Contributor time spent on polishing, tidying and breaking down work is essential, and so maintainer time is a fraction of total time spent on a change.
When you feel they are toxic or harassing you and you don't want to deal with them anymore. If you're overwhelmed, say that you're busy and will attend to issues and PRs when you have the time. If you want to be accommodating, have good build instructions or action workflows so that people can easily fork and build it themselves.
If you ask me, LLM-generated things should just be banned outright, but I suppose other people's definitions of "community" include them.
> If you ask me, LLM-generated things should just be banned outright,
Why? In the end it's a patch's quality that counts. Regardless who or what contributed it.
Bad patch from trusted contributor is still a bad patch.
Perhaps this is more a management problem. How to best use developer's time, where to use AI (vs blindly deploy AI to generate patches & swamp developers with that).
Or do some rate-limiting? "Sorry, we accept no more than 10KB worth of patches per week on this project! Try again next week after we've reviewed this week's batch".
> Why? In the end it's a patch's quality that counts.
LLM patches tend to be significantly harder to review. Mostly because LLMs let people who don't know what they are doing get much further.
It might be an unfair heurestic as there are plenty of competent people who use it to good effect, but the vast majority of negative value patches use LLMs and it can be a bit exhausting. Lowering the technical barriers of entry just means more pressure on the human ones.
> Why? In the end it's a patch's quality that counts. Regardless who or what contributed it.
You just said: The things that I think and care about matter more than the things that you care about.
is that what you meant?
Being honest, if we're talking about the health of any given project, the patch quality doesn't matter that much. Not when you measure it against the importance of consistency and continuity of a regular contributor. A thousand perfect LLM patches are less valuable than an experienced maintainer.
If your LLM is annoying them, and they quit. The perfect LLM patch just destroyed the repo.
People wasting others time is a social problem, not a technical one. Rate limits can't prevent somebody feeling disrespected.
If you draw a firm boundary with that contributor, and they continue to push, ban them.
"This doesn't meet the standards of our project for reason xyz. Please refrain from submitting further PRs that do not adhere to our contribution guidelines outlined in CONTRIBUTING.md."
I'm an open source dev who doesn't take PRs, I just build a body of work that's hopefully consistent and leans a useful direction. Are you sure being a maintainer means coordinating a community? If your only role is facilitating the community then you ATA to reject their changes, but if you embody a direction you're trying to maintain the project to represent, then you have a free hand to accept or reject based on whether the goals are being served. In some ways as a maintainer it's your job to have these goals and to communicate them.
I'm reminded of Zig, where a stated goal is to encourage human programmers to get involved so they learn more about coding… as compared with 'get involved to make Zig itself more fully developed at its more abstract goals'. If a primary purpose is to get human minds coding, that rules out the whole class of 'encourage human minds to prompt machines to do the coding instead'. Zig is not trying to teach people to be managers, and that's both legitimate and charming :)
I think everyone / every project needs to adopt a strategy consistent with their values.
Unfortunately, I see the choice space here as having "developer effort" anti-correlated with "negative repercussions".
On one end of the distribution, a "hair trigger ban" strategy is low-effort for the developer but will have some fraction of false positives and some fraction of those impacted will complain to "the socials" and some fraction of those complaints will gain traction and, as we have seen, can unfairly taint the project or worse. Responding and managing the false positives also requires developer effort, unless the developers can sustain a "fsck the haters" attitude.
On the other end of the distribution, the developer can spends substantial effort to engage each submitter to ascertain and correct bad behavior, educate them on how they should engage other humans as a fellow human in this LLM era.
There is developer effort needed of different types along this distribution.
A divide-and-conquer strategy might go something like this:
- Rank each submission in some low dimension space (llm<-->human, malicious<-->helpful)
- When enough samples are collected, perform clustering in this space to determine stereotypes, name these clusters, and develop mitigating strategies and implementations as needed.
Mitigations from easy/extreme to hard/accommodating could include:
- Hair trigger ban button.
- Copy-paste a link to an explanation in a comment before closing and/or banning.
- Customized explanation in comment before closing and/or banning.
- Link or customized explanation of what must be done to move the sample to a more favorable category and close/ban if resistance or silence is returned.
- Ongoing engagement in the face of resistance or silence.
This "meta development" program to provide such a system/facility could of course be highly automated with LLMs, fighting fire with fire.
(Despite the length of this reply, it was written entirely by a random human on the internet and not an LLM).
I think we can learn about the extent to which this is an adversarial relationship from fighting email spam. By that, I mean the attackers adapt to exploit loopholes in the system, and different attackers have different profiles (eg obviously fake looking for fools vs spear phishing).
Which is to say, your system sounds good but I expect much more complicated defenses are needed.
Yes, the spam arms race is a really good analogy. In that light, my thoughts are aligned with heuristics that might be applied with procmail or in the original, pre-learning, spamassassin.
A fight-fire-with-fire is to insert an LLM to judge and/or respond to new pull requests and issues. This brings its own risk as it lets anyone who can make a PR/issue inject a prompt. It would also put one more wedge between the real human contributors and the real human developers.
A "humanity score" could also be an ingredient. GitHub or 3rd parties, could maintain a score of how human an account is. The "humanity" of all text produced by an account could be judged by LLM and/or humans. This could be centralized or based on a web-of-trust. Actually, I'd also like to have such a thing for reading HN and reddit comments.
But still, any system we can dream up can be attacked and we are back to an arms race.
Think of it as in other relationships, it’s important to set clear boundaries even if that creates some frustration. It’s a healthier dynamic long term than feeling you have to accept some changes you don’t want to avoid rocking the boat. As a maintainer you’re not at the service of the crowd, if that makes sense, it has to be a collaborative effort, where you have the last say
One popular solution lately has been instead of banning too much, because of the danger of false positives, to use vouch [0]. Trusted people get vouched and you prioritize their actions. Unknown people (or agents) need to gain trust to be vouched and bad actors can still be banned.
Remove the human element. Yes, someone spent time fixing a bug. If the fix doesn't look like it makes sense on its own, do not merge it. If the author tries to convince you that it's a good fix, it's an immediate no.
A good fix (which is the only acceptable fix in open-source software), is one that speaks for itself.
> A good fix (which is the only acceptable fix in open-source software), is one that speaks for itself.
I disagree. Often if I'm making a PR to an open-source project I'm doing so because I have a use-case that the original author hadn't considered. So the first step in getting the PR merged is explaining my point of view and convincing the maintainer that my use-case is valid. Only when this is done can the "goodness" of the patch be evaluated.
Well, I dunno. Sometimes the fix speaks for itself but the other party is as dumb as a box of rocks and doesn’t understand. It can be hard to tell the difference.
> I also don't want to be an asshole to my community & reject all their changes.
Do they pay you to triage their noise?
Remember that you owe no one anything at all. Neither legally nor morally.
Your chosen license likely even states the former in plain english.
___
Personally, I've adopted the "you annoy me, you're out" stance and have been quite happy with it. You do need a tough shell to do that though as you will be facing all the social exploits people can throw at you.
It also leaves "growth potential" on the table, the same way that limiting your exposure to ionizing radiation does.
That all said, it depends on what your goals are + where in the lifecycle of your project you are.
So don't take this as "this is the way" but "this can be one way".
Either way, you're not an asshole for not reading slop. Don't let anyone gaslight you into that.
When you put it that way, i disagree. A gift is a gift. Once you give it to someone its their's to do with as they please. A gift with strings is not a gift.
This story is different though, the farmer sold the land for cheap in exchange for some conditions. This situation is more like going back on a contract.
If we are extending this metaphor, given the property passed through many hands, i feel like the equivalent would sort of be like giving a friend a gift, the friend eventually dies, their children sell it when dealing with the estate because they dont have use for the item.
I don't think the metaphor extends. A family gave their city land conditionally, decades went by, and then the city sells the land do develop a data center.
I don't understand what type of cope you are trying to achieve by excusing this as an okay thing to do.
Umm so if the deed had a legally binding condition on it, why is that condition being ignored? The article doesn't say what the rationale was. Was the condition not legally binding in texas? Is there some time limit on it? Something else? What is the legal excuse being used?
I agree that the OP article isn’t great - deep in the article it seems to say it’s legal but doesn’t explain why, even though the article goes into detail on less important matters.
Regardless, the government says there was never a “deed restriction” but they say there was something else which I don’t understand:
> In the notes about the grantee, the cash warranty deed states that the property was to be held in trust for future use as parkland by Williamson County, Texas. This was not a deed restriction.
reply