1175 points by CrankyBear 110 days ago | 886 comments on HN
| Mild positive
Contested
Landing Page · v3.7· 2026-02-28 11:40:52 0
Summary Developer Labor Rights Advocates
This webpage presents a newsletter subscription gate obscuring the article on FFmpeg developers' demand for Google funding or relief from unsupported bug reports. Based on observable title and metadata, the article advocates for open-source developers' labor rights (Article 23) and intellectual property recognition (Article 27), while the structural design raises significant privacy concerns (Article 12) through extensive personal data collection and commercial tracking infrastructure.
I get the idea of publicly disclosing security issues to large well funded companies that need to be incentivized to fix them. But I think open source has a good argument that in terms of risk reward tradeoff, publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
A bunch of people who make era-defining software for free. A labor of love.
Another bunch of people who make era-defining software where they extract everything they can. From customers, transactionally. From the first bunch, pure extraction (slavery, anyone?).
I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.
"They could shut down three product lines with an email"
If you (Amazon, in this case) can put it that way, it seems like throwing them 10 or 20 thousand a year would simply be a good insurance policy! Any benefits you might get in goodwill and influence are a bonus.
Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”
I agree with the headline here. If Google can pay someone to find bugs, they can pay someone to fix them. How many time have managers said "Don't come to me with problems, come with solutions"
The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it.
Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.
I don't understand the rational for announcing that a vulnerability in project X was discovered before the patch is released. I read the project zero blogspot announcement but it doesn't make much sense to me. Google claims this is help downsteam users but that feels like a largely non-issue to me.
If you announce a vulnerability (unspecified) is found in a project before the patch is released doesn't that just incentivize bad actors to now direct their efforts at finding a vulnerability in that project?
I'm not being dismissive. I understand the imperetive of identifying and fixing vulnerabilities. I also understand the detrimental impact that these problems can potentially have on Google.
What I don't understand is the choice to have a public facing project about this. Can anyone shine a light on this?
It’s a reproducible use-after-free in a codec that ships by default with most desktop and server distributions.
The recent iOS zero-day (CVE-2025-43300) targeted the rarely used DNG image format. How long before this FFMPEG vulnerability is exploited to compromise legacy devices in the wild, I wonder?
I’m not a fan of this grandstanding for arguably questionable funding. (I surely would not fund those who believe these issues are slop.) I’d like to think most contributors already understand the severity and genuinely care about keeping FFMPEG secure.
I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, they reported it. If it's a valid bug then it's a valid bug end of story. Software owes it to its users to be secure, but again it's up to the maintainers if they also believe that. Maybe this pushes Google to make an alternative, which I'd be excited for.
They should set up a foundation/LLC if they don't have one already and require a support contract for fixing any bugs in niche codecs. Target the 95%-98% use cases for "free" work. If someone gives them a CVE on something ancient, just note it with an issue tracker and that the problem is currently unsponsored. Have default build flags to omit all the ancient/buggy stuff. If nobody is willing to pay to fix all the ancient crap, then nobody should be using it. But if someone is willing to pay, then it gets fixed.
There are some rhetorical slights of hand. If Google does the work to find and report vulnerabilities, great. Nice contribution regardless of who provides it. The OSS developer can ignore it by accepting the consequences that will be. They are not forced to fix it except by themselves.
The many large corporations should be funding these tools they depend on to increase time allocations and thus ability to be responsive but this isn't an either/or. These type of thinking erode the communities of such projects and minds of the contributors.
FWIW I've totally been that developer trapped in that perspective so I empathize, there are simply better mental stances available.
Honestly, I kind of think that ffmpeg should just document that it's not secure and that you're expected to run it in a sandbox if you plan to use it on possibly-malicious input. All the big cloud users and browsers are doing this already, so it would hardly even change anything.
ffmpeg is complaining that security bugs are such a drag that it's driving people away from their hobby/passion projects. Well, if fixing security bugs isn't your passion, why not just say that? Say it's not your priority, and if someone else wants it to be a priority, they can write the patches. Problem solved?
So what if ffmpeg has open CVEs? What is Google going to do? Swap it? Leave them open, let Google ship products with CVE'd dependencies, and then they'll be forced to act.
Why would Google act if they got smart guys working for them for free? Stop fixing Google-reported bugs.
I think the glaring issue underlying this is that the big companies are not investing enough in the tools they rely on.
I agree with some of the arguments that patching up vulnerabilities is important, but it's crazy to put that expectation on unpaid volunteers when you flood them with CVE's some completely irrelevant.
Also the solution is fairly simple: Either, you submit a PR instead of an issue. Or, you send a generous donation with the issue to reward and motivate the people who do the work.
The amount of revenue they generate using these packages will easily offset the cost of funding the projects, so I really think it's a fair expectation for companies to contribute either by delivering work or funds.
As much as I hate to be on Google's side I think they're doing a reasonable thing here. Valid bug reports are valuable contributions on their own, and disclosing security issues is standard practice. Not disclosing them doesn't help anyone. Security through obscurity is not security. If neither FFMPEG nor Google dedicate resources to fixing the issue in 90 days, making it public at least ensures that it gets visibility and thus has a higher chance to get fixed by a third party.
I'm sure Google could (and probably should) do even more to help, but FFMPEG directing social media rage at a company for contributing to their project is a bone-headed move. There are countless non-Google companies relying on FFMPEG that do much less for the project, and a shit show like this is certainly not going to encourage them to get involved.
Should Google be doing more to support ffmpeg? Yes.
Should Google stop devoting resources to identifying and reporting security vulnerabilities in ffmpeg?
I cannot bring myself to a mindset where my answer to this question is also "yes".
It would be one thing if Google were pressuring the ffmpeg maintainers in their prioritization decisions, but as far as I can tell, Google is essentially just disclosing that this vulnerability exists?
Maybe the CVE process carries prioritization implications I don't fully understand. Eager to be educated if that is the case.
In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so.
Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report.
My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it.
To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works
> publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
Not publicly disclosing it also carries risk. Library users get wrong impression that library has no vulnerabilities, while numerous bugs are reported but don't appear due to FOSS policy.
How do you think Jeff got a 500 million dollars yacht? Not by writing checks.
But on a more serious note, it is crazy that between Google and Amazon they can not fund them with 50k each per year, so that they can pay people to work on this.
Specially Google, with Youtube, they can very easily pay them more. 100k~200k easily.
If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.
Notably, the vulnerability is also in a part which isn't included by default and nobody uses. I'm not sure that even warrants a CVE? A simple bug report would have probably been fine. If they think this is really a CVE, a bug fix commit would have been warranted.
You are missing the tiny little fact that apparently a large portion of infosec people are of the opinion that insecure software must not exist. At any cost. No shades of gray.
> But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it
I think this is the heart of the issue and it boils off all of the unimportant details.
If it's a real, serious issue, you want to know about it and you want to fix it. Regardless of who reports it.
If it's a real, but unimportant issue, you probably at least want to track it, but aren't worried about disclosure. Regardless of who reports it.
If it's invalid, or AI slop, you probably just want to close/ignore it. Regardless of who reports it.
It seems entirely irrelevant who is reporting these issues. As a software project, ultimately you make the judgment call about what bugs you fix and what ones you don't.
> publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.
You can never be sure that you're the only one in the world that has discovered or will discover a vulnerability, especially if the vulnerability can be found by an LLM. If you keep a vulnerability a secret, then you're leaving open a known opportunity for criminals and spying governments to find a zero day, maybe even a decade from now.
For this one in particular: AFAIK, since the codec is enabled by default, anyone who processes a maliciously crafted .mp4 file with ffmpeg is vulnerable. Being an open-source project, ffmpeg has no obligation to provide me secure software or to patch known vulnerabilities. But publicly disclosing those vulnerabilities means that I can take steps to protect myself (such as disabling this obscure niche codec that I'm literally never going to use), without any pressure on ffmpeg to do any work at all. The fact that ffmpeg commits themselves to fixing known vulnerabilities is commendable, and I appreciate them for that, but they're the ones volunteering to do that -- they don't owe it to anyone. Open-source maintainers always have the right to ignore a bug report; it's not an obligation to do work unless they make it one.
Vulnerability research is itself a form of contribution to open source -- a highly specialized and much more expensive form of contribution than contributing code. FFmpeg has a point that companies should be better about funding and contributing to open-source projects that they rely on, but telling security researchers that their highly valuable contribution is not welcome because it's not enough is absurd, and is itself an example of making ridiculous demands for free work from a volunteer in the open-source community. It sends the message that white-hat security research is not welcome, which is a deterrent to future researchers from ethically finding and disclosing vulnerabilities in the future.
As an FFmpeg user, I am better off in a world where Google disclosed this vulnerability -- regardless of whether they, FFmpeg, or anyone else wrote a patch -- because a vulnerability I know about is less dangerous than one I don't know about.
Yes - more than a sour taste. This is hideous behavior. It is the polar opposite of everything intelligent engineers have understood regarding free-and-open software for decades.
Maybe for a small project? I think the difference here is rather minimal. Everybody "knows" code often has security bugs so this announcement wouldn't technically be new information. For a large project such as ffmpeg, I doubt there is a lack of effort in finding exploits in ffmpeg given how widely it is used.
I don't see why actors would suddenly reallocate large amounts of effort especially since a patch is now known to be coming for the issue that was found and thus the usefulness of the bug (even if found) is rather limited.
Use After Free takes 3 seconds to fix if you defer free until the end of the program. If you have to do something else, or you don't want to leak memory, then it probably takes longer than 3 seconds.
Probably the right solution is to disable this codec. You should have to make a choice to compile with it; although if you're running ffmpeg in a context where security matters, you really should be hand picking the enabled codecs anyway.
This is why many have warned against things like MIT licence. Yes, it gives you source code and does easily get incorporated into a lot of projects but it comes at the cost of potential abuse.
Yes, GPL 3 is a lot ideologically but it was trying to limit excessive leeching.
Now that I have opened the flood gates of a 20 year old debate, time to walk away.
I would imagine it's mostly a PR/marketing thing. That way the researchers can point to being part of something other people know about, and Google gets positive PR (though maybe not in this case) for spending resources on making software in general more secure.
I read this as nobody wants CVEs open on their product, so you might feel forced to fix them. I find it more understandable if we talk about web frameworks: Wordpress don't want security CVEs open for months or years, or users would be upset they introduce new features while neglecting safety.
I am a nobody, and whenever I found a bug I work extra to attach a fix in the same issue. Google should do the same.
Project Zero's public existence came out of the post-Snowden period where Google was publicly pissed at the NSA/etc for spying on them (e.g. by tapping their fiber links).
1) dedicating compute resources to continuously fuzzing the entire project
2) dedicating engineering resources to validating the results and creating accurate and well-informed bug reports (in this case, a seriously underestimated security issue)
3) additionally for codecs that Google likely does not even internally use or compile, purely for the greater good of FFMPEG's user base
Needless to say, while I agree Google has a penny to spare to fund FFMPEG, and should (although they already contribute), I do not agree with funding this maintainer.
A lot of their research involves stuff they personally benefit from if they were secure. ffmpeg, libxml2, various kinds of mobile device firmware, Linux kernels and userspace components, you name it.
Their security team gaining experience on other projects can teach them some more diversity in terms of (malware) approaches and vulnerability classes, which can in turn be used to secure their own software better.
For other projects there's some vanity/reputation to be gained. Having some big names with impressive resumes publicly talk about their work can help attract talent.
Lastly, Google got real upset that the NSA spied on them (without their knowledge, they can't help against warrants of course).
Then again, there's probably also some Silicon Valley bullshit money being thrown around. Makes you wonder why they don't invest a little bit more to pay someone to submit a fix.
Bugs in little-used corners of the project are a massive red flag, that's how some of the most serious OpenSSL bugs have emerged. If the code is in there, and someone can trigger it with a crafted input, then it is as bad as any other bug.
Unfortunately, nobody not on Twitter can see anything except the first message, which just appears to be some corporate-deflection-speak.
It’s a trillion dollar company. I’m sure they could find rifle through their couch cushions and find more than enough money and under-utilised devs to contribute finance or patches.
Nice to see coming from Google. Some other current and form Google employees were unfortunately not as professional in their interactions on Twitter in regards to this issue.
And pushing forward the idea that "responsible disclosure" doesn't mean the software creator can just sit on a bug for as long as they want and act superior and indignant when the researcher gives up and publishes anyway because the creator is dragging their ass.
I've been a proponent of upstreaming fixes for open source software.
Why?
- It makes continued downstream consumption easier, you don't have to rely on fragile secret patches.
- It gives back to projects that helped you to begin with, it's a simple form of paying it forward.
- It all around seems like the "ethical" and "correct" thing to do.
Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.
I have a very distinct recollection of talks about hardware aspirations and upstreaming software fixes at a large company. The cultural response was jarring.
> The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.”
This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is a polite reading. I get that it's a bug either way, but this leaves me with a vague feeling of the ffmpeg maintainer's time being abused.
Title directly engages Article 23 labor rights. 'Fund Us' explicitly frames compensation claim for developer work. 'Stop Sending Bugs' implicitly addresses uncompensated labor: developers fielding unsupported bug reports without compensation. Article advocates that Google (major beneficiary of FFmpeg) should recognize and pay for developer labor.
FW Ratio: 60%
Observable Facts
Title: 'FFmpeg to Google: Fund Us or Stop Sending Bugs' explicitly demands funding ('Fund Us') and relief from unpaid labor ('Stop Sending Bugs').
Article categorized under open-source, a domain characterized by massive unpaid developer contributions.
The phrasing positions unsolicited bug reports as a form of unpaid work burden on maintainers.
Inferences
The 'Fund Us' demand directly asserts developers' right to fair compensation for their labor (Article 23), framing open-source development as legitimate work requiring payment.
By positioning Google as obligated party, the framing recognizes corporate entities as duty-bearers under UDHR labor protections.
Article engages Article 27 (moral and material interests in intellectual works). FFmpeg is substantial creative intellectual property. Title 'Fund Us' frames compensation demand for developers' intellectual contributions. Article advocates that creators of intellectual works (FFmpeg) deserve material benefit, particularly from corporate users (Google).
FW Ratio: 60%
Observable Facts
Article subject: FFmpeg, a complex intellectual work / open-source software framework.
Title frames compensation ('Fund Us') in direct relation to Google's use/benefit from this intellectual property.
Article advocates for developer recognition and material benefit from their creative code contributions.
Inferences
The 'Fund Us' framing implicitly asserts creators' right to moral and material recognition in their intellectual creations (Article 27).
Positioning Google as obligated beneficiary establishes corporate duty-bearing responsibility for recognizing creator interests in the intellectual works they use.
Page title 'FFmpeg to Google: Fund Us or Stop Sending Bugs' positions open-source developer grievances as newsworthy advocacy. The framing supports journalists' and developers' right to voice demands to corporate stakeholders. Technology journalism platform inherently supports free expression.
FW Ratio: 60%
Observable Facts
Page title frames advocacy: 'FFmpeg to Google: Fund Us or Stop Sending Bugs'.
Website categorizes content under open-source, cloud-native, containers, and other tech topics supporting information dissemination.
Article content is behind newsletter subscription gate, requiring personal data submission to access.
Inferences
The title's direct-address framing to Google (a corporate duty-bearer) advocates for developers' right to voice labor-related demands, supporting free expression principles.
The paywall creates structural tension: journalism mission supports Article 19, but subscription model restricts information access.
Subscription form explicitly requests: first name, last name, company name, country, job level, job role, employees in organization, organization type, organization industry, and LinkedIn profile URL.
Page includes Google Tag Manager tracking pixel (noted in DCP implementation).
Form statement: 'The New Stack does not sell your information or share it with unaffiliated third parties' acknowledges data handling but does not address retention, internal use, or duration.
Inferences
The breadth and depth of personal data collection (11 fields including professional metadata and LinkedIn) combined with commercial tracking infrastructure indicates systematic profiling for marketing purposes.
The privacy notice negates sale/sharing but does not address secondary processing or data retention, suggesting incomplete privacy safeguards relative to Article 12 expectations.
Observable Google Tag Manager implementation and user ID tracking via cookies indicate data collection practices. Privacy policy existence not directly observable from provided content.
Terms of Service
—
Terms of service not observable in provided page content.
Identity & Mission
Mission
+0.10
Article 19
Technology journalism focus inherently engages with free expression and information dissemination values.
Editorial Code
—
Editorial standards/ethics policy not observable in provided content.
Ownership
—
Ownership structure not observable in provided page content.
Access & Distribution
Access Model
0.00
Access model cannot be determined from provided HTML fragment.
Ad/Tracking
-0.15
Article 12
Google Tag Manager and category-based advertising tracking observed, suggesting behavioral data collection for commercial purposes.
Accessibility
+0.05
Article 19
Semantic HTML structure and responsive design patterns observed suggest baseline accessibility consideration, though full accessibility audit not possible from provided code.
Website structure (category navigation, open-source topic taxonomy) supports information dissemination. However, paywall gate restricts access to full article, limiting public's right to 'receive and impart information' per Article 19.