Microsoft hits out at Google team over bug report
bbc.co.uk
bbc.co.uk
MS is a huge company with an immense installed base and they have to be understandably careful with pushing updates. Working with them to disclose vulnerability on their regular patch day really wouldn't be such a bad thing for either Google nor the end users, even more so as we're talking about two days here and there even was a holiday week in the timespan.
This is about being an ass and I see no advantages for end users.
Even if Microsoft had not responded to Google at all, they could have waited for full three patch days (again, MS' patch deployment timeline is very much public knowledge by now) before publicly disclosing the issue.
Which is a dumb policy for security patches. When its fixed it should be released.
> If Google isn't willing to wait the two additional days such that the patch can be deployed within the regular update window, this means that Google effectively gives MS only 60 days to react and fix issues (because once they missed the second patch day, the vulnerability will be disclosed before the third).
Google doesn't dictate Microsoft's patch releasing policy. 90 days are 90 days. Microsoft doesn't have "only 60 days", they have 90 days like anyone else, and they chose to miss it by adhering to a policy of their own choosing that makes security patches less timely.
The whole purpose of a fixed 90-day window is to give reasonable time to fix a security vulnerability but also to create pressure to do so timely. Making exceptions for vendors to accommodate existing policies that make security fixes less timely would both increase the effort for Google (as a fixed time window is always easier to implement than one that varies with each vendors policies) and undermine the whole purpose of the 90-day timeline.
Applying the patch a few days later typically doesn't noticeably increase your risks but rolling them out unchecked can make some serious damage.
Before, many enterprises rarely patched because the testing involved was a huge pain and it fell outside what they typically planned for.
If you don't want to apply the patches as soon as they're released, then you'd be more than welcome to put them on hold for 4 weeks yourself when it's more convenient.
Your options become either to release an update the moment it's tested, immediately making vulnerable customers who have a change management policy (usually also the biggest and juiciest targets - fortune 500s including ironically the likes of Google), or delay any release until some coordinated date, giving everyone an equal and predictable opportunity to cope with the exposure, which is how Microsoft do it.
What are the chances that attackers or other agencies already know of these vulnerabilities and are exploiting them?
Microsoft's delays extend the time that the silent attackers have.
There are bad guys looking for 0-days out there. If they learn about the vulnerability from the patch, at least the world has the patch before the bad guys do. Now it's the opposite.
Edit: See _wmd's explanation about the technical details of all this in the same level of the answers.
You apply a dozen different fixes and test. Something breaks badly. You now have a dozen different root causes to check when, if you applied one at a time and tested (or applied one at a time and let your users test it, which is more commonplace than it should - automated testing tools exist for a reason) you'd know what broke.
I'd prefer to have fixes available for rollout as soon as possible and to decide whether I deploy them or not based on my tests. Automatic mandatory deployment could be on a fixed schedule, for those who can't test or don't care much about it.
Releasing the patch late (i.e., on patch day) makes that choice for everyone.
It's not that just the big companies are affected now: all users are.
Large enterprises already have centralized patch management, so they can decide how fast it gets pushed downstream to their users after MS releases the patch.
I haven't come across a source for that. Does one exist?
For all I know, Microsoft announced it in reaction to the publication, but I have no clue Google could have been made aware of it beforehand.
Edit: nevermind, I've found one.
You are new to IT aren't you?
Failure to blindly adhere to the common view isn't the same as being new.
Even so, this is a clash of two policies and Google needs to reevaluate its deadline (is 120 days better for everyone, including users?).
Perhaps responsible disclosure occasionally requires considering the unique circumstances of each security flaw?
This looks like a solution, but isn't. Perhaps Google's 90 day deadline is already a re-evaluation of a 60-day deadline that was made to accommodate holidays and companies with a once-a-month patch schedule. If Google's deadline was 120 and still hit two days before patch Tuesday, would you say the same thing but for 150?
(N.B. I'm not defending Google, just poking a hole in this particular idea.)
Microsoft do issue out of band updates but they are very rare and for very serious issues.
It isn't like Microsoft was stalling for time, they didn't ask for months, they asked for days to fir into their scheduled releases. It's also worth pointing out the enterprises time things on the patch Tuesday cycle. An earlier release causes all sorts of implementation problems, especially if only a day or two in advance. In all likelihood you wouldn't see many machines actually updated in that period, but cause significant extra grief.
Yes. Google designed Project Zero to "pressure firms into dealing with security problems more quickly." A firm policy with unambiguous enforcement has its advantages. Muddying the 90-day deadline with questions about when (and for whom) to make exceptions weakens it. For example, in the future, I expect Microsoft will not wait the extra two days in the event of a security disclosure from Google.
One may disagree with the 90-day policy to begin with. I, for one, think it should have had an exception process built in. But while these are Google policies, not laws, I respect them for adhering to published protocol. Even when it was difficult.
It's just like being late for work. "But I was only 5 minutes late." Late is late.
As far as I know, some other engineering areas have even the safety factor of 2 or 3. That means, you expect the stress x, but your process has to sustain even 3 x.
Edit: Zero tolerances are never a good idea.
http://civilrightsproject.ucla.edu/research/k-12-education/s...
Then again what does Google care, they don't use or support anything Microsoft, so it doesn't affect them.
As does Google Earth, Google Drive, the android development toolchain, and a handful of other desktop clients that I'm not going to bother to look up right now.
It seems to me Microsoft is like that student who has 3 months to do a project, but waits until the last 2 days, and then asks the professor to give him some more time. It was Microsoft's responsibility to patch the bug at the last Patch Tuesday.
If Google (or any other group that discovers security issues) has to take into account every policy of every software producer it becomes utterly impossible to have any disclosure policy.
If MS wants to handicap themselves, that's their problem. The rest of the world doesn't have to bend to their will, those days are over.
Yes, this is about being an ass. And it's Microsoft that's being an ass by claiming the rest of the world should take into account their peculiar policy.
Please don't sit on a fix until the time is more "convenient", give it to me now and let me be the judge on how important this security patch is to me.
https://code.google.com/p/google-security-research/issues/de...
> Microsoft confirmed that they are on target to provide fixes for these issues
in February 2015. They asked if this would cause a problem with the 90 day
deadline.
< Microsoft were informed that the 90 day deadline is fixed for all vendors and
bug classes and so cannot be extended. Further they were informed that the 90 day
deadline for this issue expires on the 11th Jan 2015.
> Microsoft confirmed that they anticipate to provide fixes for these issues in
January 2015.
I work in information security and patches are important, I understand. But it worries me that what we're basically seeing here is corporate warfare using security vulnerabilities. What gives any company the right to publish vulnerabilities about their competitors, especially when it has the chance to impact their competitor's performance? Does Pepsi have the right to demand Coke rotate the tires on their trucks within 90 days or they will publish the recipe for Coca Cola?
Google's policy is responsible disclosure. Wavering on the well-known deadline would become a political headache. If you give a mouse a cookie... Two days becomes a week; a week becomes half of a month; half a month becomes a full month. Perhaps if Google is feeling generous, they could not disclose a vulnerability to a vendor until a later time (for example, if a vulnerability is found just before a well-known extended holiday or something) thus automatically "extending" the expiration of the quiet period. But that still leaves us, the users, more vulnerable for longer if the bad guys were already aware of the problem.
On a slight tangent, Microsoft's policy to not release security patches as soon as they're available (and instead wait until "patch Tuesday") harms us all. They don't have to forcibly push the fixes, but immediate availability would be a tremendous improvement.
If we ask "what gives any company the right to publish vulnerabilities about their competitors?" it's only a short step to asking "what gives journalists the right to publish scathing negative reviews?" The answer is the same: freedom of speech.
It's a fact of life that if you want to fix security bugs, that takes time away from working on other things. If you don't like it, fix the bugs faster, or pay more attention to security from the get-go. Microsoft should be thanking Google for finding the bug in the first place.
Journalists are not directly competing with tech companies. Google is. Imagine the next bug they find in Windows, and they publish it saying "ChromeOS doesn't have this bug!". They already use their search to push their browser, why not use their bug reporting to push their OS? When does free speech stop and anti-competitive behavior start? Would Google publish their own vulnerability if they were unable to fix it in 90 days?
So? As a general rule, people (and companies) have the right to say things like "I'll do X if you do Y" or "I'll do X unless you do Y". It becomes blackmail under certain circumstances, like where you're threatening to harm someone illegally, or demanding money for covering up a crime. In this case, Google picked a 90-day disclosure timeline which seems to be considered generally reasonable by the security community, so I don't see how they're doing anything wrong by sticking firmly to it.
> Google published it anyway, because their competitor didn't work fast enough, for Google's definition of "fast enough".
Yup, sounds like competition to me.
> Imagine the next bug they find in Windows, and they publish it saying "ChromeOS doesn't have this bug!".
Yup, sounds like competition to me.
Maybe I'm just being dense but it would help if you could explain why you think this is "anti-competitive." To me, forbidding a company from trying to demonstrate that its product is more secure than its competitors' is anti-competitive.
> Would Google publish their own vulnerability if they were unable to fix it in 90 days?
Maybe, maybe not. Presumably since Microsoft has so many employees and cares so much about security, it has its own team of researchers dedicated to finding bugs in Chrome, right? Or is it Google's responsibility to find everyone's bugs, and then give them as much time as they want to fix them?
As a general rule, if I take action A and action A will result in a higher probability of harm coming to anyone, whether it's illegal or not...I'm a bad guy. Whether you call it blackmail or not, Google is the bad guy here.
> Yup, sounds like competition to me.
Oh good. I hope you can still apply the same logic if your personal bank gets attacked and your money is stolen because of the fact that Google decided to release detailed information to the mafia.
> ...explain why you think this is "anti-competitive."...forbidding a company from trying to demonstrate that its product is more secure...
That's not what's happening here. Google is not demonstrating any product here. The guy who runs Project Zero stated that “People deserve to use the internet without fear that vulnerabilities out there can ruin their privacy with a single website visit,”.
Do you think Google's action here has resulted in more or less of a probability of harm coming to users here?
Personally, I don't think Google should bend to the internal red tape of other companies. You are going to start maintaining this long list of exceptions based on other peoples priorities. There is a published 90 day policy, they gave 90 days notice, figure it out. There is also details missing about the communication between Google and Microsoft. Like when they asked for an extension, etc.
Its worth noting, as pointed out upthread, that the only reason it was released in January at all was because when Microsoft asked if their planned February release was going to cause a problem with the 90-day deadline, Google informed them the the 90-day deadline for that bug was 11 January and that that's when disclosure would occur. Clearly, the fixed deadline already achieved part of what it was intended to -- encouraging vendors to fix security issues more quickly.
And I'm not sure that there even exists such a thing as a "common sense exception" to that policy, but extending it simply to accommodate a vendor schedule that delays releases of security fixes to predetermined dates isn't such a common sense exception even if any exist. Its simply favoring the bureaucracy of fixed patch schedules over the purpose of the disclosure policy, which is encouraging vendors to more timely release fixes for security bugs.
If you don't have it, then you have a lot of time wasted on communication, handling special exceptions, making decisions if you should bend it or not and so on.
You start out with two days because of patch tuesday. Then next time a bug is reported, well, this is a busy month with lots of people on holiday, if we could have an extra 10 days? And the next time, we're really close to releasing Service Pack N, the fix will be in that but it's got lots of changes - it'll be out in 60 days...
I applaud Google for not bending on their 90-day deadline (assuming they do hold all companies to that, and it appears they do). Maybe this incident will help encourage some companies that might otherwise be lax when confronted with a bug to hurry up. There's no telling who else knew about this bug and was actively exploiting it (probably lots of people).
Reading the comments on the ticket however, I really feel like Microsoft was in the wrong here. They asked 4 days ago to push it for a whole month and then now they are fine for their January release. I really feel like they start to feel the pressure of the 90 days so being strict about it is a good choice from Google.
You have no reason to believe it was a "lot of people." In fact we have no reports of people exploiting it in the wild at all, unless you have some information we don't.
edit: Downmod me all you wish, but substantiate your claims. Where is this being exploited in the wild before Google released it?
But I agree with you that I shouldn't have written "probably lots of people". I have no basis for that assertion. I retract that sentence (but not the rest).
By the way, I didn't downvote you. In fact, I almost certainly would have even upvoted your comment if you hadn't made the edit complaining about the downvote (against HN guidelines) and accusing me of downvoting you (false accusation).
As a general rule, you should never assume that the person you're disagreeing with was the one who downvoted. Many of us on HN only downvote people who are making low-information comments (which your comment was not, indeed it made me reconsider an assertion) or comments made in bad faith (yours was not, as far as I know).
So is this what the disclosure issue is going to look like when packaged up for the masses? No historical context on how the ongoing disagreements are the latest in decades of ongoing discussion? Or any mention of the events that shaped the popular ideas today? Just a sour blogpost and some bland quotes of agreement and disagreement from an internet so large you can always find quotes for the positions you want to portray. We're so fucked.
Edit: And apparently it worked on us too. Of course external messaging is going to paint the other guy as the unreasonable one.
They knew they had 90 days and decided to ignore it.
I guarantee you that if this was an Android bug that the Android team would have gotten 2 more days.
That's the inconsistency here.
God help Google if an Android bug is discovered that takes them more than 90 days to patch across their 123421 variants of fragmentation.
Even given that Windows 8.1 is a large and complicated machine, what was it about this particular bug that required basically all of Q4 for MS to patch it?
It's one bug.
I have a sinking suspicion that MS simply didn't consider it a priority, even after responsible disclosure to them, which is why it's good that Google's public disclosure policy is a hard-limit 90 days. Too many companies, when given the option to choose their own priority tree over the priority tree enforced by security needs, will choose the former.
If the Project Zero programmers were independent or malicious, they could have sold this information or released it without giving the 90 day window.
Seems like Google is trying to do the right thing by alerting others on these flaws and holding a fast deadline to fix it.
[1] https://news.ycombinator.com/item?id=8874339
[2] https://nakedsecurity.sophos.com/2010/06/15/tavis-ormandy-pl...
What does Google care? I get the impression they care about not much else than ads and HUGE NUMBERS of users.
I am in general a huge Google fan, but in using Google services I realize that I am not much of a customer (I purchase extra storage and buy stuff on the Play Store); advertisers are the customers.
Microsoft on the other hand gets its money from computer users and it seems like they have a much more customer focused mentality.
(neither, or both)
Why do you say this?
It implies a world where software is almost perfectly secure, and there are only a few bugs to fix, and then it's perfectly secure, and we are all happy.
In reality, there are effectively an infinite number of bugs out there, many with security holes. Finding one and going through the motions to fix, patch, test, and release still leaves you software with plenty of open holes.
If you magically theorize "the bad guys know about all the holes already," then they are still going to exploit all the other holes in the system, because they magically know about them, too.
> Historically, it's more likely...
But going on what is actually known, less people knew before Google's actions than after.
EDIT: More accurately: We know that the information was definitely available after Google's action. We don't know that the information was definitely available before.
It seems far more likely they sat on the disclosure and did not prioritize it appropriately, after google continued to push for an estimated release date (which they never got). Then when the clock was running out, MSFT asked for extension, and Google being tired of getting put off, said no and stuck to their 90-day policy.
all of the above is speculation, and I don't necessarily agree it was the right thing to do. However, I could see folks @ googles sec group being a bit pissed MSFT wasnt taking it seriously, and then decided to stand on their policy just to make an example (surely, MSFT wont drag feet on future disclosures after this, right?).
Plus there's also the small matter of Christmas, and for many countries, significant developer unavailability falling into that period.
What's more likely, Microsoft can produce, test and deploy a patch in a few days, but chose not to until they had to. Or that they did get a patch ready and tested, but not in time for the patch Tuesday the previous month (so actually got it done in ~62 days) but it didn't warrant an out of band release?
It can sound crazy to you (certainly, it sounded crazy to me at first), but taking 90 days to turn around a fix to a piece of software like Windows is not implausible.
First you have to understand the vulnerability: under what circumstances does it occur? Can we build some reliable tests so that we are convinced that we will know when we have fixed it?
Looking at the report of the vulnerability, are there other instances of problems that will lead to similar bugs? Because if you release a patch and then a week later somebody realizes a similar vulnerability, you're going to have to do all of this over again, and not with the luxury of 90 days before the announcement.
Then you have to identify what versions of the software are affected. This is where you start sweating, because were you working on the product seven years ago? If you were, do you remember anything about it? Well, you're going to have to learn fast and hope that the architecture hasn't changed too much.
Then you fix the bug, probably only in one of the affected versions at first, which is probably the version of the software that you have on your dev box. As you're fixing it, poke around in the code to think about similar vulnerabilities that the report didn't find. Recall that Windows is not a small piece of software and building it on your dev box and being able to test your fix may take several hours.
Now you port that bug fix over to all the other versions of this software that are affected and that you still support. For a piece of software like Windows, this is a long list. Hope that the architecture and the code you're fixing hasn't changed much or else you're digging in to remember how Windows 2008 worked and how to fix this problem there. Recall again that building each of these versions takes time.
Now you hand off your fixes to some other people who will independently verify your fixes on some of the supported versions. I say some, not all, because there's going to be another round of testing on the actual deliverables, which is the patch to the operating system.
Which another group is going to make. Most products at Microsoft have a build lab that will take a branch and create either the actual installer disk image or a patch to a previous version. In this case, they're going to create a patch to the latest supported version, for each supported version.
Fortunately, this can probably be done in parallel with the first round of testing if you're pretty sure that you nailed it. If you think that the testing (above) is likely to reveal some problem, then you should hold off handing it over to the build lab because these folks are some of the least appreciated parts of the development team. They're the ones who integrate all the various development teams feature branches into master, resolve the easy conflicts and find the people who need to resolve the hard ones. They have a full time job (and not a trivial one) before you're bringing your high priority build to them, and when you ask them to dust off the build machines for a seven year old version of the product, they're going to graciously accept. But to tell them you didn't get it right and request they start over on a new version is when you start bringing six packs with your request.
Once the patch is created, it goes through the real testing. Because somebody's going to install this patch on all the supported versions, and the SKUs within those versions, to make sure that it works. When I say "it works", I don't just mean that the patch fixes the bug in question (though of course it has to do that), I mean that it also has to not regress any functionality. And that the patch is able to be installed and uninstalled cleanly. This is some annoying work and the longer this bug has been around, the more annoying it is. Remember "Windows Essentials Business Server 2008"? Me neither, but somebody's going to be installing it on a VM and ensuring that your patch works there.
Let's assume that everything has gone well up to this point and you're ready to release it. Most product updates want to get included in Windows Update, of course, because you want your security fixes to just show up to the customer without them having to learn about them, download it and install it because so few people do.
If you're going to miss a patch tuesday, then you need to start asking yourself whether you want to a) try to buy yourself some more time, b) put up several KBs with the patch and ask people to install them manually or c) wait it out until the next patch tuesday. What you decide will probably be some combination of those depending on the severity of the bug. There's a possible fourth option, which is to convince somebody that your patch needs to go out before patch tuesday and while I'm sure that happens, I'm not sure how it happens. I suspect when you're dealing with a bug so critical as to warrant that level of pain for the organization, it will happen.
All of these steps take time. And a big organization like Microsoft moves slowly sometimes - it takes time to find the right people for all of these steps. This is especially difficult over the holidays where many of the "right people" here are out of the office.
Now you could argue that it's ridiculous that it took Microsoft 92 days to get a fix out the door, and maybe you'd be right. But that's another thing entirely. What's clear to me that Microsoft did not simply wait until day 89 to start working on this.
(In relating this story, I would be remiss if I didn't thank Junio Hamano of Google, the maintainer of git, who was kind enough to provide Microsoft with additional time to research and prepare patches for the range of our products that were affected by CVE 2014-9390.)
Let's take a stab in the dark and say it takes 4 weeks to fully test. That means from day one, MSFT would have 8+ weeks of time for developers to attack the problem (yes blah blah patch tuesday, call it 7 weeks if you wish). I don't know their code, and I don't know how pervasive the problem was, but 7 weeks seems pretty generous when you are handed the problem (and not required to fish it out of "user" complaints).
For CVE 2014-9390, we had a fix roughly 30 days after we were notified of the vulnerability. In that time, we released patches for the third-party libraries that we use for Git repository management (libgit2 and LibGit2Sharp), we released patches to three versions of Visual Studio and Team Foundation Server, and we worked with the Git for Windows team to ensure that our fixes were nice and compatible. In order to get the VS and TFS patches out the door, we needed all of this time.
(In fact, we discovered additional vulnerabilities on Mac OS very late in the process. Had these problems affected Windows, too, we would have needed to throw our patches away and start over with the build / test validation process.)
And compared to Windows, Visual Studio is not nearly as big or complex, and can turn these changes around faster.
In this case, the bug was reported on 13 Oct, 15 working days before the first Tuesday of November. Assuming Microsoft couldn't fix and test a change to a core service running on millions of desktops in that time, their only remaining opportunity within the disclosure window was the patch day in December - allowing them only 50 calendar days to deal with the bug.
What's worse is that the bug isn't even all that severe. Effectively Google were trying to strong-arm Microsoft into releasing an out of band patch for a minor issue, which would have knock-on effects for thousands of IT departments. A completely dick move, and thankfully one that's being given recognition here.
Shit like this is why I have a hard time dealing with the infosec community in general – a strange mix of conformance to pointless minutia, a deeply ingrained sense of self-importance (only worsening over time with PR crap like APT), and a fatal attraction with some of the most puerile elements of society. The result is a unique melting pot of genius and dumb that I regularly can't stomach.
They've lost sight of this noble objective with an inflexible policy; who anointed Project Zero guardians of the internet? Why not wait the two days? cui bono?
Their tens of millions of customers who plan internal deployment, overtime, and other things around those specific dates?
> it's Microsoft internal schedule
It's their external schedule actually.
If some companies want to wait 2 days then let them make their own choice. It seems like a pretty stupid policy that nothing (except extreme cases) should get patched except when it's convenient.
They already do via WSUS. Companies get to plan this work to start on the second Tuesday of every month because that's the day Microsoft publishes them. Nobody puts a gun to company's heads and forces them to deploy internally.
> If some companies want to wait 2 days then let them make their own choice. It seems like a pretty stupid policy that nothing (except extreme cases) should get patched except when it's convenient.
This seems to be a complaint about a "policy" which doesn't exist and has no relationship to the topic at hand. I don't even really entirely understand the above.
If you plan your internal deployment updates based on the belief that the schedule will never change, then I'm really sorry for you and your users. In real world, not all issues are reported in advance - some are observed in the wild, and in that case you have to fast-track the fix. If you have no way to do that (e.g. because the vendor only releases fixes on Tuesdays once per month, or because you decided to choose such schedule on your own), then good luck. That might have been appropriate in 1995, not in 2015.
There are many projects and/or companies publishing fixes continuously, and leaving it up to the users when/how to apply them in production. That's essentially what all the linux distributions (RH, Suse, ...) and smaller projects do.
Not entirely true now. Users of MS software have built up their own testing processes around patch Tuesday.
Patch Tuesday was one of the best things MS did when they decided to take security seriously. They realized that testing patches downstream takes time and giving their customers a consistent patch day let them also plan ahead.
[1] http://www.zdnet.com/article/google-stops-providing-patches-...
They sought to dominate the market by means other than having the best talent and shipping the best software. It worked but now they have a problem.
And who can forget this? http://blog.zorinaq.com/?e=74 Developers developers developers.
Any vulns I find will not be dealt with in such a charitable manner. (i.e. you have exactly zero days to fix your shit).
Why on Earth are Google wasting their own resources doing Microsoft's work for them?
Tiny, tiny violins, Microsoft. Tiny, tiny violins.
Unless it hurts a competitor and is bad for their customers.
I don't believe for a second that they would have disclosed this if it was Android and they had a fix that would land within 2 days. No f'ing way.
That's the evil.
I really do hear what you're saying, and while I'm sympathetic to it, I think that it's much more likely that the Project Zero team adopted the 90-day policy specifically because of years and years of vendors playing push-the-deadline. If there was an industry history of vendors acting promptly in good faith, this wouldn't even be a thing, but the politics behind bug reporting and disclosure are really pretty mature at this point, and I really do think it's naive to just chalk it up to "Google wants to embarrass its competition and is playing dirty to do it".
Let me remind you: https://news.ycombinator.com/item?id=8728336
Disclaimer: I work for TAGA (The Arrogant Google Assholes)
>"We asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix," Microsoft's senior director of research Chris Betz said in a blog post.
The issue mentioned in the article [https://code.google.com/p/google-security-research/issues/de...] says that:
> Microsoft confirmed that they are on target to provide fixes for these issues in February 2015. They asked if this would cause a problem with the 90 day deadline.
< Microsoft were informed that the 90 day deadline is fixed for all vendors and bug classes and so cannot be extended. Further they were informed that the 90 day deadline for this issue expires on the 11th Jan 2015.
So (a) Microsoft is unable to comprehend a simple 90-day policy or (b) do basic math.
>> "Google's Project Zero seeks to find bugs in popular software and then give the manufacturers responsible 90 days to fix the problem."
Seems reasonable.
>> "On 11 January, Google publicised the flaw. Microsoft said it had requested that Google wait until it released a patch on 13 January."
Dick move. Sorry, I can't think of any other way to describe it. They may have waited until the last minute (or maybe they really did have to rewrite a tonne of code) but that's no excuse or putting users at risk when you can wait two days. Seems more like a marketing tactic than a desire for faster security patches.
Google headcount: ~49k MS headcount: ~130k
There is going to be a huge difference in speed based on size alone, but MS also has a much greater commitment to regression testing than Google ever has.
Google has embraced an engineering culture where the security team can contribute fixes directly to their own projects. I imagine this creates an unreasonable prejudice culture about how easy it is to implement fixes without concern for regression issues. You can see examples of this in recent e.o.y will not fix bug closures in AOSP. Those savants are going to set the usability vs security debate back a decade by by marking all http connections as insecure.
Finally, don't forget that Eric Schmidt agreed to a recruiting cease fire. For. All of their pride and arrogance, those Google security engineers are never going to escape the fact that they have compromised their own potential maximum value so they can sneer at other companies cultures.
Toxic and stupid.