Patch embargoes are a debate as old as security.

I think the overall source embargo is rational _until_ fixes appear in a released binary build. Otherwise there's an integration/QA/rollout window where a source patch is public while the binary patch is unavailable to anyone, including attackers, which is undesirable. In "full" open source this has always been a time-suck mental gymnastics exercise around hidden mailing lists and obfuscated commit messages (which probably aren't useful in the LLM era anyway). It makes sense for Google to avoid engaging with that given they don't need to; I think it would be fully logical for them to perform source drops gated on the rollout cadence to the first available binary release channel.

I fully agree the slower-than-Pixel "vendor lead time" windows are really detrimental. Once the binary patch is out, the source patch and disclosure is effectively out too; those extra windows just let OEMs continue to be lazy as a matter of policy (which they love to do regardless) while exploits are already available.