Comment Re:How Kind of You (Score 1) 151
>>When a Windows user receives a zip file containing a file
>>named hello.txt.exe", the default explorer settings makes
>>it appear as "hello.txt", because of the "mask extension
>>of known file type 'feature'".
>This is a UI semantic, nothing more.
Right, but this is dangerous (this allows to lure users) and this doesn't bring anything to the user. After all the trouble it caused, why hasn't MS simply made the default to show the complete filename ?
>>Then instead of launching a command like "notepad.exe hello.txt"
>>or opening a text editor and opening the file from within, when
>>you double-click on a file in Windows, it gets EXECUTED.
>Of course it gets executed - it's an executable file. Why
>wouldn't it ?
Because an application like a mail reader shouldn't expect to
receive executable code from an e-mail. So the file shouldn't
be executable. Again, a minor tweak that could save people a lot
of problems. Why on hell should a data file (a file generated with
a "Save As..." dialog) be executable ? It would be a minor tweak in
default Windows permissions, not to put the "Execute" flag.
Like on Unix: saving a file puts the permissions to "-rw-------", not to "-rwx------".
>Not that you can directly open executable attachments on any
>remotely recent version of Outlook or Outlook Express in the
>first place, making your whole argument moot.
Ok, so some minor progress from MS...
>(The real irony here is that GUIs like KDE and GNOME are,
>if anything, *more* vulnerable to this style of attack
>because they don't make any attempt to verify whether a
>file's extension matches its type. So a file called blah.txt,
>if it's really an executable binary, will be run as an executable
>binary regardless - rename a .exe to .txt in Windows and Explorer
>will just open the file in notepad.)
No, sorry this is wrong. The mechanism is to associate a file extension with a program to view it. mpg files are associated with xine or mplayer typically. If you feed mplayer with an executable, it would say something like unknown file format, no codec found for this file, etc... txt files are associated with KEdit, typically. When there is no extension, the file isen't associated with anything and the user can eventually choose a program to open with. But the file is never run.
Doing a command like:
$ mplayer malicious.mpg
is very different than:
$ chmod u+x malicious.mpg
$ ./malicious.mpg
The former requires only a mouse click and can happen by accident, but is harmless.
The latter not.
>>Ok, but in that case, the use would only be able to destroy
>>its own files, which he's allowed to do anyways...
>The user's files are typically the most important on the machine.
I agree for a home PC. (mono-user) Else there are other's users files that are more important.
>>Without Admin access, there is no spyware installation, no
>>dirty tools added at the startup and the like. This makes
>>a huge difference.
>Of course there is. The malware gets hidden away somewhere in
>~ and the user's dotfiles and GUI are modified to relaunch it
>whenever they login (KDE, GNOME, etc - most have some sort of
>"launch on login" functionality).
Right... There could be an attack vector here. But this assumes that the user has already executed a rogue executable.
>>In the linux a stupid user would destroy its own data, in the
>>Windows case, he has destroyed the whole OS and potentially
>>infects other machines around...
>"Destroying the OS" barely qualifies as a minor irritation
>compared to losing all your data files
Well, we're talking here about people needing to reinstall Windows every 6 months due to spyware and the like...
>- and root access is
>in no way a requirement to "infect other machines around".
Right.
>>Again there is a big difference here. On Windows such flaws remain
>>for years and MS only correct them when there are hundreds of
>>thousands of machines infected.
>With Windows, a flaw only needs to exist for a few hours and
>hundreds of thousands of machines are infected. That's why the
>marketshare aspect is so significant.
Sorry, this does not really work like this.
A software developer first badly codes something.
After a delay between hours and years, it's discovered by someone and eventually other people.
In the open source world, it's then corrected.
In the Windows world, noone cares to correct this. (In fact, people are typically not even allowed to correct it)
Days, weeks or months later, spammers, virus writers, bot owners use the flaw to conduct their attacks.
When MS sees that the attack is successful, it develops a patch.
Also the probability of a flaw to result in a successful attack is quite low. To spare money, MS only corrects flaws for which an attack actually occurs. The 90+ % of flaws that are not exploitable or hard to exploit are typically never corrected.
>>Which is perfectly sensible from the security point of view.
>But not from a functionality point of view, if such macros are
>what you need. ...
You've got a point here... But I hope you'll note that there are other ways on Unix to automate things using shell, Perl, etc...
This offers the security advantage that code is not linked with a datafile.
>>This is also an OS issue. Per default, on Windows, users are
>>running with admin privileges. One small problem in an
>>application and the whole system is compromised.
>No, a vulnerability in an application is solely an application
>issue.
I don't deny the application issue. I say that there are ways to
contain the problem. Running as an admin allows the issue to damage the whole system, all user files.
In some way, it can even create problems for other machine. \\othermachine\C$ is typically only accessible as an admin.
>>Or would you argue that a vulnerability in a daemon running as
>>root is a Linux problem ?
I would say this depends which deamon. Some deamons are linked to the kernel, some like Apache not... (But this would be unwise to run Apache as root anyways)
>>Which is wrong. In the 80s and beginning of the 90s, there were
>>numerous viruses for Amiga, Atari and Macintosh (the old
>>generation before Mac OS X) Amiga and Atari were much more
>>marginal than Linux.
>I find it hard to take anyone seriously who thinks MacOS, Amiga
>and Atari (ST, I assume you mean) were "much more marginal than
>Linux".
This depends much of where you're living. At least for the Amiga, it was mostly successful in Canada, Germany and post-soviet countries.
Even when the Amiga was sharply declining, viruses were developped.
>You do realise that back in the day, Macs, Amigas and Ataris were
>the most common type of PC other than an IBM PC or C64, right ?
Right, this depends in which countries... In my country, I've always seen MS-DOS and Windows being largely dominant.
>Linux wouldn't even come *close* to the proportional share those
>three computers had in the desktop computer market in their heyday.
Linux is widely deployed on servers. Lots of these servers are connected to the internet, which was not the case of Amigas, Ataris and C64s.
Maybe Linux does not reach the market share of Amiga at that time, but Linux faces much tougher threats today. Being on 24/7 directly connected requires much more security than a isolated desktop system on which some floppies are traded from time to time...
>Heck, Linux on the desktop wouldn't even beat out Macs _today_,
>and Apple's marketshare is but a pale shadow of its former glory.
Well, this is difficult to say... There is typically no official market share figure for Linux. But I can tell that lots of people test, install it as a secondary OS. I have heard no report of hack.
>That and your religious repetition of the standard Linux zealot
>... etc absolutely *scream* that you have no real-life experience
>or knowledge in the area.
I'm still waiting for the first linux virus. With millions of machines connected 24/7, I think that its security is well tested and understood.
>...but without a suitable user demographic and sufficient
>marketshare (ie: victims), no virus is going to propagate far
>before being squashed.
Millions of machines are sufficient to launch a big attack...
And you also forgot the fact that the size of the market is much larger now that it was in the 80s and 90s...
>The default user for a Windows PC in a domain (ie: "companies")
>is not an Administrator.
Well maybe. Unfortunately, so much applications require to write in Program Files and in the registry... Even the latest DivX player from www.divx.com requires write access to Program Files, else it crashes.
>The mere suggestion that everyone who types their password into the
>automated, graphical sudo prompt that OS X and various Linux
>distros conveniently pop up when necessary, understands that they
>are running something as root (and the implications thereof) is
>ridiculous.
Ok, so eventually I could imagine the following situation for really really stupid linux users. They would surf in the web and a Java application would ask the user to enter the root password to continue. Then the Java applet could install a spyware on this machine...
But the probability of finding a user so stupid is very low, even when dealing with the most debutant Windows users.
>If you seriously believe that unix machines have never, ever been
>remotely compromised, you need to do a *lot* of reading.
I don't believe that Unix was rock solid in the 70s. It's now and Windows is not.
>The NT security model, OTOH, was designed in from day one and is
>vastly more competent and capable than traditional. By any
>rational, objective measure, NT has nothing to learn from unix
>about security.
Well, I do not agree... Windows XP is probably the most hacked system today although it's based on NT.
>Software bugs aside, the security "problems" with Windows are
>almost entirely due to users being ignorant, not due to any
>technical limitations.
And totally insecure defaults, and badly written apps that require admin access to run, and a GUI that often encourage users to do stupid things, and huge security holes in IE, MSN, and the fact that MS waits that an actual attack has been successful to correct bugs, and the fact that being closed source thousands of bugs are still to be discovered... This makes to much for me. I'm on Linux and will not go to Windows.
>[autorun] is simply a matter of shell functionality. in Windows,
>Explorer will "autorun" whatever the "autorun.inf" file on a piece
>of removable media tells it to (this _is_ arguably a bad idea, but
>it was originally conceived in happier days).
There is no excuse for this. It was implemented perhaps 10 years with the L/Disk-Validator (Saddam Hussein virus and the like) and was proved to be disastrous on the Amiga. Then Commodore changed this.
>KDE does a similar thing, as does OS X (which has been bitten by
>it before). There is no technical limitation whatsoever obstructing
>the complete equivalent of the old Windows autorun functionality
>on a unix machine.
Wrong, there is no autorun in KDE. When you insert a CD, a dialog eventually pops up like: Do you want to:
1) mplayer, Xine, etc... (on the contents of the CD) ?
2) Grip (contents of the audio CD) ?
3) play audio files of the CD ?
4) Browse cd files with Konqueror ?
There is no such things as EXECUTING CODE FROM THE CD when it's inserted into the drive.
>>So there could be malware on Mac OS X if many users are running
>>with admin privileges...
>Most OS X users run as "admin". It's the default user type.
Ok, so I could imagine spyware on Mac OS X.
>>This is a huge point. If a user executes malicious code, on Unix
>>the only danger is for the the user's file. rm -rf ~/* would do
>>the same.
>Ie: the most important files on the computer.
Maybe well. An admin hack can not only damage the OS, but also the users' files and even other users' files...
With admin rights, there is more at risk.
>>On Windows, this leads to the possibility of installing a
>>spyware, a rootkit and the like. Simply by overwriting
>>drivers, dll or executables. Or by planting malicious *.bat
>>files that could be executed by an administrator instead of
>>legitimate executable, depending of the current directory,
>>path, etc...
>System files on Windows are not writable by regular users.
>Your assumption is broken.
Windows users often are admin on their machines. In other cases, whole directories in Program Files are made writeable to allow programs to work...
>Not today, no. Back before you knew about computers, however, those
>three types of machines probably covered ca. 50% of non-business
>PCs.
And there were still a lot more viruses for MS-DOS and Windows 3 than for the other systems...
>>A Linux machine connected to the Web get hundreds of rogue ssh
>>connections attempts per day...
>This is only vaguely related to viruses and other malware and
>utterly irrelevant to my point.
This could be an attack vector if ssh has a hole. Once a hole is punched in a system, it's possible to install malicious things.
>It wouldn't be at all difficult to write a virus for Linux. Heck,
>I'm only an average programmer and I could whip one up in perl
>over a weekend.
Well then try it... Really, this could lead to the discovery of a security hole. But I simply think you will never be able to make it propagate. Why ? The typical only entry point in a Linux system is it's sshd server. Without being able to use a hole of ssh, your virus will go nowhere and will only damage your own machine.
>Both "reading mail" and "surfing the web" require user interaction
>to be vectors.
You would then argue that Windows is secure as long as we don't use it... I don't know about but I like to use an OS that I install.
>>One of the big differences is the OS... Windows 2003 is not more
>>secure because it's installed on a "server" rather than on a
>>desktop PC.
>No. It is, however, vastly less compromised largely because a) it
>is on a "server" rather than a desktop PC and b) it isn't anywhere
>near as common.
Ok, so you think that installing Windows in a rack mounted PC is more secure than doing the same install on a desktop PC :-)
Then you point that the "market share" of servers is less important than desktop. I claim this doesn't matter since this is the same code running.
>If you're trying to make claims about how "secure" an OS is based
>on how often it's exploited, rather than quantifiable security
>features (or lack thereof) then your comparison is broken from
>the get-go.
More "features" means more code, more risks of exploits, less understood model so more difficult to properly setup.
An example: Firefox doesn't support Active-X so it will never be a victim of an Active-X exploit. Adding a "security feature" on IE to only allow Active-X on "trusted sites" is still less secure than not having Active-X at all...
Rather than having "security features" applied to insecure things, it's better not to have the insecure thing at all. I want real security, not only the appearance, the illusion of security.
>If you want to do it while not considering marketshare and user
>demographics as intrinsic factors, then it is laughably broken.
I don't think so. Millions of machines is largely enough to launch a massive attack. When there are millions of machines, there are always tens of thousands of totally incompetent users.
>Viruses and malware are *extremely* reliant on the end user's level
>of knowledge to be effective (which is why it's quite easy to run
>Windows without being compromised).
I don't think so. I wanted one time to test the Kazaa software. I did it inside a virtual machine loaded with XP. I followed the normal installation procedure and once it was finished, even before Kazaa was started, there was huge surge of network traffic. Then tens of popups appeared. My system was completely hijacked. Dozens of suspicious file were copied to my harddisk. Only solution: completely delete the virtual machine.
>>But here we're talking about tens of thousands of malwares on
>>Windows and zero on Linux, so this can not be explained by
>>market share problems.
>You are conveniently ignoring that those "tens of thousands of
>viruses" are really just hundreds and hundreds of variations of
>dozens of different viruses.
Which means that MS didn't even bother securing its system (at the beginning).
>>named hello.txt.exe", the default explorer settings makes
>>it appear as "hello.txt", because of the "mask extension
>>of known file type 'feature'".
>This is a UI semantic, nothing more.
Right, but this is dangerous (this allows to lure users) and this doesn't bring anything to the user. After all the trouble it caused, why hasn't MS simply made the default to show the complete filename ?
>>Then instead of launching a command like "notepad.exe hello.txt"
>>or opening a text editor and opening the file from within, when
>>you double-click on a file in Windows, it gets EXECUTED.
>Of course it gets executed - it's an executable file. Why
>wouldn't it ?
Because an application like a mail reader shouldn't expect to
receive executable code from an e-mail. So the file shouldn't
be executable. Again, a minor tweak that could save people a lot
of problems. Why on hell should a data file (a file generated with
a "Save As..." dialog) be executable ? It would be a minor tweak in
default Windows permissions, not to put the "Execute" flag.
Like on Unix: saving a file puts the permissions to "-rw-------", not to "-rwx------".
>Not that you can directly open executable attachments on any
>remotely recent version of Outlook or Outlook Express in the
>first place, making your whole argument moot.
Ok, so some minor progress from MS...
>(The real irony here is that GUIs like KDE and GNOME are,
>if anything, *more* vulnerable to this style of attack
>because they don't make any attempt to verify whether a
>file's extension matches its type. So a file called blah.txt,
>if it's really an executable binary, will be run as an executable
>binary regardless - rename a
>will just open the file in notepad.)
No, sorry this is wrong. The mechanism is to associate a file extension with a program to view it. mpg files are associated with xine or mplayer typically. If you feed mplayer with an executable, it would say something like unknown file format, no codec found for this file, etc... txt files are associated with KEdit, typically. When there is no extension, the file isen't associated with anything and the user can eventually choose a program to open with. But the file is never run.
Doing a command like:
$ mplayer malicious.mpg
is very different than:
$ chmod u+x malicious.mpg
$
The former requires only a mouse click and can happen by accident, but is harmless.
The latter not.
>>Ok, but in that case, the use would only be able to destroy
>>its own files, which he's allowed to do anyways...
>The user's files are typically the most important on the machine.
I agree for a home PC. (mono-user) Else there are other's users files that are more important.
>>Without Admin access, there is no spyware installation, no
>>dirty tools added at the startup and the like. This makes
>>a huge difference.
>Of course there is. The malware gets hidden away somewhere in
>~ and the user's dotfiles and GUI are modified to relaunch it
>whenever they login (KDE, GNOME, etc - most have some sort of
>"launch on login" functionality).
Right... There could be an attack vector here. But this assumes that the user has already executed a rogue executable.
>>In the linux a stupid user would destroy its own data, in the
>>Windows case, he has destroyed the whole OS and potentially
>>infects other machines around...
>"Destroying the OS" barely qualifies as a minor irritation
>compared to losing all your data files
Well, we're talking here about people needing to reinstall Windows every 6 months due to spyware and the like...
>- and root access is
>in no way a requirement to "infect other machines around".
Right.
>>Again there is a big difference here. On Windows such flaws remain
>>for years and MS only correct them when there are hundreds of
>>thousands of machines infected.
>With Windows, a flaw only needs to exist for a few hours and
>hundreds of thousands of machines are infected. That's why the
>marketshare aspect is so significant.
Sorry, this does not really work like this.
A software developer first badly codes something.
After a delay between hours and years, it's discovered by someone and eventually other people.
In the open source world, it's then corrected.
In the Windows world, noone cares to correct this. (In fact, people are typically not even allowed to correct it)
Days, weeks or months later, spammers, virus writers, bot owners use the flaw to conduct their attacks.
When MS sees that the attack is successful, it develops a patch.
Also the probability of a flaw to result in a successful attack is quite low. To spare money, MS only corrects flaws for which an attack actually occurs. The 90+ % of flaws that are not exploitable or hard to exploit are typically never corrected.
>>Which is perfectly sensible from the security point of view.
>But not from a functionality point of view, if such macros are
>what you need.
You've got a point here... But I hope you'll note that there are other ways on Unix to automate things using shell, Perl, etc...
This offers the security advantage that code is not linked with a datafile.
>>This is also an OS issue. Per default, on Windows, users are
>>running with admin privileges. One small problem in an
>>application and the whole system is compromised.
>No, a vulnerability in an application is solely an application
>issue.
I don't deny the application issue. I say that there are ways to
contain the problem. Running as an admin allows the issue to damage the whole system, all user files.
In some way, it can even create problems for other machine. \\othermachine\C$ is typically only accessible as an admin.
>>Or would you argue that a vulnerability in a daemon running as
>>root is a Linux problem ?
I would say this depends which deamon. Some deamons are linked to the kernel, some like Apache not... (But this would be unwise to run Apache as root anyways)
>>Which is wrong. In the 80s and beginning of the 90s, there were
>>numerous viruses for Amiga, Atari and Macintosh (the old
>>generation before Mac OS X) Amiga and Atari were much more
>>marginal than Linux.
>I find it hard to take anyone seriously who thinks MacOS, Amiga
>and Atari (ST, I assume you mean) were "much more marginal than
>Linux".
This depends much of where you're living. At least for the Amiga, it was mostly successful in Canada, Germany and post-soviet countries.
Even when the Amiga was sharply declining, viruses were developped.
>You do realise that back in the day, Macs, Amigas and Ataris were
>the most common type of PC other than an IBM PC or C64, right ?
Right, this depends in which countries... In my country, I've always seen MS-DOS and Windows being largely dominant.
>Linux wouldn't even come *close* to the proportional share those
>three computers had in the desktop computer market in their heyday.
Linux is widely deployed on servers. Lots of these servers are connected to the internet, which was not the case of Amigas, Ataris and C64s.
Maybe Linux does not reach the market share of Amiga at that time, but Linux faces much tougher threats today. Being on 24/7 directly connected requires much more security than a isolated desktop system on which some floppies are traded from time to time...
>Heck, Linux on the desktop wouldn't even beat out Macs _today_,
>and Apple's marketshare is but a pale shadow of its former glory.
Well, this is difficult to say... There is typically no official market share figure for Linux. But I can tell that lots of people test, install it as a secondary OS. I have heard no report of hack.
>That and your religious repetition of the standard Linux zealot
>... etc absolutely *scream* that you have no real-life experience
>or knowledge in the area.
I'm still waiting for the first linux virus. With millions of machines connected 24/7, I think that its security is well tested and understood.
>...but without a suitable user demographic and sufficient
>marketshare (ie: victims), no virus is going to propagate far
>before being squashed.
Millions of machines are sufficient to launch a big attack...
And you also forgot the fact that the size of the market is much larger now that it was in the 80s and 90s...
>The default user for a Windows PC in a domain (ie: "companies")
>is not an Administrator.
Well maybe. Unfortunately, so much applications require to write in Program Files and in the registry... Even the latest DivX player from www.divx.com requires write access to Program Files, else it crashes.
>The mere suggestion that everyone who types their password into the
>automated, graphical sudo prompt that OS X and various Linux
>distros conveniently pop up when necessary, understands that they
>are running something as root (and the implications thereof) is
>ridiculous.
Ok, so eventually I could imagine the following situation for really really stupid linux users. They would surf in the web and a Java application would ask the user to enter the root password to continue. Then the Java applet could install a spyware on this machine...
But the probability of finding a user so stupid is very low, even when dealing with the most debutant Windows users.
>If you seriously believe that unix machines have never, ever been
>remotely compromised, you need to do a *lot* of reading.
I don't believe that Unix was rock solid in the 70s. It's now and Windows is not.
>The NT security model, OTOH, was designed in from day one and is
>vastly more competent and capable than traditional. By any
>rational, objective measure, NT has nothing to learn from unix
>about security.
Well, I do not agree... Windows XP is probably the most hacked system today although it's based on NT.
>Software bugs aside, the security "problems" with Windows are
>almost entirely due to users being ignorant, not due to any
>technical limitations.
And totally insecure defaults, and badly written apps that require admin access to run, and a GUI that often encourage users to do stupid things, and huge security holes in IE, MSN, and the fact that MS waits that an actual attack has been successful to correct bugs, and the fact that being closed source thousands of bugs are still to be discovered... This makes to much for me. I'm on Linux and will not go to Windows.
>[autorun] is simply a matter of shell functionality. in Windows,
>Explorer will "autorun" whatever the "autorun.inf" file on a piece
>of removable media tells it to (this _is_ arguably a bad idea, but
>it was originally conceived in happier days).
There is no excuse for this. It was implemented perhaps 10 years with the L/Disk-Validator (Saddam Hussein virus and the like) and was proved to be disastrous on the Amiga. Then Commodore changed this.
>KDE does a similar thing, as does OS X (which has been bitten by
>it before). There is no technical limitation whatsoever obstructing
>the complete equivalent of the old Windows autorun functionality
>on a unix machine.
Wrong, there is no autorun in KDE. When you insert a CD, a dialog eventually pops up like: Do you want to:
1) mplayer, Xine, etc... (on the contents of the CD) ?
2) Grip (contents of the audio CD) ?
3) play audio files of the CD ?
4) Browse cd files with Konqueror ?
There is no such things as EXECUTING CODE FROM THE CD when it's inserted into the drive.
>>So there could be malware on Mac OS X if many users are running
>>with admin privileges...
>Most OS X users run as "admin". It's the default user type.
Ok, so I could imagine spyware on Mac OS X.
>>This is a huge point. If a user executes malicious code, on Unix
>>the only danger is for the the user's file. rm -rf ~/* would do
>>the same.
>Ie: the most important files on the computer.
Maybe well. An admin hack can not only damage the OS, but also the users' files and even other users' files...
With admin rights, there is more at risk.
>>On Windows, this leads to the possibility of installing a
>>spyware, a rootkit and the like. Simply by overwriting
>>drivers, dll or executables. Or by planting malicious *.bat
>>files that could be executed by an administrator instead of
>>legitimate executable, depending of the current directory,
>>path, etc...
>System files on Windows are not writable by regular users.
>Your assumption is broken.
Windows users often are admin on their machines. In other cases, whole directories in Program Files are made writeable to allow programs to work...
>Not today, no. Back before you knew about computers, however, those
>three types of machines probably covered ca. 50% of non-business
>PCs.
And there were still a lot more viruses for MS-DOS and Windows 3 than for the other systems...
>>A Linux machine connected to the Web get hundreds of rogue ssh
>>connections attempts per day...
>This is only vaguely related to viruses and other malware and
>utterly irrelevant to my point.
This could be an attack vector if ssh has a hole. Once a hole is punched in a system, it's possible to install malicious things.
>It wouldn't be at all difficult to write a virus for Linux. Heck,
>I'm only an average programmer and I could whip one up in perl
>over a weekend.
Well then try it... Really, this could lead to the discovery of a security hole. But I simply think you will never be able to make it propagate. Why ? The typical only entry point in a Linux system is it's sshd server. Without being able to use a hole of ssh, your virus will go nowhere and will only damage your own machine.
>Both "reading mail" and "surfing the web" require user interaction
>to be vectors.
You would then argue that Windows is secure as long as we don't use it... I don't know about but I like to use an OS that I install.
>>One of the big differences is the OS... Windows 2003 is not more
>>secure because it's installed on a "server" rather than on a
>>desktop PC.
>No. It is, however, vastly less compromised largely because a) it
>is on a "server" rather than a desktop PC and b) it isn't anywhere
>near as common.
Ok, so you think that installing Windows in a rack mounted PC is more secure than doing the same install on a desktop PC
Then you point that the "market share" of servers is less important than desktop. I claim this doesn't matter since this is the same code running.
>If you're trying to make claims about how "secure" an OS is based
>on how often it's exploited, rather than quantifiable security
>features (or lack thereof) then your comparison is broken from
>the get-go.
More "features" means more code, more risks of exploits, less understood model so more difficult to properly setup.
An example: Firefox doesn't support Active-X so it will never be a victim of an Active-X exploit. Adding a "security feature" on IE to only allow Active-X on "trusted sites" is still less secure than not having Active-X at all...
Rather than having "security features" applied to insecure things, it's better not to have the insecure thing at all. I want real security, not only the appearance, the illusion of security.
>If you want to do it while not considering marketshare and user
>demographics as intrinsic factors, then it is laughably broken.
I don't think so. Millions of machines is largely enough to launch a massive attack. When there are millions of machines, there are always tens of thousands of totally incompetent users.
>Viruses and malware are *extremely* reliant on the end user's level
>of knowledge to be effective (which is why it's quite easy to run
>Windows without being compromised).
I don't think so. I wanted one time to test the Kazaa software. I did it inside a virtual machine loaded with XP. I followed the normal installation procedure and once it was finished, even before Kazaa was started, there was huge surge of network traffic. Then tens of popups appeared. My system was completely hijacked. Dozens of suspicious file were copied to my harddisk. Only solution: completely delete the virtual machine.
>>But here we're talking about tens of thousands of malwares on
>>Windows and zero on Linux, so this can not be explained by
>>market share problems.
>You are conveniently ignoring that those "tens of thousands of
>viruses" are really just hundreds and hundreds of variations of
>dozens of different viruses.
Which means that MS didn't even bother securing its system (at the beginning).
