Live data from Hacker News

Project Zero – Policy and Disclosure: 2025 Edition

googleprojectzero.blogspot.com

11–20 of 41 posts

Re: Project Zero – Policy and Disclosure: 2025 Edition

#11
This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously.

At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is extremely difficult, both because of the number of people involved and because fixing the vulnerability sometimes requires advance changes to other public components.

I'm not sure there's a great solution to this.

Re: Project Zero – Policy and Disclosure: 2025 Edition

#12

This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously. At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is ext…

On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial.

For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.

Re: Project Zero – Policy and Disclosure: 2025 Edition

#13
post #8
post #3

If Google is adopting this, maybe rachelbythebay's vagueposting was ahead of the curve? I jest; the vagueposting led to uninformed speculation, panic, reddit levels of baseless accusation, and harassment of the developers: https://news.ycombinator.com/item?id=43477057 I hope Google's experiment doesn't turn out the same.

> I jest; the vagueposting led to [...] Resurrecting a 4 month old issue that evaporated in a day or two seems like poor form to me. Also I believe most of the responsibility for the negative behavior should be assigned to those actually engaging in it, not the initial post. I understand others reasonably disagree (notably about the accusation and harrassment). Tbh, it sounds like you might have been personally affec…

I stand by what I said at the time: https://news.ycombinator.com/item?id=43492940 - and if you only read one thing, read the harrassment an atop contributor was subjected to by "eslerm": https://github.com/Atoptool/atop/issues/330#issuecomment-275...

I bring it up because of the unmissable parallels. Google are trialling a policy to see what will happen, but this incident shows already what can happen.

RbtB is a trusted blog by the HN crowd, and her vaguepost unexpectedly whipped up hysteria. It was only quelled by a post with more details the next day. Google Project Zero has enormous levels of trust, intends to vaguepost as policy, and not post more details the next day to satisfy the mob.

It does not look good for volunteer maintainers to suffer an entire world of talentless clowns rifling through every commit and asking "is this the bug Project Zero found?"

Re: Project Zero – Policy and Disclosure: 2025 Edition

#14
> This data will make it easier for researchers and the public to track how long it takes for a fix to travel from the initial report, all the way to a user's device (which is especially important if the fix never arrives!)

This paragraph is very confusing: What data is meant by "this data"? If they mean the announcement of "there's something", isn't the timeline of disclosure made public already under current reporting policy once everything has been opened up?

In other words, the date of initial report is not new data? Sure the delay is reduced, but it's not new at all in contrast to what the paragraph suggests.

Re: Project Zero – Policy and Disclosure: 2025 Edition

#15
post #12

This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously. At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is ext…

On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial. For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.

Maybe I don't understand the threat model here: what kind of public-facing services are you running that are simultaneously (1) not already access-limited, and (2) not load-bearing such that they need to be public-facing?

(And to be clear: I see the benefit here. But I'm talking principally about open source projects, not the vendors you're presumably paying.)

Re: Project Zero – Policy and Disclosure: 2025 Edition

#16
post #12

This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously. At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is ext…

On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial. For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.

Unfortunately I think most of the products you use have 0-days in them, it's just that Project Zero hasn't found them yet.

Re: Project Zero – Policy and Disclosure: 2025 Edition

#17
post #12

This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously. At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is ext…

On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial. For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.

Unless the 0day is in your firewall.

Re: Project Zero – Policy and Disclosure: 2025 Edition

#18
post #12

Earlier quoted context omitted.

On the contrary: If Project Zero finds a 0-day in a product I know I use, and I know that product is Internet Facing, I can immediately take action and firewall it off. It isn't always the case that they find things like this, but an early warning signal can be really beneficial. For customers, it also gives them leverage to contact vendors and ask politely for news on the patch.

Unless the 0day is in your firewall.

Fortinet strikes again...

Re: Project Zero – Policy and Disclosure: 2025 Edition

#19

This policy change makes sense to me; I'm also sympathetic to the P0 team's struggle in getting vendors to take patching seriously. At the same time, I think publicly sharing that some vulnerability was discovered can be valuable information to attackers, particularly in the context of disclosure on open source projects: it's been my experience that maintaining a completely hermetic embargo on an OSS component is ext…

There really isn't a great solution here. The notice that a vulnerability has been discovered puts even more pressure on the fix to be deployed as close to instantly as possible, throughout the entire supply chain.

Why is this? Especially for smaller or more stable open-source projects, the number of commits in a 90-day period that have the possibility to be security-relevant are likely to be quite low, perhaps as low as single digits. So the specific commit that fixes the reported security issue is highly likely to be identified immediately, and now there's a race to develop and use an exploit.

As one example, a stable project that's been the target of significant security hardening and analysis is the libpng decoder. Over the past 3 months (May 1 - Jul 29), its main branch has seen 41 total commits. Of those, at least 25 were non-code changes, involving documentation updates, release engineering activities, and build system / cross-platform support. If Project Zero had announced a vulnerability in this project on May 1 with a disclosure embargo of today, there would be at most 16 commits to inspect over 3 months to find the bug. That's not a lot of work for a dedicated team.

So now, do we delay publishing security fixes to public repos and try and maintain private infrastructure and testing for all of this? And then try and get a release made, propagated to multiple layers of downstream vendors, have them make releases, etc... all within a day or two? That's pretty hard, just organizationally. No great answers here.

Post reply on HN