Perhaps eventually, they can finally live up to their namesake. On January 1 2029, we will move to a "Full 0" policy where vulnerabilities are disclosed after (looks at camera) zero days.
That does not follow. Somebody stills needs to set it up. And maybe to sign off. The AI could instantly diagnose and summarize the problem and its remediation and you say the word.
The way you describe it puts the role of humans as merely decorarive and ceremonial. The work is done by AI and actually validated by AI too, and increasingly the role of the human is to give an ok to whatever the AI outputs
No, that's not what it means. It just means that the benefit must outweigh the risk, as always. Making surgical patches to existing code is also quite different to introducing features, which is what developers typically spend their time on. Not that same-day patching would imply literally zero time to review either.
We can extrapolate from the last two years now that it's older than that. In 2024, although vibe coding hadn't been coined yet, AI was being used to autocomplete lines and functions with the tab key. Now it is autocompleting entire programs with a chat interface. In another two years it may be autocompleting whole projects with a neural interface.
IMO the disclosure should ~day-two after there is a fix/workaround available
Releasing before that is non-actionable by many actors (aside from taking the service completely down I guess). Any time after fix is available is just allowing vulnerable systems to be attacked and is playing favourites with who gets fix and who doesn't
I thought they made a strong case for removing the additional 30 day patch rollout time. But reducing the entire process to 30 days total seems needlessly harsh and I didn't think it was justified by the article at all. What if the bug is actually inherently hard to fix?
Every piece of software you have ever used almost certainly has critical security vulnerabilities, right now, no matter how up to date it is. However, you don't know about them and neither does anyone else.
Crowdstrike was a good example of why you should never allow global updates to roll out all at once , even for configuration changes.
Cloudflare has learnt the same lesson recently https://blog.cloudflare.com/18-november-2025-outage/
Bug fix speed isn’t particularly relevant, rollout speed is.
Two week rollouts are insane. Three days, in the vast majority of contexts, is generous.
I hate to see slow rollouts. The single best thing you can do for fighting bugs is to roll out with canaries; weekslong rollouts only make sense when someone actually has to be in the middle of a cursed release while it runs.
If there's a bug in your code and it's rare there isn't much disruption. If it's not rare, why didn't your tests catch it?
You're both missing the point. The actual issue is llm exploit generation. If they can find it, so can other bad actors. We can't sit on issues anymore the time to exploit is now tiny or negative in some cases.
lol, and if its in a widespread library in an embedded device? Thanks for compromising the internet, aka there is a tension inherent, not that i disagree with policy and the forcing function underneath, but it is quite a different perspective for non corporate projects.
This is ridiculous. Vulnerabilities doesn't mean it necessarily can lead to any real damage. But go ahead and mandate this. Let's do it. Better yet, let's register all unable to be patched devices and give the government the right to smash those devices if they don't get updates. That's the world I want to live in.
If you have an embedded device connected to the Internet that doesn’t get updates and has vulnerabilities that can be picked up by LLMs then you need to unplug it.
That is the world we live in now and pretending otherwise is reckless and leads to mass hacking like the recent supermarket fridge hacking.
Only devices and applications that can respond to security reports quickly should be connected to the internet.
Lots and lots of devices are gonna get turned into botnets and tons of personal information is going to get leaked. However both of those things are already true.
Constant attacks mean the future will hopefully see local-first devices that don't need software at all.
Want to put them on the internet? They go behind gateways which are better maintained, because a world where every teenager can hack a vending machine through its vestigial Bluetooth stack would finally need to be secure to function.
(Now the fridges could be updated, and some supermarkets announced that they'd updated some, most of all of their fridges, either before the hacking, or after the first incident.)
You should not connect a service maintained by individuals in their free time to the public internet. Put it behind a VPN or local network only and then you don’t have to worry.
Delaying disclosures is a false sense of security when the attackers are running the same scans Google is. They will have exploits faster than 30 days.
This is the kind of thinking that in the 90s would have kept the internet exclusive to the domains of university and government. Every new technology has risks and people adapt. In the early part of the 20th century we might as well have kept cars away from private citizens and relegated transportation to buses, trains and professional drivers. Need private transportation? Use a horse. What with the number of people killed and maimed every year it's just not worth it. Take away our keys and mandate public transportation please.
No. People will stop caring because they do not wish to have the extra stress of this. Which kills open source and therefore a lot of collaboration and innovation. Not to mention killing the open internet.
That would be the problem of the people running the software, not writing it.
Considering the direction software and their exploits are going with AI, if 30 days is insufficient in 2028 then that's useful signal to the people running that they should move elsewhere.
Only until cybersecurity liability legislation finally starts to kick in, then those writing it will have a solid reason to assign the necessary resources to make it happen.
Any sensible legislation will unconditionally exempt the authors of FOSS software. If that is ever not the case the logical consequence is all FOSS contributors moving to pseudnonymous identities and collaborating exclusively via tor.
For example see the EU cyber resilience act (regulation 2024/2847). It sets out nuanced rules regarding FOSS.
If you simply run or contribute to a FOSS project then you don't have any obligations, those kick in when you distribute software for profit and your obligations scale with the size of your business. Companies that fail to promptly address security vulnerabilities will face strict liability for damages.
>Only until cybersecurity liability legislation finally starts to kick in
In America software is protected by the First Amendment, so most software (and all open source for sure) cannot be subjected to "cybersecurity liability" of the sort you seem to be envisioning. Congress could have an angle when it comes to stuff that is sold, including in particular hardware and subscription services though there will be both plenty of lobbying and plenty of potential landmines involved in any such effort.
But with anything free there is no commercial angle involved, no contract. It's just speech that's put out there, identical to the posts we're writing here on HN right now. Software bugs aren't true threats, incitement, defamation, or obscene.
Other countries of course could take a different tack, but they'd then face "OSS becomes fully American" and I'm deeply skeptical that'd work politically.
There is this thing called soverignity where goveremnts can legally track down the citzens who fails to comply, and whose actions can endager the country in whatever means the forces in power decide it may be.
Also when US gets a saner goverment back, I am quite sure CISA will have yet another opinion on the matter, especially if national security is considered exposed in some media case.
>There is this thing called soverignity where goveremnts can legally track down the citzens who fails to comply, and whose actions can endager the country in whatever means the forces in power decide it may be.
Perhaps in your authoritarian fever-dreams or whatever shithole country you current reside in, but no in the US.
>Also when US gets a saner goverment back, I am quite sure CISA will have yet another opinion on the matter, especially if national security is considered exposed in some media case.
I see only two possibilities. Either it's a proprietary product that should either be rapidly fixed by the vendor or abandoned by the customer. Or it's a FOSS project in which case the end user can simply request his LLM of choice to patch it for him. I honestly see no issue here. It isn't how things used to work even as recently as a year ago but it seems to be the only sensible way they can work going forward.
Google isn't doing this because they think this is best for all of this. They are doing it because it is best for Google. This is like when companies say they hate regulation, except for when they can weaponize it to bully (smaller) competition.
After reading the first line of the comment I thought it was a criticism that 30 would be way too _long_ of a deadline in 2028
With AI assisted vulnerability research the relative edge of project zero is going down - anything they can find can likely be found by others in a similar timeframe. We see this today with the parallel discovery of php2shell by many groups in the same few weeks
You misunderstand - denying patches to downstream vendors improves financial security for Google.
But they actually did this to comply with the EU Cyber Resilience Act. When a patch is released, a legal clock starts ticking - anyone who doesn't apply it promptly is liable for any resulting damages.
We have found a large number of vulnerabilities in major open-source projects at HunterSwarm[0], and we're disclosing them on a typically 30-day timeline, but we're working with the projects. I personally think 90 days is way too long.
(With customers, however, we integrate right into their CI-CD, but because of the nature of our work, we can only work with certain customers. Major open source projects, however, have a lot of stakeholders and typically no budget, so we just try to help them as much as we can.)
I’m not familiar with this specific effort but it seems like the companies digging around for the bugs should also offer similar access to their products that discovered the vulnerabilities to the vendors or OSS projects to patch them. Otherwise vendors might use this as a leveraged approach to get people to adopt LLMs, specifically theirs, so their products remain reasonably attractive. Google, OpenAI, Anthropic etc could just turn on existing software as a strategy to get more adoption of their tools.
“Don’t like our constant stream of patches? For $10k/mo + tokens you can get access to the model to patch the vulnerabilities we disclose!”
Usually you can’t find the kind of bugs P0 finds by just throwing AI at it. You need highly skilled people driving/guiding it. Highly skilled people are the bottleneck.
In any case it’d be sensible to make yourself familiar with the “specific effort” before you make up your opinion on it.
For sure I would love to get access to P0 researchers for a m 10k/months, but i don’t believe you can hire such talent for this sum.
They are one of or maybe the most skilled security research team that’s doing public research and their blog is the source of many modern exploitation techniques
For a while, asking your agent to act like a P0 researcher was a nice nudge to find better bugs !
That's kinda the problem with asinine "safety" idea the AI moguls have.
It is just leaving people with less safe software. At least claude the limitations are actively preventing you from looking for security bugs in your own software
Your argument makes complete sense if the tools that find a bug can automatically make a patch, but a vendor getting a thorough bug report can't make a patch with anywhere near the same amount of ease.
But that assumption is pretty crazy to me and your argument makes no sense to me.
Running trivy scans on my docker containers has really highlighted which projects keep up to date. I’ve been moving away from all the one person projects to more commercial offerings that keep on top of updates.
Of course I don’t expect a single person to work every day for free, but I also can’t have a project with only a single dev exposed to the internet.
It makes to hold out for disclosure if there's a pay day involved. Since this is Google, the bug bounty is not the issue. I say release right away. Nothing else will compel the company being reported on to fix otherwise.
Is this a version of extortion? Isn't this Google, a massive company with lots of power and control, forcing the prioritization of work on everyone under the guise of security? It's at least clearly a threat.
Project Zero doesn't create the vulnerabilities, it finds them. Vendors want unlimited time to fix their bugs. Users want to know ASAP if the software they are running is vulnerable. These things are obviously in tension, so you need a deadline.
It's gotten easier finding vulnerabilities, so every day without disclosure now brings a higher chance that blackhats have already found the bug. The deadline gets shorter accordingly.
Calling vulnerability research "extortion" is the kind of ignorant messenger-blaming the hacker culture has always ridiculed.
You directly called it "clearly a threat", and you indirectly called it plausibly extortion or else there would be no reason to ask if it's extortion.
But you need to explain on what general basis this even could be extortion.
And they're not "forcing the prioritization" of anything. They're just reporting bugs they found. They don't even need to warn the vendors at all if they don't want to.
You are ignoring the part of Project Zero that reports the vulnerability.
Neither the users nor the vendors chose the 90/60/30 day limit.
Google is making an active choice in the design of their reporting process, and that is something that is open to critique and in some sense liability.
Why is Google choosing to report unlimited number of bugs, but a different Google program will only pay to fix 3 bugs? (https://bughunters.google.com/about/rules/open-source/patch-...) Why are not all Project Zero bugs exempt from that limit and awarded a minimum reward?
the bug exists regardless of p0. either p0 reports it and users can mitigate its impact or p0 doesn't report it and someone else finds it and users are exploited.
if anything liability is on vendors that claim to be secure but actually aren't.
and sounds like you want a free money printer: write bugs, report to p0, get money to fix it.
Not necessarily. This view contains an inherent contradiction. If the bugs require skill to find, then Project Zero makes sense because it donates that skill. But if the bugs require skill to find, then "someone else finds it" stops being certain. Alternatively, if the bugs don't require skill to find, then Project Zero is not actually doing anything valuable.
So it is absolutely possible that nobody would ever find a memory corruption bug in a Lucas Arts SCUMM VM video transcoder if Project Zero didn't go poking around.
But because they did, and chose NOT to fund the fix, they DO carry some fault for anyone who acts on the bug after they disclosed it. Or if it is fixed in time, they must accept responsibility for consuming resources of a project they use but did not contribute to.
And the free money printer argument is absurd. The projects that Google uses are notable enough that writing bugs on purpose would be self-defeating. A project that write bugs on purpose would simply lose all users and nobody would care anymore.
Did the projects ask for vulnerability scanning from Google?
Did they ask Google to decide how quickly they need to fix reported vulnerabilities?
Same free will Google uses to decide to spam them with reports, they could use to exempt those fixes from the 3 per month limit in Google’s already existing vulnerability fix reward program.
They don’t _have to_. But then I am free to call them out on it.
I think you're confused. Google isn't paying other people to fix bugs in their own software. Google pays people to find bugs in Google software so that they can fix it. The same service they are providing to other software projects, for free, they pay individuals for because finding bugs in Google software helps Google to improve it.
> Did the projects ask for vulnerability scanning from Google?
Do projects ask hackers to hack them?
> Did they ask Google to decide how quickly they need to fix reported vulnerabilities?
It is irrelevant and this is the point you don't get: Google is not forcing anyone to do anything. They just say "I found this problem in your software, I am notifying you and in 30 days from now the whole world will know. Do what you wish with this information."
> They don’t _have to_. But then I am free to call them out on it.
It is the internet, do whatever makes you sleep better at night.
> Neither the users nor the vendors chose the 90/60/30 day limit.
Well, vendors can be more invested in building secure software and users get a lesson in why the "Check for updates" button exists in many devices' configuration options.
Google is not liable in any way for the vulnerabilities it finds.
Google is liable for their actions. In particular, Google is liable for choosing 90, 60 and 30 days waiting time.
What happens if a project has a vulnerability disclosure policy with a mandatory 90 day period, and Google ignores it starting 1.1.2027 and releases after 60 days?
You might wish that, but in the US at least they literally are not. There is no "security bugs" exception to the First Amendment. Anyone who finds one is perfectly free to shout it to the world instantly, or never, or anything in between. There is no gray area or complexity here as a matter of law. As a matter of morals, it is quite complex, and only getting more so in the age of LLMs. It was always the case that knowing a bug existed will let operators do "something" whether there is a patch or not, even if that something is "shut off all network access until patched", and it was always the case that anything one party can discover somebody else could at any moment, or at any earlier point from release before the second discoverer. LLMs can tremendously accelerate the discovery angle and expand the parties likely to do it, and might also speed up patching even by users of the software vs the devs.
>What happens if a project has a vulnerability disclosure policy with a mandatory 90 day period, and Google ignores it starting 1.1.2027 and releases after 60 days?
They can apply any social or economic pressure they're able to, otherwise too bad for the project? They can set whatever policy they want, nobody else is under any obligation to follow it unless contractually obligated.
See but I do wonder if it would be less liable for them to literally shout it out instantly.
It’s not the vulnerability that is the problem, it’s the timeline.
That’s what the original article is about. The 90-60-30 limit is something Google actually chooses, and that is not a first amendment issue.
Imagine a research found a vulnerability in Google and said, “You have 90 days to transfer 1 000 000 to my account or I will make the vulnerability public”. Pretty sure that would be considered actual blackmail and would be illegal.
It’s kind of tricky to see where the line would be. Google is effectively saying “You have 90 days to fix this vulnerability, in the software we use to make billions, or we will make the vulnerability public”. It’s not a huge difference. At best, you could argue it’s two different departments: one that find vulnerabilities and the other that makes money from the project.
>See but I do wonder if it would be less liable for them to literally shout it out instantly.
Wonder no more. They have zero liability either way.
>That’s what the original article is about. The 90-60-30 limit is something Google actually chooses, and that is not a first amendment issue.
Uh. Choosing time/place for speech is absolutely a 1A issue. Google (and you, me, and anyone else) is completely protected from legal action in how and when they make a unilateral decision to speak using their own resources.
>Imagine a research found a vulnerability in Google and said, “You have 90 days to transfer 1 000 000 to my account or I will make the vulnerability public”.
Yes, as you say that'd be blackmail but that's completely irrelevant to anything you have said or anything in this case. Google is not demanding money.
>It’s kind of tricky to see where the line would be.
No. It's not actually. Blackmail is extremely well defined in law and caselaw. No demand for anything? No blackmail.
>“You have 90 days to fix this vulnerability, in the software we use to make billions, or we will make the vulnerability public”. It’s not a huge difference.
Yes, it's a huge difference, even if you were being honest in your statement, which you aren't. Google doesn't have any "or we", they just say "when we find something, we've decided we'll generally try to let you know, and then at X time later we'll disclose it no matter what you do or don't do, so that then other mitigations can happen, unless we feel like doing differently." Which is 100% fine. Somebody can fix the vulnerability they introduced themselves, or not. Or they can try to get someone else to do it (depending on the project and whether Google cares, it might well be a Google engineer or LLM who offers a patch). Once it's out there, everyone else who uses said software can also try to patch or otherwise ameliorate it or move to something else, based on their own considerations, or not. That's just... normal society and market of ideas? And it doesn't make any difference is whether Google makes billions or zero dollars.
There’s a pretty big difference between saying “pay me hush money or I release this vulnerability” and saying “we found this vulnerability and we’re going to publicly disclose it in 30 days”.
This is sort of what I was getting at with my original post. I'm just curious as to the power dynamics here. Not everyone has $0.5 trillion in revenue every year.
Why does it take Google scale to address reported security vulnerabilities in a timely manner?
And if something is just a personal / hobby project that you don't want to support - that's also fine. Having the security vulnerability published just means people using it have a more realistic view of the situation.
You know that colleague at work who goes around "helpfully" and constantly making suggestions about how you could improve your work and even criticising you in front of your boss?
Yeah they're not doing it to help you but to sabotage you.
But when challenged they profess they're just trying to be "helpful"
What do you think Google is extorting from the publishers of insecure software - reduced security vulnerabilities? Or what is it that you think Google is actually after by doing this?
> guise of security
What do you think is the real motivation if not security?
I read the linked article and can't find anything involving extortion; just that one person associated with the FFMPEG didnt like the flood of vulnerability reports.
In fact, the article cites one of the FFMPEG maintainers as being grateful for the vulnerability reports.
Yes. You are missing the wider interpretation of the word extortion that includes obtaining benefit by coercion. Presumably you are only including extortion by use of blatantly illegal means in your definition. However, you don't need to threaten using illegal means to be extorting and/or blackmailing someone. You can be blackmailing someone by threatening to sue them in court, for example.
Google is extorting benefit, specifically fixes to software it heavily depends on for its multi billion dollar business, by coercion, specifically by actively threatening the project with reputational damage in 90 days if certain action is not taken, even if the action is not in the vendors best interest.
As a thought experiment, imagine if Google was reporting this to the project, but _without_ the 90 day limit. The one that the original article describes going down to 60 then 30 days. Yes, you might first think "that will cause the projects to never fix bugs" which might be true for some projects, but you do realize how legally that would completely change the dynamic between Google and the project and remove the entire extortion part from the picture? Or indeed, if they simply published it without any notice at all.
Whether or not other people also happen to benefit is related, but it doesn't remove the fact that Google also benefits.
Or if you would like a more vivid picture:
If the Mob forces you to give them a room in your hotel for illegal poker tournaments and then gives you tips on how to make the windows safer so that bricks can't fly through them, it does improve safety for all your clients but it's still extortion.
If google stops sending ffmpeg vulnerability reports the software will still be vulnerable but neither the maintainers nor the end users will be aware of it. As someone who makes use of ffmpeg I want google to continue sending such reports. If I'm running vulnerable software I very much want to know about it.
I agree with you. Google pretends that this is "donating security research to the community" and maybe it started like that, but it has been clear for some time that there is an element of bullying and abuse in the process that they are conveniently ignoring to be able to sleep better at night.
And Google has a vested interest in FFMPEG, because it uses it heavily to transcode and process videos. So they absolutely benefit from the work, for free.
That story is basically what I'm getting at, although I didn't know about that particular story. At a certain level of product, organization, and severity of bug, Google's threat to publish the vulnerability forces the hand of organizations to prioritize the fix since it will then be exposed. But that could be disruptive and unproductive, as the story you linked points out.
How is it extortion? Google does not create the vulnerabilities. It just validates them and makes the details public. It is a public service for everyone.
The first party and flagship security patch chain was always fast. The real issue is the bottom-of-the-barrel third party budget sector chain. They already need 6+ months (if they patch at all) despite 90 days disclosures having been industry standard for a while. Tightening these timelines won't make them care, it will only increase threat levels for low-income users.
I hate to say this, but that's a good thing IMO. It will serve to either force those companies to finally start caring to fix their process or it will force the relevant users to get hacked until they vote with their wallets or (less likely) possibly force bootloaders to be unlocked or perhaps governments to finally step in and mandate some minimum level of software maintenance.
The tools enabling these exploits exist and aren't going away so burying our collective heads in the sand by allowing messes to be swept under rugs isn't a productive response.
> perhaps governments to finally step in and mandate some minimum level of software maintenance.
EU's CRA is coming (already delayed).
But it will all depends on enforcement strength. Until the first supermarket (or online reseller) is heavily fined for selling a smartphone that no longer receives updates, I won't hold my breath.
FWIW right to repair is already in force in the EU, which you'd think would require bootloaders to be unlocked, but they probably won't be until someone sues them over it.
> It will serve to either force those companies to finally start caring to fix their process
Those companies care about their revenue; they care only about the security of their customers' devices if it impacts their business success.
> or it will force the relevant users to get hacked
That it well might.
> ... until they vote with their wallets
They won't, because the next company over is just as bad, and the first-party devices are too expensive. And anyway the knowledge of which companies patch early may not even spread outside the tech circle.
> ... or (less likely) possibly force bootloaders to be unlocked
By whom? I have no idea what party would arrange that.
> ... or perhaps governments to finally step in and mandate some minimum level of software maintenance.
Now that would be nice, but that would be regulating the industry, and since when is that happening?
Note that Google doesn't get special treatment from Project Zero. There are (as of this comment) four Google issues disclosed after missing the deadline.
This is unfortunately too slow. As their finances show & name states p0 they need to act accordingly 0 day patch & disclosure and with the advancement of Ai 0 hour, 0 minute 0 seconds needs to be on the near roadmap if they want to remain “p0” alphabet/Google/other big tech need to fund the patches if they intend to disclose and they need to do it much faster. 30 days time is laughable anyone with basic understanding of 0 days, Ai & latency knows this.
Google is a mess. I have been doing essentially slave labor for 8 months for instance several high severity bugs I have submitted to Google have been patched in not one but three firmware updates yet they still have not paid me, you can read about it here www.github.com/jegly/jegly
Slaves didn't have a choice what to work on.
You are reward hunting. Reward hunting depends on both the size of promised reward as well as reliability of the counterparty to pay out. You seem to be misjudging the latter.
151 comments
[ 4.5 ms ] story [ 49.9 ms ] threadOn February 2, 2027, we will move to a “Full 60” policy where vulnerabilities are disclosed after 60 days.
On January 3, 2028, we will move to a “Full 30” policy where vulnerabilities are disclosed after 30 days.
It’s agents all the way down.
Releasing before that is non-actionable by many actors (aside from taking the service completely down I guess). Any time after fix is available is just allowing vulnerable systems to be attacked and is playing favourites with who gets fix and who doesn't
2 days after there's a fix, with a max of 90 days after disclosure?
Because you still need to have the 90 days no matter what to induce the vendor to create a fix. Otherwise (many) just sit on it forever.
You’re replying in a thread whose top level comment is that the 90 days will rapidly decrease to 30.
Hope 30 is enough to induce them to fix.
Maybe the future fixes will be “Reddit + Claude”, done at home.
I thought they made a strong case for removing the additional 30 day patch rollout time. But reducing the entire process to 30 days total seems needlessly harsh and I didn't think it was justified by the article at all. What if the bug is actually inherently hard to fix?
What makes you think this is true?
The article says they are willing to negotiate in exceptional cases, and mentions Spectre.
The testing can take a while, assuming it's a consideration at all.
Skipping testing is how you end up with another Crowdstrike scenario.
Bug fix speed isn’t particularly relevant, rollout speed is.
I hate to see slow rollouts. The single best thing you can do for fighting bugs is to roll out with canaries; weekslong rollouts only make sense when someone actually has to be in the middle of a cursed release while it runs.
If there's a bug in your code and it's rare there isn't much disruption. If it's not rare, why didn't your tests catch it?
Who can say? But it happens. If it didn't then deploying straight to production wouldn't be a problem.
That is the world we live in now and pretending otherwise is reckless and leads to mass hacking like the recent supermarket fridge hacking.
Only devices and applications that can respond to security reports quickly should be connected to the internet.
Lots and lots of devices are gonna get turned into botnets and tons of personal information is going to get leaked. However both of those things are already true.
Constant attacks mean the future will hopefully see local-first devices that don't need software at all.
Want to put them on the internet? They go behind gateways which are better maintained, because a world where every teenager can hack a vending machine through its vestigial Bluetooth stack would finally need to be secure to function.
Some (likely most) projects have just non-paid people working on it in their free time. That's the reality of open source.
Delaying disclosures is a false sense of security when the attackers are running the same scans Google is. They will have exploits faster than 30 days.
1. https://sheets.works/data-viz/holding-up-the-internet
2. https://ecosyste.ms/
3. https://busfactor.tech/oss/study/edition-1
4. https://infrastructure-heroes.org/maintainers/
5. https://www.linuxfoundation.org/research/census-iii
6. https://xkcd.com/2347/
Considering the direction software and their exploits are going with AI, if 30 days is insufficient in 2028 then that's useful signal to the people running that they should move elsewhere.
If you simply run or contribute to a FOSS project then you don't have any obligations, those kick in when you distribute software for profit and your obligations scale with the size of your business. Companies that fail to promptly address security vulnerabilities will face strict liability for damages.
In America software is protected by the First Amendment, so most software (and all open source for sure) cannot be subjected to "cybersecurity liability" of the sort you seem to be envisioning. Congress could have an angle when it comes to stuff that is sold, including in particular hardware and subscription services though there will be both plenty of lobbying and plenty of potential landmines involved in any such effort.
But with anything free there is no commercial angle involved, no contract. It's just speech that's put out there, identical to the posts we're writing here on HN right now. Software bugs aren't true threats, incitement, defamation, or obscene.
Other countries of course could take a different tack, but they'd then face "OSS becomes fully American" and I'm deeply skeptical that'd work politically.
Also when US gets a saner goverment back, I am quite sure CISA will have yet another opinion on the matter, especially if national security is considered exposed in some media case.
Perhaps in your authoritarian fever-dreams or whatever shithole country you current reside in, but no in the US.
>Also when US gets a saner goverment back, I am quite sure CISA will have yet another opinion on the matter, especially if national security is considered exposed in some media case.
And I'm quite sure you're full of shit.
Not the maintainer's problem.
That's the company's problem that stole the code without contributing back in the first place.
a reality that has always been blatantly obvious, unless one only listened to its all too many zealots.
With AI assisted vulnerability research the relative edge of project zero is going down - anything they can find can likely be found by others in a similar timeframe. We see this today with the parallel discovery of php2shell by many groups in the same few weeks
AOSP still has a 6 months holding back patches delay, the reasoning was "improved security".
So, what is improving security now? Fast patches or slow patches? :)
But they actually did this to comply with the EU Cyber Resilience Act. When a patch is released, a legal clock starts ticking - anyone who doesn't apply it promptly is liable for any resulting damages.
(With customers, however, we integrate right into their CI-CD, but because of the nature of our work, we can only work with certain customers. Major open source projects, however, have a lot of stakeholders and typically no budget, so we just try to help them as much as we can.)
0. https://swarmresearch.org
“Don’t like our constant stream of patches? For $10k/mo + tokens you can get access to the model to patch the vulnerabilities we disclose!”
In any case it’d be sensible to make yourself familiar with the “specific effort” before you make up your opinion on it.
https://blog.google/security/chrome-stronger-with-every-upda...
So I assume it’s all advertising and they’re not using LLMs then?
They are one of or maybe the most skilled security research team that’s doing public research and their blog is the source of many modern exploitation techniques
For a while, asking your agent to act like a P0 researcher was a nice nudge to find better bugs !
It is just leaving people with less safe software. At least claude the limitations are actively preventing you from looking for security bugs in your own software
But that assumption is pretty crazy to me and your argument makes no sense to me.
https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
They are all owned by Google, but registrations are not open to the public.
Definitely much happier. There’s nothing I miss from Ubuntu.
Of course I don’t expect a single person to work every day for free, but I also can’t have a project with only a single dev exposed to the internet.
The principle (containerized apps) is fine, but the dependency on a single vendor's "storefront", is not.
It's gotten easier finding vulnerabilities, so every day without disclosure now brings a higher chance that blackhats have already found the bug. The deadline gets shorter accordingly.
Calling vulnerability research "extortion" is the kind of ignorant messenger-blaming the hacker culture has always ridiculed.
What types of vulnerabilities does Project Zero find, in terms of their severity? And who are the companies that they are notifying?
You have to admit that there is likely a power imbalance here.
You directly called it "clearly a threat", and you indirectly called it plausibly extortion or else there would be no reason to ask if it's extortion.
But you need to explain on what general basis this even could be extortion.
And they're not "forcing the prioritization" of anything. They're just reporting bugs they found. They don't even need to warn the vendors at all if they don't want to.
Threats need an "or else". A non-negotiable publication is not a threat. It's someone sharing their schedule.
Nor do I consider it a threat when someone says "Items in the lost and found will be held for 30 days before they're donated to charity."
This is called "setting expectations" or maybe "communicating intentions".
Neither the users nor the vendors chose the 90/60/30 day limit.
Google is making an active choice in the design of their reporting process, and that is something that is open to critique and in some sense liability.
Why is Google choosing to report unlimited number of bugs, but a different Google program will only pay to fix 3 bugs? (https://bughunters.google.com/about/rules/open-source/patch-...) Why are not all Project Zero bugs exempt from that limit and awarded a minimum reward?
These are legitimate questions to ask.
if anything liability is on vendors that claim to be secure but actually aren't.
and sounds like you want a free money printer: write bugs, report to p0, get money to fix it.
So it is absolutely possible that nobody would ever find a memory corruption bug in a Lucas Arts SCUMM VM video transcoder if Project Zero didn't go poking around.
But because they did, and chose NOT to fund the fix, they DO carry some fault for anyone who acts on the bug after they disclosed it. Or if it is fixed in time, they must accept responsibility for consuming resources of a project they use but did not contribute to.
And the free money printer argument is absurd. The projects that Google uses are notable enough that writing bugs on purpose would be self-defeating. A project that write bugs on purpose would simply lose all users and nobody would care anymore.
Did they ask Google to decide how quickly they need to fix reported vulnerabilities?
Same free will Google uses to decide to spam them with reports, they could use to exempt those fixes from the 3 per month limit in Google’s already existing vulnerability fix reward program.
They don’t _have to_. But then I am free to call them out on it.
Do projects ask hackers to hack them?
> Did they ask Google to decide how quickly they need to fix reported vulnerabilities?
It is irrelevant and this is the point you don't get: Google is not forcing anyone to do anything. They just say "I found this problem in your software, I am notifying you and in 30 days from now the whole world will know. Do what you wish with this information."
> They don’t _have to_. But then I am free to call them out on it.
It is the internet, do whatever makes you sleep better at night.
Well, vendors can be more invested in building secure software and users get a lesson in why the "Check for updates" button exists in many devices' configuration options.
Google is not liable in any way for the vulnerabilities it finds.
What happens if a project has a vulnerability disclosure policy with a mandatory 90 day period, and Google ignores it starting 1.1.2027 and releases after 60 days?
You might wish that, but in the US at least they literally are not. There is no "security bugs" exception to the First Amendment. Anyone who finds one is perfectly free to shout it to the world instantly, or never, or anything in between. There is no gray area or complexity here as a matter of law. As a matter of morals, it is quite complex, and only getting more so in the age of LLMs. It was always the case that knowing a bug existed will let operators do "something" whether there is a patch or not, even if that something is "shut off all network access until patched", and it was always the case that anything one party can discover somebody else could at any moment, or at any earlier point from release before the second discoverer. LLMs can tremendously accelerate the discovery angle and expand the parties likely to do it, and might also speed up patching even by users of the software vs the devs.
>What happens if a project has a vulnerability disclosure policy with a mandatory 90 day period, and Google ignores it starting 1.1.2027 and releases after 60 days?
They can apply any social or economic pressure they're able to, otherwise too bad for the project? They can set whatever policy they want, nobody else is under any obligation to follow it unless contractually obligated.
It’s not the vulnerability that is the problem, it’s the timeline.
That’s what the original article is about. The 90-60-30 limit is something Google actually chooses, and that is not a first amendment issue.
Imagine a research found a vulnerability in Google and said, “You have 90 days to transfer 1 000 000 to my account or I will make the vulnerability public”. Pretty sure that would be considered actual blackmail and would be illegal.
It’s kind of tricky to see where the line would be. Google is effectively saying “You have 90 days to fix this vulnerability, in the software we use to make billions, or we will make the vulnerability public”. It’s not a huge difference. At best, you could argue it’s two different departments: one that find vulnerabilities and the other that makes money from the project.
Wonder no more. They have zero liability either way.
>That’s what the original article is about. The 90-60-30 limit is something Google actually chooses, and that is not a first amendment issue.
Uh. Choosing time/place for speech is absolutely a 1A issue. Google (and you, me, and anyone else) is completely protected from legal action in how and when they make a unilateral decision to speak using their own resources.
>Imagine a research found a vulnerability in Google and said, “You have 90 days to transfer 1 000 000 to my account or I will make the vulnerability public”.
Yes, as you say that'd be blackmail but that's completely irrelevant to anything you have said or anything in this case. Google is not demanding money.
>It’s kind of tricky to see where the line would be.
No. It's not actually. Blackmail is extremely well defined in law and caselaw. No demand for anything? No blackmail.
>“You have 90 days to fix this vulnerability, in the software we use to make billions, or we will make the vulnerability public”. It’s not a huge difference.
Yes, it's a huge difference, even if you were being honest in your statement, which you aren't. Google doesn't have any "or we", they just say "when we find something, we've decided we'll generally try to let you know, and then at X time later we'll disclose it no matter what you do or don't do, so that then other mitigations can happen, unless we feel like doing differently." Which is 100% fine. Somebody can fix the vulnerability they introduced themselves, or not. Or they can try to get someone else to do it (depending on the project and whether Google cares, it might well be a Google engineer or LLM who offers a patch). Once it's out there, everyone else who uses said software can also try to patch or otherwise ameliorate it or move to something else, based on their own considerations, or not. That's just... normal society and market of ideas? And it doesn't make any difference is whether Google makes billions or zero dollars.
And if something is just a personal / hobby project that you don't want to support - that's also fine. Having the security vulnerability published just means people using it have a more realistic view of the situation.
Yeah they're not doing it to help you but to sabotage you.
But when challenged they profess they're just trying to be "helpful"
What do you think Google is extorting from the publishers of insecure software - reduced security vulnerabilities? Or what is it that you think Google is actually after by doing this?
> guise of security
What do you think is the real motivation if not security?
As seen by the infamous FFMPEG incident: https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-send...
In fact, the article cites one of the FFMPEG maintainers as being grateful for the vulnerability reports.
Did I miss something?
Google is extorting benefit, specifically fixes to software it heavily depends on for its multi billion dollar business, by coercion, specifically by actively threatening the project with reputational damage in 90 days if certain action is not taken, even if the action is not in the vendors best interest.
As a thought experiment, imagine if Google was reporting this to the project, but _without_ the 90 day limit. The one that the original article describes going down to 60 then 30 days. Yes, you might first think "that will cause the projects to never fix bugs" which might be true for some projects, but you do realize how legally that would completely change the dynamic between Google and the project and remove the entire extortion part from the picture? Or indeed, if they simply published it without any notice at all.
Whether or not other people also happen to benefit is related, but it doesn't remove the fact that Google also benefits.
Or if you would like a more vivid picture:
If the Mob forces you to give them a room in your hotel for illegal poker tournaments and then gives you tips on how to make the windows safer so that bricks can't fly through them, it does improve safety for all your clients but it's still extortion.
I would prefer ffmpeg team to have the time to focus on slightly newer stuff, as a user myself.
For a lot of security people its collecting scout badges.
It all came to a head once before: https://thenewstack.io/ffmpeg-to-google-fund-us-or-stop-send...
And Google has a vested interest in FFMPEG, because it uses it heavily to transcode and process videos. So they absolutely benefit from the work, for free.
How is it extortion? Google does not create the vulnerabilities. It just validates them and makes the details public. It is a public service for everyone.
The tools enabling these exploits exist and aren't going away so burying our collective heads in the sand by allowing messes to be swept under rugs isn't a productive response.
EU's CRA is coming (already delayed).
But it will all depends on enforcement strength. Until the first supermarket (or online reseller) is heavily fined for selling a smartphone that no longer receives updates, I won't hold my breath.
Those companies care about their revenue; they care only about the security of their customers' devices if it impacts their business success.
> or it will force the relevant users to get hacked
That it well might.
> ... until they vote with their wallets
They won't, because the next company over is just as bad, and the first-party devices are too expensive. And anyway the knowledge of which companies patch early may not even spread outside the tech circle.
> ... or (less likely) possibly force bootloaders to be unlocked
By whom? I have no idea what party would arrange that.
> ... or perhaps governments to finally step in and mandate some minimum level of software maintenance.
Now that would be nice, but that would be regulating the industry, and since when is that happening?
I doubt this is a good thing.
> it will force the relevant users to get hacked until they vote with their wallets
By definition, a low-income user has very little "wallet" to vote with. Government stepping in is really the only workable solution.
https://project-zero.issues.chromium.org/issues?q=status:ope...