So there are 3 issues [1] against OS X, released a while ago, and one against Microsoft. Why the HN focus on the Windows bugs? At least Microsoft is communicating with Google, and have patches planned, just not on the exact timeline of the arbitrary 90 day deadline. Is there something about the OS X ones that doesn't warrant the same exposure/discussion?
Because a Windows zero-day is a major risk to our economic system as our business and governments infrastructures run on MS products for the most part. OSX just doesn't have that level of install base and for the most part its installed on consumer/residential equipment. Heck, most OSX shops I've been part of have bog standard Windows AD on the back-end. Windows, good or bad, is everywhere that matters.
Google seems to think Windows is a poorly written php app where you can just change a line and walk away. Windows testing has to be top notch and handle a huge about of 3rd party software, libraries, and drivers. The 90 day deadline really speaks to how web devs think and not how application engineers with massive install bases on a variety of equipment and running a variety of software think.
It does piss me off to be honest. MS isn't saying no to the updates its just saying, "We're doing them in 100 days, not 90 as out of band patches are really bad for the ecosystem and we need more time to certify our changes." Google is saying, "Fuck you. Buy an android tablet, microserfs."
Imagine if Google found the Kaminsky DNS bug. The internet would have melted on day 91 when google told everyone, "Sorry, too bad." I think this kind of "fuck you" disclosure should only be for attacks that have been demonstrated to be in the wild. Now they will be in various crimepaks, botnets, and trojan droppers within hours.
I used to work on telephone switches. We had 31 million lines of code. I can't remember the entire details since it was over a decade ago, but I believe Bellcore required us to deploy fixes for 70% of all reported bugs within 30 days. We were a huge, fat-ass company with 5000 programmers working on the same project and managed this. 90 days is a lifetime to fix a security problem.
The point behind having a deadline before publicly disclosing is that if one person has discovered a security problem, then some other people probably have as well. It is fair enough to give vendors time before you make disclosure but if the vendor is moving too slowly -- for whatever reason -- you want to give the consumers a chance to implement their own security work around. Because if you don't they are vulnerable.
Giving Microsoft 90 days to fix an issue is fine. They can prioritize it anyway they want. If they think it is super urgent, they can almost certainly get a fix out. If they think it is not so urgent, then they don't have to make a fix -- but they know that the problem will be disclosed.
Nowhere in Google's documentation of this problem do I see a massive issue. Google gave MS 90 days. MS found a fix but there was another bug so they couldn't meet the window. Google released the information. Nowhere do I see MS requesting more time or any indication that anybody in the process thinks that anything went badly at all. It didn't meet the disclosure deadline. That's just the way it goes sometimes.
The Kaminsky bug was disclosed 30 days after it was announced, and by then, pretty much the entire internet had been patched. Google is being generous with 90 days, and Microsoft is being utterly incompetent.
Then perhaps MS ought to shorten its bug fixing period. Three months is quite a long time to find a bug, fix it, and run extensive tests. What good is a fixed time period if you're willing to extend it just because one company can't pull their shit together?
As for the Kaminsky DNS bug, it was leaked more than a solid week ahead of the time he intended to release it. Sure, patches had already been released, but how about if other companies had said, "We need a full month to test this patch prior to rolling it into production."? They would have been putting themselves at risk. Mind you, this bug was simply an extension of an earlier flaw - too small a range of transaction IDs, and some DNS projects (`djbdns` comes to mind) had already mitigated it (ostensibly fixing the root cause as opposed to the symptom). Had the other vendors mitigated that flaw in a similar fashion (they had almost a decade since djb pointed it out), they would not have been vulnerable. However, there was no looming deadline, so few of them even noticed until an actual attack was possible (as opposed to fixing issues as they come up).
What happens if someone leaks the bug early? Or if a malicious adversary discovers the bug at the same time? The whole idea of these deadlines is to force security bug fixes to be released ASAP, taking precedence int time and importance over all else.
Deadlines can't be adjusted just so MS can screw around for longer doing nothing. If it's really taking them more than three months to fix a bug and release patches, perhaps they need to rethink their priorities and dedicate more resources to the task. And perhaps we need to seriously reconsider our dependence on their products.
Everybody is saying that 90 days is too much, even at MS' scale. So, taking into account that everybody seems to know very well what MS has to support, what is a good number of days to finish all the work that needs to be done?
90 days seems just fine. What they need to do is give greater importance to bugs and apply more resources accordingly.
When it actually affects them, they aren't hesitant to do whatever the hell it takes, with no regards as to the consequences for others, with zero warning at all, as was shown during the whole fiasco when they effectively took down NoIP's services. Meanwhile, when Google holds them to a perfectly reasonable deadline, for the extremely valid reason that bugs should be fixed on time, Google is evil?
Given their scale, they can afford to dedicate larger teams of people to the task of fixing security vulnerabilities. They can afford to hire independent security researchers and whatnot to help them find and fix such vulnerabilities.
If they need to break some third-party application in fixing a security vulnerability, that's okay. Because that application can also be fixed by its developer, and security needs come ahead of an app here or an app there. Besides, it isn't as if users of Microsoft's products are not used to the concept of having stuff break all the time anyways.
Have you noticed how quickly MS starts releasing patches and updates when a 0day comes out? That shows that they are clearly capable of doing whatever they need to do pretty damn quickly. They just don't do that with all security vulnerabilities, due to "business reasons", and as a result their customers suffer.
> If they need to break some third-party application in fixing a security vulnerability, that's okay. Because that application can also be fixed by its developer, and security needs come ahead of an app here or an app there.
That is exactly the opposite of what Microsoft's customers think. If Microsoft began taking this attitude, there would be mass outrage. And maybe rightfully so: for countless applications in the Windows world, the developers are no longer around or ask for money to update the software. People are more likely to simply not update or roll back the update after they get it.
> Besides, it isn't as if users of Microsoft's products are not used to the concept of having stuff break all the time anyways.
They actually aren't. It certainly happens, but it's very rare that a Windows update (or even upgrade) breaks anything.
In my experience, the only kind of PHP (or any) app where you can change just one line and walk away is a well written one. It's the poorly written ones where you have to change dozens or hundreds of lines, and run away screaming. But point taken.
The issue isn't fixing the flaw. The issue is testing.
Say I patch a security flaw in a webapp I run. If I screw up the phone starts ringing, and then I undo the patch I made and think some more about it. Meanwhile no one has any clue about the flaw.
If I have to deploy a release to fixed endpoints, I have to think about what could possibly go wrong on every device out there running my software. Plus, if I didn't fix the problem completely, the nature of distributing the patch has now told the rev-eng community exactly where the problem was.
Google once pushed out a version of their browser that stopped the entire browser from working when their sync server went offline (for anyone using sync in their browser). Microsoft does not want even 1% of their users to suddenly be unable to use their computers.
Ya, my comment was too brief. I was mostly reacting to the HN posters that basically were saying "Microsoft evil" by gently pointing out that other companies are leaving bugs in for longer than Microsoft. For example, someone posted "Other companies fix such bugs in days." Well, there are counterexamples, aren't there (OS X at the moment).
I think what Microsoft is doing is really hard. I don't have insight into their process, having never worked there. So yes, we can speculate that they could do things much faster. But can they? I find it rather tasteless to just assume so with no evidence and to then go on and call them names. I dunno, maybe they are falling flat on their faces internally, or maybe the team is performing heroics at the cost of personal lives, or maybe it is just business as usual.
But, it was also an honest question. Maybe there is evidence out there that Microsoft is just failing, and I haven't seen it or my reading comprehension failed me and I saw it but didn't register it.
But mostly, I am tired of the hurl accusations and drag people&companies through the mud meme that happens here, and this seemed to be more of the same (again, open to evidence, not claims, to the contrary).
Another perspective is that Google found a bug through which they (and other businesses) can be owned, and ms is saying "fuck you" to google by not fixing it for months. Without this disclosure strategy, google wouldn't have any leverage to get bugs critical to their business (and to most other businesses) fixed. If your company is using windows, google is doing your company a favor.
I think the issue is not the bug count, but that Microsoft tells Google "we will release a fix on day X," and Google says "X is past an arbitrary day we chose, so sad" and discloses a zero-day. Some people think it's an irresponsible PR stunt by Google, others that Microsoft would just put off fixes forever if Google didn't do this.
Maybe there's a similar story with OS X, but there doesn't seem to be a public record of it.
I meant to say that there would be zero days between when I could patch my (hypothetical) Windows machine, and when people could start hacking it. The Wikipedia article you linked elsewhere seems ambiguous, e.g. "It is called a "zero-day" because the programmer has had zero days to fix the flaw (in other words, a patch is not available)." Microsoft has had something up to 90 days to produce such a patch, but hasn't for whatever reason.
I really dislike your description because while it is technically true it heavily implies that they decided on dates on a per-bug case, when they decided on a flat 90 days.
Then again, 90 days contains 2.5 of their fix cycles. If the vulnerability really is serious, and they can't fix it in that time line, they should exit the business.
Google roughly supports one version of their product on 2 OSs.
Microsoft supports all versions of all their products for 10years+ after release, integrated with a combination of all other products they have shipped in that same time-frame.
Needless to say, Microsoft needs to do more QA on their bug-fixes before they can safely release it to all customers without the risk of causing new issues.
It's easy for Google to be big in the mouth when they don't bother to support their existing customers properly.
Speaking of being big in the mouth: Did you know that Google isn't back-porting security fixes to older versions of Android either (only 2 last minor releases)? I guess supporting more than 40% of your user base is too much work.</sarcasm>
Guess which side my sympathy is leaning to in this case.
> Needless to say, Microsoft needs to do more QA on their bug-fixes before they can safely release it to all customers without the risk of causing new issues.
IIRC Microsoft also releases pre-versions of their patches to select customers so sysadmins can test the patch doesn't cause issues on their deployments.
No, I think the "issue" is that Apple doesn't talk to the media, while Microsoft immediately complained to some big tech sites about it, which then wrote the story from Microsoft's point of view.
Even if we're talking about such a massive roll-out to millions of machines, with various versions of the OS running on various hardware? I don't know how easy or not the actual patch is to produce, but it's not out of the realm of possibilities that they did run into a compatibility issue that they wanted more time to sort out. Think of the outcry and damage to their business if they rolled out a patch that accidentally broke some installations.
Yes, even then. Imagine if the bug had been found by security researchers who believe in full disclosure. You think it's reasonable for Microsoft to allow dozens of rootkits and viruses to proliferate for more than three months, for botnets to grow to hundreds of millions in size? Microsoft's release process is broken.
Sure, three months is a long time to fix an issue, but what does Microsoft have to gain by taking longer to fix an issue of this severity than it believes it needs to? If Microsoft released the fixes when they were going to, and Google then released the details of the issues and when they first reported them, Google could still make a stink about Microsoft's turn-around time on critical security bugs, and there wouldn't be any gap between global notification of the issues and a readily available fix for them.
Put another way, Google may have just notified the world of black-hat hackers of an issue they weren't otherwise aware of, an issue that demonstrably will not be patched for some time. If that is the case, then Google just recklessly endangered people's computers in the interest of raising awareness of Microsoft's poor turn around time on these issues. There is also the very real chance that this issue was already known by the black-hat community, in which case there isn't nearly as much lost by reporting here, but that's a gamble Google is making in order to make a point.
And if we're talking about a true 0-day being exploited in the wild? Microsoft is still unable to get a patch out in less than 90 days time? That's flat unacceptable. They need to be more responsive than that.
Think what you want, but IMO 90 days (even rounded to the nearest patch Tuesday) is plenty of time to fix the critical security issue. Clearly Microsoft is acting weird here.
In another news, google stop fixing security bugs which cover 60% of the current android users (4.3 or older). Not saying microsoft is right, but they just dropped windows xp support last year (that is >10 years of support).
Thank the carriers for being jerks for that one. I know on the last time this article came up I took a hard line on them, but upon further reflection, it's not like they can just write a patch and have it out in a week. Heck, it takes months for point releases to go through acceptance testing at the carriers, and probably not insignificant amounts of cash.
At least they're starting to own more of the ecosystem. I wouldn't expect this to be as big of a problem on newer devices.
Carriers not rolling out updates a) doesn't waive Google's responsibility to roll out patches to their largest OS cohort and b) is really all Google's fault because they let the carriers get away with it and have never reigned them in even after years of incompetence on the carriers' part.
Look into the "Open" Handset Alliance (especially findings from the SkyHook lawsuit) to see how much control Google actually wields over manufacturers. Google controls what software and services are bundled with handsets (see SkyHook). Google prevents manufacturers from creating competing Android devices using forks of Android (see Acer; that's why the quotes around "Open"). If it cared at all, Google could easily require manufacturers to provide regular updates.
See the beauty of the situation is that they are all at fault. However, only one company makes the core OS software these hardware manufacturers run on.
Perhaps if Google provided the update and the pressure could be put on the manufacturers to roll out the update to their paying customers...?
That assumes that you can make enough consumers with these (relatively) older devices care loud enough for any "pressure" to be applied to the manufacturers.
Security updates aren't sexy and don't get applied unless they include shiny things along with them.
Right now, the customers have zero power because Google and the manufacturer simply point fingers at each other as to who's to blame.
Releasing the update gives the customer power to press for pushing their manufacturers.
The whole model where carriers or manufacturers can send updates is ridiculous. Carriers update baseband. Manufacturers should defer to google for Core OS updates and Google Play. The fact that they're even involved is simply a recipe for disappointment.
It's bad for everyone because compromised machines simply reward and embolden the criminals which will eventually increase the harm to everyone who ins't a criminal.
No. They are not all at fault. The only one's responsible for updating their phones are the companies supplying the phones. There is nothing stopping Samsung, Sony, HTC, LG from creating and submitting a patch to AOSP and they are the ones who actually have a responsibility to their customers to do so. There is also very little stopping them from updating their phones to 4.4.
> is really all Google's fault because they let the carriers get away with it and have never reigned them in even after years of incompetence on the carriers' part.
You are again blaming Google for the carriers policy of updating phones not even belonging to Google. Do you really think Google is involved with a carriers agreement to carry Samsung phones?
Last time I checked, Nexus phone's can also be updated without the assistance of the carrier.
It's not Google's product any more than it's the Linux Foundation's product. Both are just organizations with software built into somebody else's product. Nexus phones purchased from Google are Google's product.
Separately, complaining that the vulnerabilities are unpatched in Android is a rubbish argument. They are fixed in the latest release.
I can't fault Google for that. They've released subsequent versions of Android that has fixed the vuln in WebViews.
Also, they took a major step in Android L by removing the WebView from the Android Framework and distributing it via the Play Store, thereby, enabling them to push security updates to all newer devices without the devices themselves having to update to a newer version of Android to get security fixes.
Microsoft also released subsequent versions of Windows, but they still keep updating old ones.
I don't understand why Google hasn't build an update process for Android in the first place. Everyone knows the OEMs won't update if they don't have to.
I consider google with android to be a similar position to the linux kernel on my servers. I don't expect any of the kernel team to produce a patch for my 2.6.18 kernel I am running on a RHEL 5 system, I expect Red Hat to do that.
Why doesn't Samsung / LG / HTC manage Long Term support for Android versions, back port the patches and roll them out? Alternatively why don't they all pool together and manage an LTS version for customers.
It seems crazy that the company that has a relationship with the customer doesn't have to support the customer, and everyone instead blames google who wrote the code. The android vendors could back port, create alternative patches or simply make the device able to be updated to a more recent version.
Google is not responsible for supporting Android. Android is fully open source, and OEMs are responsible for their devices. AOSP is distributed under Apache 2.0 license https://source.android.com/source/licenses.html which stipulates there's no warranty or support.
Google supports Play Store and related services, but webview on 4.3 and older is not part of that.
Android is "fully open source" except that Google writes 99.999% of the code in secret. Rarely they will accept a pull request but there is zero transparency into that process.
One thing to note, more and more of what constitutes the android user experience is being pulled into the Google Play Services app which is closed source. A big part of the reason why is that it gives Google a better negotiation tool to use with carriers as they have to license the use of the Google Play platform and that isn't really optional in modern Android right now. AOSP has been left behind not in support but in more and more features of "Android" being closed source. Another huge benefit is that tons of bug fixes that would have required coaxing carriers into supporting a software update on the phones can now be applied just by patching Google Play Services and rolling it out as an app update.
Why does Google still rely on the carries, even though they know for years, that they don't have interest in updates. They could easily implement an update mechanism for the core of Android, like they do for App-Updates as well.
When i buy a Laptop from HP, Dell, Lenovo or any other OEM, i still get Windows updates (even if i don't upgrade to the latest Windows version). I would really like to know why it is not possible for Google to implement such an update system? Blaming carriers is easier i guess.
That's exactly what they are doing, although perhaps for two-fold reasons. More recent versions of Android move more and more core stuff into the Play services. This enables Google to push updates to core services like normal app updates. It also ensures that a lot of core APIs are covered by services only available on phones licensed with Google.
I'm honestly not sure what you're talking about. Android does have a system update mechanism. You go to settings -> About phone -> System updates.
If manufacturers / carriers change that to check for updates on their own servers, rather than google's - which they can do since Android is open-source, and so they all do - then that's how the system update mechanism will work.
I don't follow what you're suggesting google could do about that, apart from moving more and more OS functions out of the core OS and into google play services. Which is exactly what they've been doing.
Aka, no longer part of Android. The millions of users without Google Play will have an even less functional OS than they used to, all in the name of greater control by Google.
It should be noted as a point on this specific bug that, since wasn't fixed in the EXTRA time allotted and subsequently disclosed, this is a good thing. Impersonation is something that Windows Administrators can readily disable and manipulate via Group Policies and Active Directory. There's not a one-fix-for-all disable in this case, because impersonation is used in very nuanced ways. That being said, every organization can quickly and with a little effort tighten up their impersonation rights.
What I would like for Google to do is instead of publishing the details of the bug, after the deadline they would publish vague summary of vulnerability, so people would know it exists, but not quite able to exploit it right away. That would both inform people about danger and put pressure on MS, but without puting so much risk onto systems.
That is not providing information about how to protect against the vulnerability regardless of a patch from Microsoft. Full disclosure is the only way to go.
I can understand both points of view with the disclosure of the security issue. A while ago I discovered some security issues with Adobe ColdFusion and Railo. I wish I had put a deadline on disclosing the Adobe ColdFusion issues, as they dragged their feet so much (with admitting it was an issue and progressing with a fix) that at points I felt like throwing in the towel. Regrettably, instead of lighting a fire under their ass, I waited. At the time I was working on an open source side project, which would have pointed fingers towards where the issue was for any curious people.
I ended up halting development of my project while I waited for Adobe, to the point where I no longer wanted to work on it. I had stopped for too long and I didn't want to dig anything else up. Having no legal type knowledge myself or knowing anyone who could offer such advice, I was also too concerned to reveal anything for fear or any legal reprise.
So, the threat of security disclosure is warranted to pressure others into putting in the effort. However, the impact of the disclosure should be considered. If it will seriously affect others (who aren't responsible for the fix) and put them at risk, there should be the flexibility there to work with them on a deadline.
They fixed one of the issues I reported. I don't believe I had official confirmation of the other issue I had with Railo being resolved. I probably should try it out again on their latest version, but I don't use Railo and haven't found myself with much fondness for ColdFusion either.
But I should probably pull my thumb out and check ;)
Google should ask money to keep it secret longer. Around 30 000$ a day IMO. Then give this money back to android device manufacturers scammed by Microsoft.
As they should do, Microsoft is notoriously bad at security patching and have had more than enough time to issue a suitable fix. It won't be until we start doing this will all (closed sourced) vendors that'll we'll actually see improvements - otherwise what incentives for these company's are there? Making themselves look good is their primary objective, right next to sales.
Hopefully this inspires change within Microsoft's development processes. Security issues are a big deal. While 90 days is difficult for them (and other companies), I'm sure with some investment on process improvement and or hiring more staff, they can get these fixes out faster. They owe it to their customers to do the right thing.
Given that the holidays occurred during the 90-day period, and that Microsoft was paying attention and made a fix, and that testing found an issue with the fix, I think it would be reasonable for Google to give Microsoft an extension on the deadline.
The statement that "if 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public" is little more than Google claiming the computer made them do it.
Somehow I foresee Microsoft trying to rush out a security patch to a hugely complicated piece of software so it can be distributed to hundreds of millions of devices running countless hardware configurations just to appease Google ending very poorly for everyone but Google's marketing department.
Yeah, Google really should not really worry about discovering all those endless Windows vulnerabilities and let all those hacks (such as Sony's) to continue. Security by obscurity.
The first thing Microsoft does when they learn about a zero-day is to hand it to the NSA. Microsoft doesn't get to fix it until the NSA tells Microsoft they're done exploiting it.
Google may be pissed about this. They've been pissed off before about NSA's shenanigans.
I suspect that Google is an NSA front organization, which is why Google appears to be pissed at the NSA.
In any case, I think both Microsoft and Google would be high value targets for all sorts of infiltration by the NSA, whether it's sanctioned by the power structures of these companies or not.
I'm just a single HN'er and I wasn't really thinking of PRISM... I was thinking more along the lines of how obviously valuable it would be to the NSA to either A) start companies like Google or B) infiltrate them.
I also said that I suspect that's the case, not the I assume it to be. Given that the NSA seems to do what it wants and the obvious motivation for infiltrating or starting companies like Google...I think the suspicion is warranted.
Half a year? I wouldn't assume these guys at Google are the only ones discovering these vulnerabilities. Longer period won't improve Windows security. All it can do is keep better image of MS.
Either Google is sending Microsoft bug reports like rapid-fire, and Microsoft has already fixed dozens of them that we haven't found out about - or for some strange reason, Microsoft didn't fix the only two bugs Google reported in the last 90 day period.
If that's the case, then either Microsoft forgot about them, or they carefully orchestrated a PR scandal against Google (wouldn't be the first time - like the time they built an unauthorized Youtube app that Google specifically told them not to build, and then notified the whole media about it, putting words in the reporters' mouths).
What I find interesting is that there are at least a couple of cases in which bugs were marked as being subject to the 90-day disclosure deadline, but not made publicly visible until days or weeks after the deadline had passed.
There are other bugs not reported by Google that Microsoft has to investigate and resolve as well. I doubt Google is the primary channel of security bug reports.
Microsoft informed us that a fix was planned for the January patches but has to be pulled due to compatibility issues. Therefore the fix is now expected in the February patches.
So, they met the deadline and fixed the vulnerability, but due to compatibility issues had to pull it before being released through Windows Update.
... so they didn't meet the deadline. The deadline is for a released fix, not a theoretical fix that nobody can install in reality. They could, and should, speed up their process. But they won't, unless they get pressure from outside.
...yea it's easy to say when most people here should know how hard it is to ship any complicated system on multiple platforms. Actually, just making an app work for all major versions of Android could be a nightmare. And...what do you mean "they won't speed up their process"? Microsoft has released zero-day security bug fixes less than 90 days so many times before.
I didn't say it was easy. I said Microsoft could do it, and that's true. Microsoft can do hard things, if it's a priority for them. Apparently they've judged that the damage isn't worth prioritizing these fixes higher.
This is conjecture and frankly nonsense. If the time frame was 5 years, would MS really find a reason to delay and to publicly cry out loud? No. The only org being unreasonable is big G.
For one, IBM does, and has for some time. Others in the thread note that Red Hat and others do. Apple does iOs, which runs on far more devices than anything else mentiond in this thread.
The total number of iPhones is not really relevant to the discussion, the number of iPhone models is. Testing a fix on an enumerable number of iPhone models in the wild (lets say iPhone 4, 4s, 5, 5c, 5s, 6, 6+) is nowhere near the complexity of testing Windows against the variety of devices that it would need to be validated against.
Few of these issues are in driver level code, so the variety of devices doesn't play into that.
The most recent one is somewhere in the User Profile Service, which is about as far away from the hardware as possible. Shellshock didn't need testing on every possible hardware combination it runs on either, did it?
More resources should make the number of fixes possible per year greater, but it may not substantially reduce the time from notice to fix any single issue (and may, because of organizational overhead involved, sometimes increase the time for particular fixes over an organization with fewer total resources.)
Maintaining code is not a trivially parallelizable function.
> Maintaining code is not a trivially parallelizable function.
Yes, I know this, thank you.
But we are talking about billions of dollars vs. millions of dollars (for Linux / BSD). We are talking multiple orders of magnitude(!) more money. I realize there isn't a Silver Bullet, but the fact that what we have heard coming out of Microsoft about they're management practices year after year is ABYSMAL, it is not an excuse. Especially when people who are working for free, with no/little organizational support, can beat them at releasing security fixes.
> because of organizational overhead involved
So maybe they should fix it? How is their incompetence at running an organization a valid excuse? If it was a problem they cared about they would be researching how developers and teams of developers perform best, how best to organize code, etc. Instead they used stacked teams for years on end. I have no sympathy.
If it's as serious problem maybe they should stop making new operating system features and devote more resources to fixing, cleaning up, depreciating, etc. the ones they already have?
They are making business decisions, and their ineptitude at security is a result of them. There are no excuses of "they are the only one's doing X" for "they are bad at doing Y when they do X" when they are promising Y!
How is it a fallacy? Because management is incompetent? If your budget goes from 1M to 10M even a child could show you how to spend 1M and throw the rest into a big fire or something. Maybe run two agile teams at 1M each.
Yea, but that doesn't mean you still don't get some additional speed out of hiring more developers, especially when correctly organized, with sane management policies, and good software development practices.
The point is that Microsoft has the money to hire 100x more developers than the other guys, they should at least be well organized enough to deploy a part of that man power effectively.
Lets put it this way, there are 7 companies out there (at least) maintaining various different distributions of UNIX that can patch quickly, why can't Microsoft patch their 7 operating systems as quickly? From my view what you are saying is that because Microsoft is a monolithic company with 7 code bases it is somehow harder than 7 companies with 1 code base each? How does that track? Especially when Microsoft has a 100x more money than each of those other companies.
I'm not saying there is such a thing as a man-month. I'm saying there are ways to organize production, teams, and software so that people can provide more work than in poorly managed environments.
My point wasn't that more money itself induces potential slowness, but added infrastructure & scope that surround it (not necessarily even in the same department) often can.
Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
Other departments matter in some ways, but bugfixing can be self-contained and mostly avoid slowdowns.
But even more important is that these outside slowdown effects are pretty minor. If this was software development then you might have no recourse and you'd be somewhat slower overall. But this is handling many many independent projects. You can hire more teams without having man-month problems, and then handle bugs efficiently.
>Ignoring more money is pretty unlikely to be an option as a whole, and inefficiencies generally cascade down to some extent.
Again, I blame management. A nice sturdy cardboard box as a manager is impervious to social effects from other departments, and it can soak up extra cash too.
I expect anyone being paid to manage to do a better job than a box. Not to go along with the flow uncritically.
Microsoft seems to be making a habit of not taking these vulnerabilities seriously enough, as this is the second time in the past few weeks that this has happened.
3 months is more than enough time to fix an important vulnerability that is potentially being exploited in that time period and longer. The threat of shouting it to the world should be enough to make it a top priority.
So, since I'm in the dark beyond what the links say, what was the timeline for this disclosure?
The github repo readme says "A few days ago, Google has introduced a new version of ReCaptcha" which seems to me like it was a 0-day disclosure. If that is the case why would it be hypocritical of Google to ask for the repo to come down so they have some time to fix the issue?
[1] https://code.google.com/p/google-security-research/issues/li...