The other side is that the moment a patch is released, people will diff it to the previous version making it much more likely this issue is found by a lot of independent people who might seek to exploit it.
That sounds like a logic flaw because iPhones and most other devices like it will normally auto update after a short while. I think more people will rely on that feature than browse, uh, bugs.chromium.org...
This view of it will assist hackers in getting a head start before the auto update cycle gets to your device and you're notified. And if you're hit but something like this before that, your iPhone will no longer be able to update and apply the fix.
Of course, there's no way to find an objectively "correct" time frame since update cycles vary, but a month or two ought to give plenty of time for the updates to roll out and users to be made aware.
Sounds good in theory. In reality, the vast majority of iPhone users are not aware that this bug exists and never will be. The best action for user safety is to wait until the period has elapsed or the exploit has been seen in the wild already.
Alternatively, they could publish the gist of the exploit without providing enough detail to actually perform the exploit.
Publishing it like this will make them more likely to be aware of it. They may not read Hacker News but it spreads to Facebook user groups etc.
The bad guys (many enough of them) will anyway figure it out right away after the patches have been published, because with every patch, people will (and should) ask "why".
Reading (dis)assembly is a skill many in our profession are required to learn. It’s common in OS & security fields. Heck, when developing Windows on ARM we were told Friday that we’d come to work Monday with a mandatory “no source” debugging session where we had up to an hour to describe a hanged program’s intended behavior and why it was hanged. One of my colleagues also refused my symbols when I asked for help debugging a program. He was more comfortable in ASM than the latest C++