It also seems to disclosesinteresting internal products: what is Google Bigwave ?
Seems to be described a bit here https://www.androidauthority.com/how-google-built-tensor-g5-...
Project Zero – Policy and Disclosure: 2025 Edition
21–30 of 41 posts
Re: Project Zero – Policy and Disclosure: 2025 Edition
#22Not sure what is the measurable metric here, and what will be considered a success in this trial period. Propagating the fix downstream depends on the release cycles of all downward vendors. Giving them a heads up will help planning, but I doubt it will significantly impact the patching timeline. It is highly more likely that companies will get stressed that the public knows they have a vulnerability, while they are…
The measure would probably be whether any of the reports led to examples of downstreams either syncing prior to release via security sharing they didn't already have established or any projects preparing to sync out of normal schedule ahead of time, regardless of if that's a small or large magnitude of change. How companies would prefer the public hear about a vulnerability has always been the lowest concern out of disclosures so I don't expect it to bring anything new here.
Google's products represent 3/6 of the initial vulnerabilities following this new reporting policy in the linked reporting page.
Re: Project Zero – Policy and Disclosure: 2025 Edition
#23If 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.
[deleted]
Re: Project Zero – Policy and Disclosure: 2025 Edition
#24Earlier 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.
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.)
Some companies might be willing to compromise functionality to avoid compromise of their networks.
There's always a usability / functionality vs security tradeoff
Re: Project Zero – Policy and Disclosure: 2025 Edition
#25It is indeed a complex problem. But is Google now killing FOSS slowly? IMHO there is far too much emphasis on Foss security and far too little on closed sourced hardware, firmware and software. Too much blame and pressure will not solve the complex problems as stated in the blog.
Re: Project Zero – Policy and Disclosure: 2025 Edition
#26It is indeed a complex problem. But is Google now killing FOSS slowly? IMHO there is far too much emphasis on Foss security and far too little on closed sourced hardware, firmware and software. Too much blame and pressure will not solve the complex problems as stated in the blog.
Shoring up the security of FOSS is not "killing FOSS slowly".
Closed source software doesn't get to benefit from the goodwill of the open source software community, which includes independent security researchers as well as orgs like P0.
I guess our disagreement can be distilled down to one question:
Why would an emphasis on closed source products help FOSS, and why would an emphasis on FOSS help closed source?
Because this seems backwards to me. Maybe it makes sense in public relations where vibes are more important than substance and nobody thinks for more than 100 milliseconds?
Re: Project Zero – Policy and Disclosure: 2025 Edition
#27I love it; it's a big-company reformulation of the classic vulnerability researcher's "reporting transparency" process: post "Found a nasty vuln in XYZ: 6f0c848159d46104fba17e02906f52aef460ee17d1962f5ea05d2478600fce8a" (the SHA2 hash of a report artifact confirming the vuln).
Re: Project Zero – Policy and Disclosure: 2025 Edition
#28Earlier quoted context omitted.
> 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 trus…
The "Rachel By The Bay" blog and Google Project Zero are not reasonable comparands in matters of vulnerability disclosure.
Re: Project Zero – Policy and Disclosure: 2025 Edition
#29Earlier quoted context omitted.
Speaking of, whatever came out of that? I don't see any related updates on that blog.
This was published the day after, with the title "Problems with the heap" but the URL makes the context clear: https://rachelbythebay.com/w/2025/03/26/atop/
Yeah, I meant since that one.
Re: Project Zero – Policy and Disclosure: 2025 Edition
#30I find the stated goal of alerting downstream a bit odd. Most downstreams scan upstream web pages for releases and automatically open an issue after a new release.
Project zero could also open a mailing list for trusted downstreams and publish the newly found announcements there.
The real goal seems to be to increase pressure on upstream, which in our modern times ranks lowest on the open source ladder: Below distributors, corporations, security pundits (some of whom do not write software themselves and have never been upstream for anything) and demanding users.