Slashdot Mirror
Why Can't Microsoft Just Patch Everything?
paneraboy writes "If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities? Had Microsoft fixed a low risk browser vulnerability six months ago, perhaps we could have avoided last week's zero-day exploit. Currently, more than two dozen Windows XP issues remain unpatched. Ou thinks Microsoft ought to fix them all." From the article: "Almost 4 years after the launch of Trustworthy Computing, I found myself wondering why am I staying up till 4:00 AM to deliver an emergency set of instructions (Home and Enterprise) to my readers because Microsoft felt it unnecessary to patch a flaw six months ago that was originally low risk but mutated in to something extremely dangerous."
Here's one from the article flagged: "Less critical" from 2002: SA7127 Check out the first paragraph of this 'less critical' item's description.
By the way, when I read a statement like this one:
If smaller software companies can patch all of their bugs serious or minor, why can't Microsoft just patch all of their vulnerabilities with their massive army of programmers and massive budget?
I start thinking there ought to be some kind of credibility (karma) system for anyone giving public opinions. You know, give the article '-1', give the guy 'Terrible Karma'. Make all his subsequent articles dissapear for you, or even better, replace the article with a 'joke of the day', you know, to dilute the real news a bit.
The biggest problem that M$ has is their size. Sure they have tons of cash and an army of coders, but I bet the left hand doesn't know what the right is doing. There must be so much red tape there as to basically paralyze them. Just look at the lack of innovation coming out of M$. Windows has been stagnant since Windows 98 and Office hasn't improved much since Office 97. M$ is being crushed under their own weight.
gasmonso http://religiousfreaks.com/Just because MSFT has an army of programmers, it doesn't mean it has an easier time patching its old code. Larger groups of people (be they developers or military groups or a bunch of friends going out drinking) almost always require more grooming and maintenance. Look up "Dunbar Number" - here - I find it fascinating.
;)).
A smaller, and thus possibly more agile group of programmers may actually be able to patch more holes than a mammoth like MSFT. Size can be a disadvantage (don't quote me on this
Simpy
Do you really think if Microsoft COULD do it, they wouldn't.
Whereas I agree with you that it isn't as easy as some people think, if any company in the world has the resources to do it, its Microsoft. I see NO reason why a company with this many people and this much money can't get good patches out the door soon after vulnerabilities are found. The only exlplanation is poor organization and bureaucracy.
Patches, no matter what they are, are woven into most things that Microsoft and developers do. There are numerous dependencies, and the numerous divisions, API sets, and partner dependencies make this difficult if even impossible to do on an ad hoc basis, as a generally available patch that breaks things is irresponsible.
Yes, it happens anyway.
Thie is the downside to having a huge, inter-dependent set of apps. Regression testing and dependency testing regimens have to be followed to ensure that small or even massive destabiliations don't happen. This also means that the easy stuff and the most urgent stuff (by their reckoning, not necessarily mine or yours) gets done first, and the tough stuff is just tough.
It's also what makes the closed source model more difficult to deal with, as Microsoft isn't just one pool of programmers, rather thousands of coders working on largely interdependent projects. While it looks like they should be able to do this, it's a reality that it cannot. And it would be irresponsible for them to do so, given so many users, and so many inter-related apps. We just wish it could. That's why OSS methodologies have a bit of an edge in this context (and others).
---- Teach Peace. It's Cheaper Than War.
Where the whole thing is allocated dynamically, based on what someone else told you the size was.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
I agree with you that it's pissheaded of any software company to ignore fixing their security holes, I would suggest that that their "reason" would have something to do with the fact that a new version of Windows and IE are on their way, that don't have the same holes, and the cost/effort to fix those existing problems would be too costly to the newer versions (going from the IE Blog, alot of the IE 6 team has something to do with IE 7, and the WinXP team is involved in WinVista).
That being said, perhaps the problem here is that it costs less for Microsoft to ignore security holes than fix them. That would mean the solution is to forget adding to the "Microsoft so bad" arguments and start pressuring lawmakers to punish companies that are negligent and exposing consumers to harm.
Once the cost of inaction is greater than the cost of action, we'll start seeing a difference.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
I think you have hit on a, if not THE, reason MS has problems providing timely patches. It's bureaucracy. Take a look at any large company/institution (i.e. automotive companies, government, etc.). I know from personal experience working for both government and a very large global company that it takes forever to get anything done. This is due to the simple fact that the decision process takes forever because of the number of people that have to sign off. You do not have this problem with smaller companies because you have more decision making powers invested at lower leveles (i.e. the power to do the right thing is much closer to the developer level as opposed to somebody in an office in another state or country making all the decisions).
Do what is right and let the consequence follow
This is actually only true about 50% of the time, but it is a very good thing to pretend is true when fixing security bugs.
MS discovered a bug that sent execution off to a magical realm of fairies and candy, and decided 'Well, that's okay, we'll fix it someday.', which was just completely idiotic. They didn't even bother to notice that the magical realm was user-supplied text, thus begging to be replaced with actual machine instructions.
If corporations are people, aren't stockholders guilty of slavery?
I've worked for MS in the past, in their Windows Sustained Engineering (WinSE) division. So I think I can bring some valid criticism to this situation.
The major issue is: How many customers is it affecting? Nevermind that it's a huge security flaw with the potential to be exploited. Has it been exploited yet? If so, by whom and who was affected? If nobody has been affected, why not? These things go into determining the prioritization for a fix.
Another slew of issues is: How many man-hours will it take to fix the bug? Can the functionality which causes the bug simply be removed without terribly ill effect? Does the person who originally wrote the code still work at Microsoft? Given the fondness for contingent staffing (aka CSG, contract workers) at Microsoft, a good number of people come and go on pretty much a 6 to 12 month basis. I know that some divisions tend to not let contract workers do development expressly for this reason, but there are always exceptions. (ie, a full-time employee (FTE) leaves the company and the company has a CSG with the skills to replace him in the interim while they hire a new FTE) Also, how many man-hours will it take to test the bug? If it will take 5,000 hours to test a bug that presently affects nobody, it ends up near the bottom of the priority list. If it will take 2,000 hours and they have a report or two from customers who have experienced the bug themselves, fixing it becomes a higher priority.
You also have to keep in mind that Windows isn't just one program. Windows XP, for example, is XP Home, XP Pro, the new XP N (sans media player), and Windows Media Center Edition I believe is also XP-based. So that's four platforms that need a fix developed and tested. That doesn't seem like much, right? Ok, Microsoft localizes their software in 44 different languages, which will all need to be fixed and tested. Four platforms, 44 languages, that's 176 different variations which need to be fixed and tested. They will generally not release a fix for only one language at a time.
The open-source community is filled with people with a lot of free time on their hands, as is evidenced by the fact that they are willing to do development work for free, and some of them do quite a lot of that development work. If a team of developers and a team of testers were to volunteer at Microsoft, giving their time over at no charge what-so-ever, I imagine you might see more of these bugs that don't actually affect anyone get fixed sooner. But as long as the company needs to make a risk-vs-cost analysis, bugs that don't affect anyone (yet) will not get fixed any time soon.
Reinvent the wheel only at either a lower cost, greater effectiveness, or your own personal enrichment and satisfaction.