> I already addressed why that doesn't really hold water: it assumes that you're likely to know if a bug is being exploited or not. Google found the bug. They'r

> I already addressed why that doesn't really hold water: it assumes that you're likely to know if a bug is being exploited or not. Google found the bug. They're already doing the free research, giving Microsoft a reproducer, and giving Microsoft a well-established policy for when they're going to go public with the bug. Are you suggesting they're responsible for knowing if a bug is being exploited in the wild, or that we should take Microsoft's word for it if it is or not? Google is operating with limited-to-zero information on what exactly breaks when the bug is fixed, and Windows (or even just the .net framework) is a behemoth. Google and Microsoft do both have threat intelligence groups, but that's a separate thread. When you're producing software designed to run on many configurations with absolutely stable operation for at least a month at a time, it's extremely, extremely hard to say that "some bugs don't need 6 months of intense QA to fix." I'm not an engineer at Microsoft, but so long as Microsoft is giving routine updates on a private channel—which they did in this case—as to why it's taking so long, it at least signals that the team is in fact actively working towards a resolution. In fact, with this specific defect, Google applied its own rules/practices to decide whether Redstone 4 (which is my assumed read into what "RS4" means) would be considered a broad patch, whereas Microsoft considers system requirements for minor Windows 10 releases to be hardware-identical in need and entirely backwards-compatible. Timeline (per the report): -> 2018-01-19: Reported issue to secure@microsoft.com and received MSRC case number 43182 <- 2018-02-10: MSRC indicates that the issue has been reproduced and will determine if it's to be fixed. <- 2018-02-12: MSRC indicates that due to unforeseen code relationship this will not be fixed in April PT <- 2018-04-02: MSRC requests the 14 day extension. -> 2018-04-02: Informed MSRC that as the issue will not be fixed with 90+14 days then the grace extension does not apply. <- 2018-04-05: MSRC again requests withholding of disclosure until 2018-05-08, giving more context on the deadline miss. -> 2018-04-06: Informed MSRC that this isn't possible. Made it clear that the issue isn't particularly serious and other .NET based DG bypasses are still unfixed. <- 2018-04-11: MSRC again requests grace extension based on the upcoming release of RS4 which will have the fix -> 2018-04-12: Informed MSRC that as there's no firm date for RS4 this couldn't be applied, and RS4 wouldn't be considered a broadly available patch per the disclosure conditions. -> 2018-04-19: Issue exceeds deadline. —————————— —————————— As an aside: > You are again only interacting with a tiny part of my argument. I'm developing RSIs and would prefer to minimize my interaction to what's most relevant to the debate. I apologize if that makes it more difficult. Edit: though for what it's worth, I'm enjoying interacting. I bear no ill will towards you for your perspective; I've seen and learned quite a bit about balancing security and managing business impact as I've continued to climb the career ladder, things which were shielded from me when I was a lowly developer or security engineer.