Some hoots about how development process affects security response time. Yeah, it would be nice if there's lots of time to fix. But the reality is that 0days drop, which requires fast turnaround, thus secure software must have a fast development cycle to get patches through pipeline. "Responsible" researchers offering extended fix deadlines is optional and cannot be relied upon.

hoot: https://twitter.com/ErrataRob/status/1138544053857988608

@ErrataRob: So this is just a recapitulation of the debate we've been having for decades. The underlying issue here is not "responsible (sic) disclosure", but development processes. Google dev is based on 24 hour cycles, Microsoft dev on 6 month cycles. https://twitter.com/taosecurity/status/1138490944347619329

@ErrataRob: When a bug is found in Chrome, then Google can fix it, test it, and release it to customers in a day. If a second bug is found in testing, it just means another day. When a bug is found in Windows, it takes around 90 days, and if a second bug delays this, it's another month.

@ErrataRob: Google manages Chrome as a piece of software that must be patched, and gives customers few options to do otherwise. Microsoft still manages Windows as software where patching is optional, even though in practice, it really isn't.

@ErrataRob: So we can't focus on Tavis's decision to adhere to the Project Zero 90 day disclosure policy. We must also factor in Microsoft's decision to have such slow development processes.

@ErrataRob: After 30 years of watching this "disclosure" debate, one thing that's clear is that Microsoft (and all other big companies) are as slow as they can get away with. If it weren't for vuln researchers adhering to a 90 day policy, Microsoft would be even slower.

@ErrataRob: I mention that because in the VEP (vuln equities) debate, people say the NSA shouldn't "hoard" 0days but notify vendors. But vendors won't fix those 0days unless the NSA is also willing to sometimes adhere to a maximum timeframe and disclose them publicly if not fixed.

@ErrataRob: Politically, the NSA could never publish 0days the way Tavis has just done, and Q.E.D., most of their 0days they tell vendors will never get fixed anyway. So they may as well hold onto them and use them to find and drone strike terrorists.

@ErrataRob: Back to Microsoft. The issue isn't that a bug was found in testing and they needed an extra 30 days on top of the normal 90 days. They should've had a fix at least within 30 days, and should only have needed an extension to 60 days.

@ErrataRob: So this response to my thread should be highlighted: instead of looking at it from the dev point of view, let's look at the problem from the customer point of view. Customers don't want daily updates to Windows. https://twitter.com/jfslowik/status/1138550435705307136

@ErrataRob: But customers are wrong. It's like how Baltimore wants to sue the NSA because they hadn't patched Windows systems after 2 years. Software as exposed to threats as the operating system has to be patched faster than that.

@ErrataRob: Browsers and operating systems are in the same boat: their size, complexity, and exposure to threats are orders of magnitude beyond that of any other software. This necessitates patching.

@ErrataRob: But customers still buy medical equipment based on Windows that can't be patched and which fails when the next worm comes along.

@ErrataRob: That's fine. There are other ways of mitigating such threats, like hardening the operating system or firewalling it. Patching isn't necessary most of the time -- if you do your job right.

@ErrataRob: But customers have decided NOT to do their jobs right. That's why they don't want Microsoft to patch more often than "patch Tuesday", because they don't want to be responsible for mitigating bugs, but want Microsoft to be responsible.

@ErrataRob: If Microsoft were to move to weekly patches, customers would have no reason to be angry. They could decide to still only apply the patches once per month. The reason pitchforks would come out is because they can't make that sort of decision.