I haven't been able to find anything remotly equivalent on the x86 side, but I might go ahead and build a couple of PC's out of standard components anyway.
One could also view this differently. MS is closed source, so if that many were found by people who don't have the source how bad would it be if they had the source?
One must also consider that Windows has a vastly higher level of exposure than any of the other platforms. How well would the unixes have fared if they had the user demographics and marketshare of Windows ?
The second issue is with Linux sources, the bugs are being vetted out of the code at a much faster pace making it ulimately more secure.
People say this a lot, but it never seems to get supported with anything more than hand-waving.
Statitics lie when taken out of context.
Statistics never lie, the people interpreting them do.
Windows: XP,NT,Me,98,95
note that these are all x86...
NT runs on multiple platforms. x86, x86_64 and Itanium, at the very least, must be considered (plus PPC for the Xbox360, but I wouldn't consider that relevant to this discussion).
In regards to numberpumping, it is generally a lot easier to find a vulnerability in a Linux/Unix/OSX program than a Windows program, for the simple reason that a greater proportion of L/U/O programs are open source. You have two angles to attack from, and if you find some problem in the code, you can most likely find other instances in the code where the exact same mistake is made.
On the other hand, you have to take into consideration the _vastly_ higher exposure level Windows has.
Now, assuming that Linux, Unix, and OSX collectively run on 5 architectures (QUITE modest),
Not really. x86, x86_64, P[PC], SPARC, Itanium. There aren't many other platforms out there that are likely to be relevant to these stats.
[...] that is 5 times the code for any architecture and hardware related problems to arise in, although I would be willing to bet that it doesn't actually increase numbers that much.
Somehow I don't think there are completely separate codebases for each platform. The vast majority of code in an OS isn't platform specific.
*sighs* I know. It frustrates me to no end that Operating System is being redefined.
It has been changed from the layer of software that operates the hardware and provides the lowest level api for accessing it (kernel, and kernel api); to the layer of software that interacts with the user.
It hasn't changed at all, like many other things, it's simply dependant on context.
When in the context of academia and theory, "Operating System" (basically) means the kernel.
In any other context, it means a bunch of software packaged together to make a computer more useful than a paperweight.
I'd like to see OS versus OS. For linux you count kernel flaws (everything else is user space and can be swapped out with other apps). For windows you count flaws in the software that remains after you remove everything you can through proper channels (uninstall, not simply delete).
That's not even a remotely equitable comparison.
If you want to fairly compare "OS versus OS" pick a Linux distribution with a similar software bundle to Windows. But comparing a kernel to an entire OS bundle is so ridiculously one-sided (not to mention worthless for any sort of real-world conclusions) it's not even worth considering.
Actually, *any* running process with higher priveleges will do (even windowless ones or ones on a different desktop).
No, an exploitable process must have a window on the user's interactive desktop. That's how it works - by sending messages to windows.
Further, most admin-level processes are broken in this regard. When I say most, I mean most of the ones that are supplied directly by MS.
Examples ?
The vulnerability exposed by Shatter is precisely why Microsoft have always recommended never having processes with elevated privileges running on the users interactive desktop as a matter of course. IOW, Shatter largely depends on poorly written software to be dangerous.
Have you ever actually tried to run Windows XP as a non-admin user? You can't install any new USB devices, and on about 1/2 of the devices I've tried, you need admin rights to plug them in whether or not the drivers have been previously installed. I tried to set my dad up that way, and after about a day we both agreed it was hopeless. He's got a digital camera, card reader, printer/scanner, and VoIP headset all of which need Admin rights *JUST TO BE PLUGGED IN*. It's not a policy mistake if the "correct" policy prevents the computer from being useful.
You are mistaken, or lying. I regularly plug in USB (and Firewire) devices as a non-Admin user and they work fine.
Under XP, you need to be an administrator or you won't be able to edit a graphics file with Paint, the default program launched when you double click a JPEG, GIF file. Something having to do with the requirement of writable registry settings that non-admin users don't have access to.
Really? Than why is it that the vast majority of programmers writing for other platforms can get it right? Moreover, I'll be willing to bet that there have been cases where the same piece of software requires Administrator privilages on Windows but doesn't require root on unix-like systems (e.g. Linux, BSD, Mac OS X).
And I can give you one - Doom 3 (well, I've never actually used Doom 3 under Linux, but I'm willing to bet it doesn't need root to run).
Why does Doom 3 need an Administrator account to run in Windows ? Because it tries to write configuration data (that on Linux almost certainly goes into ~/.doom3/doom3.cfg or similar) in %PROGRAMFILES%\Doom3. All you have to do to run Doom 3 under Windows in a regular user account is change the permissions on a single.cfg textfile (actually, it will run by default, even as a regular user, but it won't save any settings you change in the game, so functionality is reduced).
How is it at all Microsoft's fault that Doom 3 has been written this way ? Microsoft's own best practices say not to do it. Any semi-decent (and probably even the bad ones) software development course will also recommend against it. Per-user profiles and registry keys have existed in Windows NT since 3.1 in 1993 and Windows 9x since 95 OSR2 in 1996 (not that it's relevant, since Doom 3 is only supported on Windows NT derivatives). COMMON SENSE dictates it's a dumb idea. Yet still someone at id used the program's directory rather than %USERPROFILE%\Doom3 to store per-user configuration data.
99% of applications that "require" Administrator access to run suffer from this sort of stupidity. Needlessly trying to open files read-write (rather than read-only) in system and application directories. Storing configuration data in the application directory, system directory or system-wide registry keys instead of per-user locations that have existed on every version of Windows sold for nearly a decade.
Why is any of that Microsoft's fault ?
Surely Windows has always discouraged programmers from requiring administrator access, since the dangers of it have been known in the UNIX world for decades... right?
Correct. And the facilities for writing multiuser-friendly applications have been around since ~1996 even in DOS-based Windows (although obviously it had no way of enforcing user separation) to help developers write applications that could work on both platforms.
First of all, I never said Microsoft was completely to blame, and second, I don't give a shit about Microsoft's "political position" or what's most cost-effective for them; they caused the problem so they should fix it regardless!
I suppose you think women "cause" the problem of getting raped, as well, by wandering around in anything short of a burlap sack.
Obviously it's not Linux's fault, because Linux doesn't encourage such shitty programming. Microsoft, on the other hand, did at one time. That's what makes it Microsoft's fault!
When did Microsoft encourage "such shitty programming" ? Please provide evidence for your answer.
Nonsense. Until M$ ships M$Windows with user access non-admin by default it's still largely their fault.
Why ? Why is developer incompetence/ignorance/laziness Microsoft's fault ?
The application developer is doing nothing more than targeting the default environment they've been given since the year dot.
The default environment is irrelevant. Best practices - from both Microsoft and any decent educational institution (not to mention simple common sense) - dictate that software shouldn't require privileges higher than the absolute minimum.
99% of applications that "require" Administrator access really don't. The developer has just been lazy or stupid and written bad software. There is no rational way anyone can blame Microsoft because a software developer decides to put application configuration data in the program's directory rather than the user's profile, or in a system-level registry key rather than a user-level one.
M$ started this mess and it's largely their responsibility to fix it. Protected OS' and the reasons for them were well understood long before M$Windows came along and the fact that recent versions of M$Windows implement but don't actually use that body of knowledge says a lot about their business ethics.
NT was multiuser back in 1993. That such a system it was the "future of Windows" was being said even before that. That's how long developers have had to write software that didn't needlessly require elevated privileges.
M$ should be pressuring and educating application vendors much harder to lift their game.
They've been "educating" developers for over a decade.
Even publishing a list of prominent applications and why they could run in user mode but don't would be a start. There's also all sorts of technical tricks they could do virtualising the environment of applications to make admin unnecessary, from popup warning messages up to and including multiple copies of \WINDOWS and the registry.
Which are the kind of ugly hacks Vista is doing. It still doesn't fix broken applications, though, nor even encourage (let alone coerce) developers to fix their bad habits.
The problem lies 100% with software developers. Microsoft can hack around their stupidity, but it will negatively impact performance, reliability and usability. All because software developers are too lazy or stupid to write their software properly.
Not exclusively M$' fault though, there's plenty of blame to go around.
It's not at all Microsoft's fault. In no way have they recommended, required or even suggested software developers wrte applications that require higher than necessary privileges.
One of the NT features 95 lacked was user isolation. That is, the concept of protecting one user's stuff from another user. This included any type of user/administrator distinction. All home applications were developed for 95, because nobody had NT on their home computers (which was due to NT's limited compatibility with DOS and Win16 programs). Thus, they never had to worry about anything security related. By the time NT overtook 9x, this practice was firmly established. In order to maintain compatibility with programs written on 9x, MS was forced to make administrator the default on NT.
It is important to note that the facilities - APIs and system infrastructure - existed for user separation in Windows 9x, from about 1996, even though the system had no way of enforcing it.
Or, in other words, Windows 9x was not a hinderance for developers writing "multiuser-aware" software because it supported APIs and per-user registry/filesystem locations to allow the distinction between users. Not that even this is really an excuse, since it's only relevant to storing per-user data, which is a relatively minor part of most pieces of software.
Your false statement is wrong. Ever heard of a shatter attack?
Yes. It, too, depends largely on poorly written applications to be successful.
This means that any process, run at any privlege level, can escalate itself to having administrator-level privleges. (Don't believe me? Google on "shatter attack" -- with quotes -- and read.)
Only if there is an appropriately vulnerable window with higher privileges that already exists on the same desktop.
And the point everyone else is trying to make is Micorsoft encouraged ID to make Doom 3 use administrator to run by making half of the API's that Doom 3 uses only accessible by administrator (like writing directly to hardware to increase performance).
Bullshit.
Doom 3 "needs" Administrator privileges because some dipshit at id thought it would be a good idea to store configuration data in the application's directory, rather than the user's profile where it belongs. Changing the permissions on a single.cfg file is all it takes to run Doom 3 under a non-Admin account, with no performance impact whatsoever.
99% of programs that "require" Administrator access "require" it because of stupidity like this - stupidity that is 100% the fault of the software developer.
No, but I would blame Mandriva if they released a version of OpenOffice.org that required me to run it as root.
And that would make sense.
But why do you blame Microsoft because id released a version of Doom 3 that (ostensibly, it's pretty easy to fix) requires Administrator privileges to run ? Because that's the point I'm trying to make.
If you consider "the system" to include applications -- and most end users do, then the system does depend on such permissions and fixing the problem is exceptionally difficult, if not impossible.
No rational definition of "the system", with regards to Microsoft's responsibilities, can include third party applications they have no control over.
When applications require higher than necessary permissions to run, generally meaning needing to use an Administrator level account, then it is wholely and solely the application developer's fault.
The permissions system is working exactly as it should and just as it does on other platforms. It is the applications that are broken.
Only if they sit at their computer using only Solitaire, Notepad, and Internet Explorer!
False, and this is where the difference is most apparent.
It's possible to run Windows day to day in a regular user account - I've been doing it since 1996. Some applications do have problems, but they're fixable either with some localised permissions tweaking, or as a last resort by running just that application as Administrator.
Contrast this to a system (like, say, Windows 95) where the permissions really are broken, and it is impossible to restrict access to critical system areas because the system-level tools themselves either can't handle it, or there is no facility for discretionary access control at all.
If Microsoft really cared about this issue, then why haven't they changed the default?!?!
Because there are too many pieces of broken software out there that wouldn't run. An OS that won't run common software titles out of the box is a sales and support train wreck. For Microsoft, customer requirements and expectations overrule everything, because that's the only way their product gets sold.
That the actual blame for this situation lies with the sofware developers is irrelevant, as it is Microsoft who is blamed by ignorant end users for everything. Even in a relatively technically aware community like Slashdot, they are constantly blamed for problems that are neither their responsibility, nor realistically within their control.
Heck, just look at the blasting they got because XP's SP2 lightly tightened up a few things and broke a handful of machines and applications. Imagine what would happen if they did something that broke a significant (10%+) percentage of software.
If the situation were truly comparable to Microsoft -- if there was one distribution of Linux that completely dominated the others, and it defaulted to root, then yes, I would blame that distribution!!
Why would you blame an OS vendor for software developer incompetence ? It is senseless and illogical (unless, of course, you're an all-rights-no-responsibilities-blame-shifting-loon y).
No, they're not. You are trying to conflate two distinctly different things.
Broken permissions would be if the system directories and files were writable/changeable by any user and the system itself depended on such permissions to function. For an end user, fixing such a problem would be exceptionally difficult, if not impossible.
Defaulting to Administrator, on the other hand, is trivial for an end user to address.
You cannot say "default user is admin == broken permissions". One is trivial to change, the other extremely difficult.
The fact that everyone does run as Administrator is Microsoft's fault.
It's at least as much (moreso, IMHO) the fault of software developers who insist on writing software assuming the user has unrestricted access to the entire system, despite a multiuser version of Windows having existed for over a decade and Microsoft telling people to write multiuser-aware code.
Would you blame Linus if someone wrote a Linux app that required root privileges to run ?
1. MS doesn't take security seriously. Has broken permissions.
False.
You may argue that they have poorly chosen defaults, giving users Administrator accounts (although in context I'd consider it justifiable), but the permissions themselves are not broken.
2. People point out Windows's flaws, dismissed as MS bashers.
Blaming Microsoft because Sony installed malicious code is bullshit. Unless you can think of some platform that can magically tell whether or not software is "good" or "bad".
3. Company uses MS's broken permissions to threaten security.
Which permissions are broken ? If running a non-Administrator account, the Sony rootkit fails to install. If running an Administrator account, it installs. That's exactly how the system *should* work.
4. People point out Windows's flaws, dismissed as MS bashers.
Blaming Microsoft because their system behaves as designed and identically to every other platform, is hypocritical, mindless, Microsoft bashing.
solution: never buy another Sony product for doing what they did, and never buy another MS product for enabling them to do it. most people aren't focusing any of the blame on MS, but imo they should since this is exactly the sort of thing people have warned MS's crap security and disrespect of the user would lead to.
Here on Slashdot, we can turn *anything* into Microsoft-bashing, even when it has nothing to do with them !
Slashdot Mirror
Aopen have one.
This "MiniPC" will also be quite a bit faster than the Mac Mini, even without taking OS X's sluggishness into account.
One must also consider that Windows has a vastly higher level of exposure than any of the other platforms. How well would the unixes have fared if they had the user demographics and marketshare of Windows ?
The second issue is with Linux sources, the bugs are being vetted out of the code at a much faster pace making it ulimately more secure.
People say this a lot, but it never seems to get supported with anything more than hand-waving.
Statitics lie when taken out of context.
Statistics never lie, the people interpreting them do.
note that these are all x86...
NT runs on multiple platforms. x86, x86_64 and Itanium, at the very least, must be considered (plus PPC for the Xbox360, but I wouldn't consider that relevant to this discussion).
In regards to numberpumping, it is generally a lot easier to find a vulnerability in a Linux/Unix/OSX program than a Windows program, for the simple reason that a greater proportion of L/U/O programs are open source. You have two angles to attack from, and if you find some problem in the code, you can most likely find other instances in the code where the exact same mistake is made.
On the other hand, you have to take into consideration the _vastly_ higher exposure level Windows has.
Now, assuming that Linux, Unix, and OSX collectively run on 5 architectures (QUITE modest),
Not really. x86, x86_64, P[PC], SPARC, Itanium. There aren't many other platforms out there that are likely to be relevant to these stats.
[...] that is 5 times the code for any architecture and hardware related problems to arise in, although I would be willing to bet that it doesn't actually increase numbers that much.
Somehow I don't think there are completely separate codebases for each platform. The vast majority of code in an OS isn't platform specific.
Including many of those who say they do...
It hasn't changed at all, like many other things, it's simply dependant on context.
When in the context of academia and theory, "Operating System" (basically) means the kernel.
In any other context, it means a bunch of software packaged together to make a computer more useful than a paperweight.
That's not even a remotely equitable comparison.
If you want to fairly compare "OS versus OS" pick a Linux distribution with a similar software bundle to Windows. But comparing a kernel to an entire OS bundle is so ridiculously one-sided (not to mention worthless for any sort of real-world conclusions) it's not even worth considering.
Because they have highly biased user demographics and relatively miniscule levels of exposure.
Windows neither requires nor encourages such a thing. Ignorant, incompetent and/or stupid software developers do.
I don't give my grandma root. Redmond does it by default.
"Redmond" isn't managing your grandma's computer, they're selling a piece of general purpose software.
If M$soft could figure out a way to separate privs, the Net would be a better place.
They did that over a decade ago.
Incidentally, the next time you're exercising your inner seven-year-old, the '$' is meant to replace the 's', not supplement it.
Their OS architecture, especially that God-awful anything-goes "read me write me 69 me" registry, is killing them.
Their OS architecture is superior in nearly every way to its contemporaries.
No, an exploitable process must have a window on the user's interactive desktop. That's how it works - by sending messages to windows.
Further, most admin-level processes are broken in this regard. When I say most, I mean most of the ones that are supplied directly by MS.
Examples ?
The vulnerability exposed by Shatter is precisely why Microsoft have always recommended never having processes with elevated privileges running on the users interactive desktop as a matter of course. IOW, Shatter largely depends on poorly written software to be dangerous.
Read this.
Linux distros tend to only be "diverse" in ways that are frustrating, rather than useful.
You are mistaken, or lying. I regularly plug in USB (and Firewire) devices as a non-Admin user and they work fine.
Shift+Right click an applet, Run As.
You are mistaken, or lying.
And I can give you one - Doom 3 (well, I've never actually used Doom 3 under Linux, but I'm willing to bet it doesn't need root to run).
Why does Doom 3 need an Administrator account to run in Windows ? Because it tries to write configuration data (that on Linux almost certainly goes into ~/.doom3/doom3.cfg or similar) in %PROGRAMFILES%\Doom3. All you have to do to run Doom 3 under Windows in a regular user account is change the permissions on a single .cfg textfile (actually, it will run by default, even as a regular user, but it won't save any settings you change in the game, so functionality is reduced).
How is it at all Microsoft's fault that Doom 3 has been written this way ? Microsoft's own best practices say not to do it. Any semi-decent (and probably even the bad ones) software development course will also recommend against it. Per-user profiles and registry keys have existed in Windows NT since 3.1 in 1993 and Windows 9x since 95 OSR2 in 1996 (not that it's relevant, since Doom 3 is only supported on Windows NT derivatives). COMMON SENSE dictates it's a dumb idea. Yet still someone at id used the program's directory rather than %USERPROFILE%\Doom3 to store per-user configuration data.
99% of applications that "require" Administrator access to run suffer from this sort of stupidity. Needlessly trying to open files read-write (rather than read-only) in system and application directories. Storing configuration data in the application directory, system directory or system-wide registry keys instead of per-user locations that have existed on every version of Windows sold for nearly a decade.
Why is any of that Microsoft's fault ?
Surely Windows has always discouraged programmers from requiring administrator access, since the dangers of it have been known in the UNIX world for decades... right?
Correct. And the facilities for writing multiuser-friendly applications have been around since ~1996 even in DOS-based Windows (although obviously it had no way of enforcing user separation) to help developers write applications that could work on both platforms.
First of all, I never said Microsoft was completely to blame, and second, I don't give a shit about Microsoft's "political position" or what's most cost-effective for them; they caused the problem so they should fix it regardless!
I suppose you think women "cause" the problem of getting raped, as well, by wandering around in anything short of a burlap sack.
Obviously it's not Linux's fault, because Linux doesn't encourage such shitty programming. Microsoft, on the other hand, did at one time. That's what makes it Microsoft's fault!
When did Microsoft encourage "such shitty programming" ? Please provide evidence for your answer.
Why ? Why is developer incompetence/ignorance/laziness Microsoft's fault ?
The application developer is doing nothing more than targeting the default environment they've been given since the year dot.
The default environment is irrelevant. Best practices - from both Microsoft and any decent educational institution (not to mention simple common sense) - dictate that software shouldn't require privileges higher than the absolute minimum.
99% of applications that "require" Administrator access really don't. The developer has just been lazy or stupid and written bad software. There is no rational way anyone can blame Microsoft because a software developer decides to put application configuration data in the program's directory rather than the user's profile, or in a system-level registry key rather than a user-level one.
M$ started this mess and it's largely their responsibility to fix it. Protected OS' and the reasons for them were well understood long before M$Windows came along and the fact that recent versions of M$Windows implement but don't actually use that body of knowledge says a lot about their business ethics.
NT was multiuser back in 1993. That such a system it was the "future of Windows" was being said even before that. That's how long developers have had to write software that didn't needlessly require elevated privileges.
M$ should be pressuring and educating application vendors much harder to lift their game.
They've been "educating" developers for over a decade.
Even publishing a list of prominent applications and why they could run in user mode but don't would be a start. There's also all sorts of technical tricks they could do virtualising the environment of applications to make admin unnecessary, from popup warning messages up to and including multiple copies of \WINDOWS and the registry.
Which are the kind of ugly hacks Vista is doing. It still doesn't fix broken applications, though, nor even encourage (let alone coerce) developers to fix their bad habits.
The problem lies 100% with software developers. Microsoft can hack around their stupidity, but it will negatively impact performance, reliability and usability. All because software developers are too lazy or stupid to write their software properly.
Not exclusively M$' fault though, there's plenty of blame to go around.
It's not at all Microsoft's fault. In no way have they recommended, required or even suggested software developers wrte applications that require higher than necessary privileges.
It is important to note that the facilities - APIs and system infrastructure - existed for user separation in Windows 9x, from about 1996, even though the system had no way of enforcing it.
Or, in other words, Windows 9x was not a hinderance for developers writing "multiuser-aware" software because it supported APIs and per-user registry/filesystem locations to allow the distinction between users. Not that even this is really an excuse, since it's only relevant to storing per-user data, which is a relatively minor part of most pieces of software.
Yes. It, too, depends largely on poorly written applications to be successful.
This means that any process, run at any privlege level, can escalate itself to having administrator-level privleges. (Don't believe me? Google on "shatter attack" -- with quotes -- and read.)
Only if there is an appropriately vulnerable window with higher privileges that already exists on the same desktop.
How is it at *all* Microsoft's fault because software developers write their software badly ?
Bullshit.
Doom 3 "needs" Administrator privileges because some dipshit at id thought it would be a good idea to store configuration data in the application's directory, rather than the user's profile where it belongs. Changing the permissions on a single .cfg file is all it takes to run Doom 3 under a non-Admin account, with no performance impact whatsoever.
99% of programs that "require" Administrator access "require" it because of stupidity like this - stupidity that is 100% the fault of the software developer.
And that would make sense.
But why do you blame Microsoft because id released a version of Doom 3 that (ostensibly, it's pretty easy to fix) requires Administrator privileges to run ? Because that's the point I'm trying to make.
No rational definition of "the system", with regards to Microsoft's responsibilities, can include third party applications they have no control over.
When applications require higher than necessary permissions to run, generally meaning needing to use an Administrator level account, then it is wholely and solely the application developer's fault.
The permissions system is working exactly as it should and just as it does on other platforms. It is the applications that are broken.
Only if they sit at their computer using only Solitaire, Notepad, and Internet Explorer!
False, and this is where the difference is most apparent.
It's possible to run Windows day to day in a regular user account - I've been doing it since 1996. Some applications do have problems, but they're fixable either with some localised permissions tweaking, or as a last resort by running just that application as Administrator.
Contrast this to a system (like, say, Windows 95) where the permissions really are broken, and it is impossible to restrict access to critical system areas because the system-level tools themselves either can't handle it, or there is no facility for discretionary access control at all.
If Microsoft really cared about this issue, then why haven't they changed the default?!?!
Because there are too many pieces of broken software out there that wouldn't run. An OS that won't run common software titles out of the box is a sales and support train wreck. For Microsoft, customer requirements and expectations overrule everything, because that's the only way their product gets sold.
That the actual blame for this situation lies with the sofware developers is irrelevant, as it is Microsoft who is blamed by ignorant end users for everything. Even in a relatively technically aware community like Slashdot, they are constantly blamed for problems that are neither their responsibility, nor realistically within their control.
Heck, just look at the blasting they got because XP's SP2 lightly tightened up a few things and broke a handful of machines and applications. Imagine what would happen if they did something that broke a significant (10%+) percentage of software.
If the situation were truly comparable to Microsoft -- if there was one distribution of Linux that completely dominated the others, and it defaulted to root, then yes, I would blame that distribution!!
Why would you blame an OS vendor for software developer incompetence ? It is senseless and illogical (unless, of course, you're an all-rights-no-responsibilities-blame-shifting-loon y).
No, they're not. You are trying to conflate two distinctly different things.
Broken permissions would be if the system directories and files were writable/changeable by any user and the system itself depended on such permissions to function. For an end user, fixing such a problem would be exceptionally difficult, if not impossible.
Defaulting to Administrator, on the other hand, is trivial for an end user to address.
You cannot say "default user is admin == broken permissions". One is trivial to change, the other extremely difficult.
The fact that everyone does run as Administrator is Microsoft's fault.
It's at least as much (moreso, IMHO) the fault of software developers who insist on writing software assuming the user has unrestricted access to the entire system, despite a multiuser version of Windows having existed for over a decade and Microsoft telling people to write multiuser-aware code.
Would you blame Linus if someone wrote a Linux app that required root privileges to run ?
False.
You may argue that they have poorly chosen defaults, giving users Administrator accounts (although in context I'd consider it justifiable), but the permissions themselves are not broken.
2. People point out Windows's flaws, dismissed as MS bashers.
Blaming Microsoft because Sony installed malicious code is bullshit. Unless you can think of some platform that can magically tell whether or not software is "good" or "bad".
3. Company uses MS's broken permissions to threaten security.
Which permissions are broken ? If running a non-Administrator account, the Sony rootkit fails to install. If running an Administrator account, it installs. That's exactly how the system *should* work.
4. People point out Windows's flaws, dismissed as MS bashers.
Blaming Microsoft because their system behaves as designed and identically to every other platform, is hypocritical, mindless, Microsoft bashing.
Here on Slashdot, we can turn *anything* into Microsoft-bashing, even when it has nothing to do with them !
By that logic, Firefox and Flash Viewer are one and the same.