Ah, yes, the standard "look how quick I can do it on Linux vs Windows" comparison, where not only is the quickest method on Linux chosen, compared to the slowest method on Windows but, additionally, steps which are given as single and generic on one are broken down into specific sub-steps on the other.
Heck, why aren't you counting individual keypresses as steps on Windows ? It'd be only marginally less subtle than the bullshit you posted.
This isn't necessarily the fault of Windows... although Microsoft is one of the prime offenders with IE and MSOffice and so forth.
Both IE and Office work fine as a non-Administrator.
Windows applications that don't run as regular users, in this day and age, are 100% the fault of the software developers. They have no excuse for badly written software that needlessly requires Administrator privileges.
Plus, given the author's scenario - let's flip it around: A Windows virus can bork your data and your OS. At least with UNIX, backups notwithstanding, the OS is still there and you'd have a much better chance at recovering your data than you would with Windows.
If you follow the same procedures on both OSes, both will protect from being "borked" equally.
You seem to be missing the point. Just because the default _is_ an Administrator, is not justification for developers ignoring Microsoft's recommendations, universal best principals, and just sheer common sense by writing applications that _needlessly_ require Administrator privileges.
An application that "needs" Administrator access because it's badly written, is solely the responsibility - and fault - of the application developer.
I've written an informative summary of the ascendance of MS on my blog.
Considering the bias and errors, it's hardly "informative".
I assume that by:
Digital Research's product, DRDOS had features that were clearly superior to the competitors. Most notably, DRDOS 6.0 was not bound by 640k ram limit that hobbled MSDOS.
You're talking about the ability to load parts of the DOS kernel, along with drivers into the Upper Memory Area. This actually happened with DR-DOS 5, in 1990. MS-DOS followed afterwards in mid-1991 (and the delay - coupled with the disaster that was DOS 4.0, cost them badly).
Following on, your comments about Windows 3.1 completely ignores that a) the non-MSDOS detection in Windows 3.x (note: not a specific test for DR-DOS, but a test for a non-MS-DOS) was only in a beta and never in any shipping versions; and b) the test itself had perfectly valid technical reasons for existing.
You also ignore that DRDOS had incompatibilities, particularly with games utilising the additional memory available via the HIMEM.SYS and EMM386.EXE memory managers present in later versions of DOS, or that were otherwise highly optimised under the assumption they would be running under MS-DOS.
Moving on to Novell:
Microsoft used this power to steal the word processing market, and this is how: they closely guarded their APIs until Windows 95 was released, and they shipped Word for Windows on the same day. It took Novell months to perfect a Windows 95 version of WordPerfect, and in that time they lost their market share.
Even ignoring how silly the idea of an *OS vendor* withholding *developer information* from *developers* is, the idea that Word 95 could somehow wipe out the market share of a decade's worth of entrenched WP users in a matter of months is not only flat-out ludicrous, but would be stunningly high praise of Word as a product if it had actually happened.
Wordperfect had been in decline for _years_ before Windows 95 - mainly because their early Windows products sucked massively - and since they were basically just DOS versions wrapped in a GUI layer, they took little to no advantage of the facilities Windows had to offer, like printing, truetype fonts, WYSIWYG and the like. As a consequence, anyone that wasn't already a hardcore WP user wasn't interested, because Word was easier to use, printed to any printer with Windows drivers and could give a good representation of what the printed output would look like on paper, while you were working on the document. Added to that, many WP users _were_ interested, because not only did Word offer significant advantages, but Microsoft went out of their way to make transitioning from WP to Word very easy, with full support for Wordperfect's file formats and keyboard controls. Back then, there was basically an option box that turned Word into a better looking, more functional version of WordPerfect (it's been a very long time, but IIRC it actually asked the user during install to choose between "Word or Wordperfect" compatibility).
Fundamentally, WP made the same mistake Lotus did - they ignored Windows as a "fad" or "toy" and barrelled on with their DOS-based products. Microsoft, OTOH, with years of experience from writing software for MacOS, were able to provide _good_ Windows/GUI-based apps that more people found attractive. Coupled with their intense desire to knock WP off its perch, and the lengths they went to to make the Wordperfect -> Word transition easy, it's probably the best example of Microsoft winning a market 100% on merit. You can read a more firsthand account here (I personally only have the perspective of a consumer from that era).
Your Internet Explorer comments ignore that a) the biggest period of growth Internet Explorer had was in the 6-odd months between IE4 being released for Windows 95 and Windows 98 being rele
Microsoft has had dozens, if not hundreds, of competitors over the last 30 years. You're going to need to be a bit more specific, because I'm sure as hell not going to list them all.
I am not sure if you are familiar with the history of this but the "success" of Microsoft is a result of confluence of several factors: a) IBM's irrational decision to tie its fortunes to Microsoft's on an exclusive basis, [...]
Ie: good business acumen on behalf of Microsoft. Another textbook example of capitalism.
[...] b) general public's lack of understanding of principles of computing, leading it to treat everything and anything PC-related as a brand-new, never before heard of discovery, never you mind not realizing that Microsoft was doing them great disservice by reinventing 20 year-old principles, poorly [...]
Completely irrelevant, as it applies to _all_ computer related products.
[...] and c) Bill's ability to create a vendor lock in, by unethical and morally repugnant manouvers both legal and technical.
Which are also done by everyone else. Again, not relevant because it's common - nay, *standard* - behaviour.
This is a text book example of failure of capitalism, the dangers of trusts and cartels and the limitations of the contribution-reward scheme when the consumers are deprived of sufficient information to make an informed purchase.
There has never been any shortage of information.
Re:Although this seems "reasonable" in light of th
on
Google Delists BMW-Germany
·
· Score: 2, Interesting
In no way is Google telling you how to design your web site.
In much the same way Microsoft doesn't tell OEMs how to configure their computers ?
Neither Bill Gates nor Paul Allen did ivented anything novel or unique [...]
Even assuming this is true, it is not in conflict with:
[...] reward contributors in direct proportion to their contributions [...]
The vast, vast bulk of transactions are not for things that are "novel or unique", nor are "contributions" in any way a measure of being "novel or unique".
Microsoft produced a product that a whole bunch of people thought was worth spending money on instead of its competitors, and thus made its founders rich. That is _textbook_ capitalism.
'I _literally_ feel that we do not - as software developers - have the moral right to enforce our rules on hardware manufacturers. We are not crusaders, trying to force people to bow to our superior God. We are trying to show others that co-operation and openness works better.'
Given the prevailing attitudes towards hardware vendors from a driver development perspective...
I disagree with you. GP post was right in that the operating system is inherently flawed and makes it easy for virus/malware software to be executed on it.
So how can the OS protect against it ? Given no shipping OS I'm aware is capable of auomatically identifying malicious code, you'll have to give a theoretical explanation.
The only thing Windows does that makes it "easy" for "virus/malware software to be executed" is, by default, allowing a couple of file extensions indicate that a file is a binary executable. This is, at worst, a minor issue - having to 'chmod +x' on unix is barely a speedbump.
Inadecuate user privileges policies: Microsoft Windows operating systems do not apply correct user privileges policies, in fact they have the worst policies possible giving ALL the process the user runs the possilibity to run with ADMINISTRATOR privileges, for example, letting an Internet Navigator (IE, Fx, etc) run with Administrator privileges is a potential flaw BY DESIGN.
Having a default user be an Administrator isn't even close to a design flaw. It's a default configuration semantic that is _trivially_ addressable by the end user.
Every OS runs applications in the context of the user that starts them (sans special conditions like Run As or sudo). If you load up Firefox as a root user, it runs as root. There is nothing unusual in Windows doing the same thing with Administrator.
Having a big dependency between the Operating System and an Internet navigator: Extending from point one, Microsoft OS have made the Internet Explorer web browser inherently tied to the Operating System use. This, combined with the problems that arise from the first point create a great security hole.
IE has the same design and architecture as khtml (in KDE) and WebCore (in OS X). It's a shared component, nothing more. It runs with the same privileges as the user. It's no different to the myriad shared libraries that exist in every other OS. It's "integration" into "the OS" is irrelevant to security.
Lack of proper file permissions and permission management: Microsoft Windows Operating systems didnt have any kind of file permission management until the most recent versions, and even on these (the Windows XP versions) they still use the "less secure" approach by default making it trivial for any process to delete an important OS file.
False. The default file permissions in Windows are as restrictive as they are on any other platform. A regular user _cannot_ delete an "important OS file".
Lack of good network security: Until recently (Service pack 2 of Windows XP) windows didn't have decent network security.
Service Pack 2 does next to nothing for "network security" except enable the firewall (that XP has always had) by default.
As you can see, it is the union of these problems that make the Operating System quite inscure and companies like Symantec, McAfee, SSSI and other exploit to profit.
Most of your conclusions are based on fallacious assumptions.
In almost all cases, anti-virus and anti-spyware programs protect against things OS security cannot. Ie: the detection and blocking of malicious code _after_ the user has chosen to execute it (ie: after the OS security has had its chance).
Of course the company that makes the software is not to blame (at it is not all their fault) as there are some technologies that where not considered native for the Operating Systems (like networking) and the OS developers can only enhance the software adding the new security (of course the response time may or may NOT be good).
WTF are you talking about ?
The Operating System function should be preventing the execution of malicious code (being it automatic or manual attacks) at least.
How do you propose it differentiates malicious code from normal code ? Almost everything "malicious" code does is only "malicious" because of the context.
Security on computers is like security in the real life, the OS should make it difficult enough for the attacker to dissuade them for trying it.
The OS does. Windows has the same capabilities as other OSes.
They should have been pushing much harder on this, doing things like refusing the use of trademarks to apps that are security-stupid when run on recent-enough Windows versions.
It's a requirement of the "Made for Windows" logo.
It never ceases to amaze me that people buy an Operating System (you really do one way or another) and then have to buy software to keep malware and other nasties out. At least with Unix/Linux OS's you can get security updates for the OS and in may cases, unless you have a subscription (good value for large corporations and even some small business) it can be free.
No amount of OS security can protect against the deliberate execution of malicious code.
To actually require virus protection is really a damming indictment of the Operating System [...]
No OS's security has a means of stopping the things most viruses do.
However, the architecture and coding practices of the other operating systems I mentioned make it much easier to avoid flaws altogether and also make it much easier to locate the flaws and correct them.
What "architectural and coding practices" are you thinking of ?
Being required to run Windows as administrator for many applications to work is just one simple example of extreme neglect for security. And yes this is partially the fault of Windows developers, however it's also largely Microsoft's fault for not teaching or enforcing developers using their platform to use sane security practices since day one.
Microsoft have been telling developers to write LUA-friendly apps for 6+ years now. They share zero blame for any remotely current application needlessly requiring Administrator level privileges to run.
I don't. But the effects of such an action could be dramatically reduced. The worst that should be able to do is to destroy the user's data. It shouldn't be able to take over the machine.
Don't run as a privileged user, and it can't (just like every other multiuser platform).
Good question. Frankly, that's a primary reason why the Registry is a near-complete design failure.
I'm not quite sure I follow. About the only qustionable design aspect of the Registry is the usage of a solely binary-file backend (which, when you consider it was conceived back around the 1990-93 timeframe, is quite justfiable).
Preference data that is specific to a particular application should be able to be changed by that application whenever it wants to.
Within the context of the user, yes.
Sensible OSs tend to do this by having separate files which hold per-app data, but there's nothing inherently wrong with a database model which keeps Windows from using this type of model.
Windows[0] does this with per-user, per-application Registry keys. Or, basically, the equivalent of ~/.<application> directories in unix. There are also system-wide application Registry keys, the equivalent of/etc/<application> in unix.
Moreover, this should not EVER require "admin" privileges, although one might want a "kiosk" class of user which prohibits even this.
If an application developer doesn't use the per-user Registry locations and instead chooses to use the system-wide Registry and _assumes_ that the user will be running as Administrator and able to modify it, then there's not much Windows can do about it, nor is there any blame that lies in the hands of Microsoft.
Preference data which modifies system behavior should require direct and specific user approval. Not many OSs get this right, although most do a better job than Windows.
This is all very hand-wavy, so it's nearly impossible to respond. However, am I right in assuming that a) regular users shouldn't be able to modify system-wide defaults and b) even for users that have the privileges to do so, they should be bombarded with "Are you sure" dialogs at every turn ?
Preference data which modifies OTHER apps should not be allowed, except with the "permission" of the other app (allowing for config utilities and plugins). Nice ideal, but generally I don't see that implemented anywhere. The failback SHOULD be to treat other apps just like system data, but generally OSs tend to treat other-app prefs the same as this-app prefs for convenience.
I'm not really sure what you mean by "preference data". I'm assuming you mean that for application A to make any changes to application B's configuration data, then application A must register with, and have the approval of, application B.
I hope you can see why this would make a general purpose editor (ie: RegEdit) completely unworkable and would seriously hinder - if not make impossible - troubleshooting and recovery.
In my experience, the general reason apps require Administrator privileges to run is that they want to be able to modify the Registry.
More specifically, they want to edit the *system-wide* Registry that, by default, only high-privilege users may do. These applications are broken, and should be using the per-user Registry hives.
See above.
Your apparent assumption (that the Registry is a monolithic entity with no permissions capabilities or user/applicaiton/system separation) is wrong. Hence, so are your conclusions.
Generally, these changes are of the first nature (remember what the user had set for preferences, etc). Many times, only a small subset of what an application does will require Admin privileges, but as there is no escalation procedure in the OS, they have to require Admin privileges from the outset, or not provide those utilities at all.
Firstly, there are "escalation procedures" in the OS.
Secondly, these applications are broken because they are trying to write to the wrong part of the Registry, that they do not (nor should) have permissions to modify. It is analagous to a random unix user's application trying to modify parts of/etc, rather than using ~ like it s
Maybe I'm just a bit compulsive but if I miss brushing my teeth in the morning, by night my teeth can feel pretty grimy (no I don't eat a lot of sugar).
Shouldn't make a lick of difference (unless you're eating at night after you brush).
But appliations in emails should not be able to hide the fact that they are applications.
They can't. When you try and open attachments you get a dialog that tells you it's a bad idea and the default response set to "Don't Open".
Applications should not be able to edit the registry without warning the user.
How is the OS supposed to tell the difference between a legitimate registry change and a malicious one ?
Users should not need to run as Administrator to make their computers work properly.
I agree. Blame the people who are writing software that does, it's their fault.
The registry is itself pretty sucktastic as far as security design goes.
Bollocks. The Registry has per-user ACLs on each key. It's got a better "security model" than most OSes.
I don't know the specifics of this worm, but times have come a long way from where you'd have to click on at attachment, select save, and then run. Nowadays the infection can happen automatically, instantly, and completely unobserved -- all because Microsoft figures it should automatically execute anything that looks executable (or that you're not really mature enough to see the extension of this file, so it looks like a JPG, or just simply because it's fun.)
You seem to have that arse about face. It's been getting steadily harder and harder, with every patch and revision, to run executable content directly from an email client.
Not that any version of Outlook has - by design - ever automatically executed attachments.
Time was when someone would send you an e-mail warning you that should shouldn't even click on an attachment since it could be a virus, you would politely tell them it was impossible. Nowadays, that's simply not true any more.
It's always been possible for an attachment to be a virus. Certain Windows email clients make it *marginally* easier for such code to be executed, that's it.
The only thing I've ever managed to do with "Run As" is install a program.
That just says you've not tried to use it much at all.
If there is any capability to do anything else, it's managed to hide itself from me.
Just about every executable file type will have a "Run As" option in its context menu. Those that don't (most notably, Control Panel applets) display it with a shift-right click.
However, if developers write their software properly, you shouldn't _need_ to manually right click, the program itself will prompt for credentials whenever a higher privilege level is needed.
Which is why I blame Microsoft for basically forcing every user who sometimes must perform administrative tasks to be root all the time.
Your blame is misplaced. I have used all my Windows NT machines with a non-admin login since 1996.
I agree that legacy software is not an outright excuse for bad code. That's why I say I wouldn't totally absolve Microsoft of responsibility. I'm just saying they're the ones who built their legacy. I think that along with the other issue means they need to share responsibility for this continuing problem.
Since about 1997, software developers have had no excuse for writing software that needlessly requires administrator privileges (before then, DOS-based Windows lacked the per-user profiles and registries of NT-based Windows, so developers could feasibly say that the maintenance costs of two slightly different versions of their software were a problem). Microsoft deserve no blame for any remotely current piece of software that needlessly requires an Administrator account to run.
Slashdot Mirror
Ah, yes, the standard "look how quick I can do it on Linux vs Windows" comparison, where not only is the quickest method on Linux chosen, compared to the slowest method on Windows but, additionally, steps which are given as single and generic on one are broken down into specific sub-steps on the other.
Heck, why aren't you counting individual keypresses as steps on Windows ? It'd be only marginally less subtle than the bullshit you posted.
Both IE and Office work fine as a non-Administrator.
Windows applications that don't run as regular users, in this day and age, are 100% the fault of the software developers. They have no excuse for badly written software that needlessly requires Administrator privileges.
If you follow the same procedures on both OSes, both will protect from being "borked" equally.
You seem to be missing the point. Just because the default _is_ an Administrator, is not justification for developers ignoring Microsoft's recommendations, universal best principals, and just sheer common sense by writing applications that _needlessly_ require Administrator privileges.
An application that "needs" Administrator access because it's badly written, is solely the responsibility - and fault - of the application developer.
This is the software's fault, not Windows'.
Considering the bias and errors, it's hardly "informative".
I assume that by:
You're talking about the ability to load parts of the DOS kernel, along with drivers into the Upper Memory Area. This actually happened with DR-DOS 5, in 1990. MS-DOS followed afterwards in mid-1991 (and the delay - coupled with the disaster that was DOS 4.0, cost them badly).
Following on, your comments about Windows 3.1 completely ignores that a) the non-MSDOS detection in Windows 3.x (note: not a specific test for DR-DOS, but a test for a non-MS-DOS) was only in a beta and never in any shipping versions; and b) the test itself had perfectly valid technical reasons for existing.
You also ignore that DRDOS had incompatibilities, particularly with games utilising the additional memory available via the HIMEM.SYS and EMM386.EXE memory managers present in later versions of DOS, or that were otherwise highly optimised under the assumption they would be running under MS-DOS.
Moving on to Novell:
Even ignoring how silly the idea of an *OS vendor* withholding *developer information* from *developers* is, the idea that Word 95 could somehow wipe out the market share of a decade's worth of entrenched WP users in a matter of months is not only flat-out ludicrous, but would be stunningly high praise of Word as a product if it had actually happened.
Wordperfect had been in decline for _years_ before Windows 95 - mainly because their early Windows products sucked massively - and since they were basically just DOS versions wrapped in a GUI layer, they took little to no advantage of the facilities Windows had to offer, like printing, truetype fonts, WYSIWYG and the like. As a consequence, anyone that wasn't already a hardcore WP user wasn't interested, because Word was easier to use, printed to any printer with Windows drivers and could give a good representation of what the printed output would look like on paper, while you were working on the document. Added to that, many WP users _were_ interested, because not only did Word offer significant advantages, but Microsoft went out of their way to make transitioning from WP to Word very easy, with full support for Wordperfect's file formats and keyboard controls. Back then, there was basically an option box that turned Word into a better looking, more functional version of WordPerfect (it's been a very long time, but IIRC it actually asked the user during install to choose between "Word or Wordperfect" compatibility).
Fundamentally, WP made the same mistake Lotus did - they ignored Windows as a "fad" or "toy" and barrelled on with their DOS-based products. Microsoft, OTOH, with years of experience from writing software for MacOS, were able to provide _good_ Windows/GUI-based apps that more people found attractive. Coupled with their intense desire to knock WP off its perch, and the lengths they went to to make the Wordperfect -> Word transition easy, it's probably the best example of Microsoft winning a market 100% on merit. You can read a more firsthand account here (I personally only have the perspective of a consumer from that era).
Your Internet Explorer comments ignore that a) the biggest period of growth Internet Explorer had was in the 6-odd months between IE4 being released for Windows 95 and Windows 98 being rele
Microsoft has had dozens, if not hundreds, of competitors over the last 30 years. You're going to need to be a bit more specific, because I'm sure as hell not going to list them all.
I am not sure if you are familiar with the history of this but the "success" of Microsoft is a result of confluence of several factors: a) IBM's irrational decision to tie its fortunes to Microsoft's on an exclusive basis, [...]
Ie: good business acumen on behalf of Microsoft. Another textbook example of capitalism.
[...] b) general public's lack of understanding of principles of computing, leading it to treat everything and anything PC-related as a brand-new, never before heard of discovery, never you mind not realizing that Microsoft was doing them great disservice by reinventing 20 year-old principles, poorly [...]
Completely irrelevant, as it applies to _all_ computer related products.
[...] and c) Bill's ability to create a vendor lock in, by unethical and morally repugnant manouvers both legal and technical.
Which are also done by everyone else. Again, not relevant because it's common - nay, *standard* - behaviour.
This is a text book example of failure of capitalism, the dangers of trusts and cartels and the limitations of the contribution-reward scheme when the consumers are deprived of sufficient information to make an informed purchase.
There has never been any shortage of information.
In much the same way Microsoft doesn't tell OEMs how to configure their computers ?
Even assuming this is true, it is not in conflict with:
[...] reward contributors in direct proportion to their contributions [...]
The vast, vast bulk of transactions are not for things that are "novel or unique", nor are "contributions" in any way a measure of being "novel or unique".
Microsoft produced a product that a whole bunch of people thought was worth spending money on instead of its competitors, and thus made its founders rich. That is _textbook_ capitalism.
Given the prevailing attitudes towards hardware vendors from a driver development perspective...
So how can the OS protect against it ? Given no shipping OS I'm aware is capable of auomatically identifying malicious code, you'll have to give a theoretical explanation.
The only thing Windows does that makes it "easy" for "virus/malware software to be executed" is, by default, allowing a couple of file extensions indicate that a file is a binary executable. This is, at worst, a minor issue - having to 'chmod +x' on unix is barely a speedbump.
Inadecuate user privileges policies: Microsoft Windows operating systems do not apply correct user privileges policies, in fact they have the worst policies possible giving ALL the process the user runs the possilibity to run with ADMINISTRATOR privileges, for example, letting an Internet Navigator (IE, Fx, etc) run with Administrator privileges is a potential flaw BY DESIGN.
Having a default user be an Administrator isn't even close to a design flaw. It's a default configuration semantic that is _trivially_ addressable by the end user.
Every OS runs applications in the context of the user that starts them (sans special conditions like Run As or sudo). If you load up Firefox as a root user, it runs as root. There is nothing unusual in Windows doing the same thing with Administrator.
Having a big dependency between the Operating System and an Internet navigator: Extending from point one, Microsoft OS have made the Internet Explorer web browser inherently tied to the Operating System use. This, combined with the problems that arise from the first point create a great security hole.
IE has the same design and architecture as khtml (in KDE) and WebCore (in OS X). It's a shared component, nothing more. It runs with the same privileges as the user. It's no different to the myriad shared libraries that exist in every other OS. It's "integration" into "the OS" is irrelevant to security.
Lack of proper file permissions and permission management: Microsoft Windows Operating systems didnt have any kind of file permission management until the most recent versions, and even on these (the Windows XP versions) they still use the "less secure" approach by default making it trivial for any process to delete an important OS file.
False. The default file permissions in Windows are as restrictive as they are on any other platform. A regular user _cannot_ delete an "important OS file".
Lack of good network security: Until recently (Service pack 2 of Windows XP) windows didn't have decent network security.
Service Pack 2 does next to nothing for "network security" except enable the firewall (that XP has always had) by default.
As you can see, it is the union of these problems that make the Operating System quite inscure and companies like Symantec, McAfee, SSSI and other exploit to profit.
Most of your conclusions are based on fallacious assumptions.
In almost all cases, anti-virus and anti-spyware programs protect against things OS security cannot. Ie: the detection and blocking of malicious code _after_ the user has chosen to execute it (ie: after the OS security has had its chance).
Of course the company that makes the software is not to blame (at it is not all their fault) as there are some technologies that where not considered native for the Operating Systems (like networking) and the OS developers can only enhance the software adding the new security (of course the response time may or may NOT be good).
WTF are you talking about ?
The Operating System function should be preventing the execution of malicious code (being it automatic or manual attacks) at least.
How do you propose it differentiates malicious code from normal code ? Almost everything "malicious" code does is only "malicious" because of the context.
Security on computers is like security in the real life, the OS should make it difficult enough for the attacker to dissuade them for trying it.
The OS does. Windows has the same capabilities as other OSes.
It's a requirement of the "Made for Windows" logo.
No amount of OS security can protect against the deliberate execution of malicious code.
To actually require virus protection is really a damming indictment of the Operating System [...]
No OS's security has a means of stopping the things most viruses do.
What "architectural and coding practices" are you thinking of ?
Being required to run Windows as administrator for many applications to work is just one simple example of extreme neglect for security. And yes this is partially the fault of Windows developers, however it's also largely Microsoft's fault for not teaching or enforcing developers using their platform to use sane security practices since day one.
Microsoft have been telling developers to write LUA-friendly apps for 6+ years now. They share zero blame for any remotely current application needlessly requiring Administrator level privileges to run.
Don't run as a privileged user, and it can't (just like every other multiuser platform).
I'm not quite sure I follow. About the only qustionable design aspect of the Registry is the usage of a solely binary-file backend (which, when you consider it was conceived back around the 1990-93 timeframe, is quite justfiable).
Preference data that is specific to a particular application should be able to be changed by that application whenever it wants to.
Within the context of the user, yes.
Sensible OSs tend to do this by having separate files which hold per-app data, but there's nothing inherently wrong with a database model which keeps Windows from using this type of model.
Windows[0] does this with per-user, per-application Registry keys. Or, basically, the equivalent of ~/.<application> directories in unix. There are also system-wide application Registry keys, the equivalent of /etc/<application> in unix.
Moreover, this should not EVER require "admin" privileges, although one might want a "kiosk" class of user which prohibits even this.
If an application developer doesn't use the per-user Registry locations and instead chooses to use the system-wide Registry and _assumes_ that the user will be running as Administrator and able to modify it, then there's not much Windows can do about it, nor is there any blame that lies in the hands of Microsoft.
Preference data which modifies system behavior should require direct and specific user approval. Not many OSs get this right, although most do a better job than Windows.
This is all very hand-wavy, so it's nearly impossible to respond. However, am I right in assuming that a) regular users shouldn't be able to modify system-wide defaults and b) even for users that have the privileges to do so, they should be bombarded with "Are you sure" dialogs at every turn ?
Preference data which modifies OTHER apps should not be allowed, except with the "permission" of the other app (allowing for config utilities and plugins). Nice ideal, but generally I don't see that implemented anywhere. The failback SHOULD be to treat other apps just like system data, but generally OSs tend to treat other-app prefs the same as this-app prefs for convenience.
I'm not really sure what you mean by "preference data". I'm assuming you mean that for application A to make any changes to application B's configuration data, then application A must register with, and have the approval of, application B.
I hope you can see why this would make a general purpose editor (ie: RegEdit) completely unworkable and would seriously hinder - if not make impossible - troubleshooting and recovery.
In my experience, the general reason apps require Administrator privileges to run is that they want to be able to modify the Registry.
More specifically, they want to edit the *system-wide* Registry that, by default, only high-privilege users may do. These applications are broken, and should be using the per-user Registry hives.
See above.
Your apparent assumption (that the Registry is a monolithic entity with no permissions capabilities or user/applicaiton/system separation) is wrong. Hence, so are your conclusions.
Generally, these changes are of the first nature (remember what the user had set for preferences, etc). Many times, only a small subset of what an application does will require Admin privileges, but as there is no escalation procedure in the OS, they have to require Admin privileges from the outset, or not provide those utilities at all.
Firstly, there are "escalation procedures" in the OS.
Secondly, these applications are broken because they are trying to write to the wrong part of the Registry, that they do not (nor should) have permissions to modify. It is analagous to a random unix user's application trying to modify parts of /etc, rather than using ~ like it s
Shouldn't make a lick of difference (unless you're eating at night after you brush).
They can't. When you try and open attachments you get a dialog that tells you it's a bad idea and the default response set to "Don't Open". Applications should not be able to edit the registry without warning the user.
How is the OS supposed to tell the difference between a legitimate registry change and a malicious one ?
Users should not need to run as Administrator to make their computers work properly.
I agree. Blame the people who are writing software that does, it's their fault.
The registry is itself pretty sucktastic as far as security design goes.
Bollocks. The Registry has per-user ACLs on each key. It's got a better "security model" than most OSes.
How do you propose they secure against users deliberately running malicious code ?
No, it's not. This worm requires user interaction to install.
You seem to have that arse about face. It's been getting steadily harder and harder, with every patch and revision, to run executable content directly from an email client.
Not that any version of Outlook has - by design - ever automatically executed attachments.
Time was when someone would send you an e-mail warning you that should shouldn't even click on an attachment since it could be a virus, you would politely tell them it was impossible. Nowadays, that's simply not true any more.
It's always been possible for an attachment to be a virus. Certain Windows email clients make it *marginally* easier for such code to be executed, that's it.
It does, to a degree. Use "Run As" to execute the attachment in a dedicated Limited User account.
That just says you've not tried to use it much at all.
If there is any capability to do anything else, it's managed to hide itself from me.
Just about every executable file type will have a "Run As" option in its context menu. Those that don't (most notably, Control Panel applets) display it with a shift-right click.
However, if developers write their software properly, you shouldn't _need_ to manually right click, the program itself will prompt for credentials whenever a higher privilege level is needed.
Which is why I blame Microsoft for basically forcing every user who sometimes must perform administrative tasks to be root all the time.
Your blame is misplaced. I have used all my Windows NT machines with a non-admin login since 1996.
I agree that legacy software is not an outright excuse for bad code. That's why I say I wouldn't totally absolve Microsoft of responsibility. I'm just saying they're the ones who built their legacy. I think that along with the other issue means they need to share responsibility for this continuing problem.
Since about 1997, software developers have had no excuse for writing software that needlessly requires administrator privileges (before then, DOS-based Windows lacked the per-user profiles and registries of NT-based Windows, so developers could feasibly say that the maintenance costs of two slightly different versions of their software were a problem). Microsoft deserve no blame for any remotely current piece of software that needlessly requires an Administrator account to run.
Because the "issue" is typically the person using the computer.
I, for one, would be up in arms if a company took such an overtly-passive approach to the security of their software.
How do you secure against a user deliberately (even if inadvertently) executing malicious code ?
Virus scanners are not there to protect against OS flaws or exploits, they're protect against malicious code being executed.
With ten years of hindsight, you'd fucking well hope so.
A default installation of XP is as insecure as Win9X.
Difference is, an XP installation is trivially securable.