Slashdot Mirror
The Microsoft Protection Racket
bonch writes "Dvorak writes about the 'Microsoft protection racket' in his latest column--'charging real money for any sort of add-on, service, or new product that protects clients against flaws in its own operating system.' Dvorak argues that someone took a look at the expense of Microsoft's monthly 'Patch Tuesday' and decided to find a way to make money from it instead of fix the code (e.g., abandoning the use of the registry)." I enjoy salt with my Dvorak, but that's just me.
Microsoft Windows - Operating system. Provides resource allocation to underlying computer hardware. Note: No warrantee, no guarantees, may have security issues.
Microsoft Security - Subscription security service. Provides security monitoring of underlying insecure operating system. Note: No warrantee, no guarantees, may have security issues.
The NSA: The only part of the US government that actually listens.
While the views of the pundit may be questionable sometimes, it *is* a conflict of interest to charge fees for protection against your own flaws. Initially I'm sure they will try to continue securing the operating system while considering this service a backstop for users who violate basic common sense. When viewed that way, the extra fees make sense: I haven't had a security *alert* about an attempted infection in many years, mostly because I secure my environ and don't do stupid things. But for those who can't handle such things, and extra fee "security blanket" is acceptable.
In the long run though, if the security software becomes a security blanket for *Microsoft* and basically is a required purchase to host a secure environment despite the security efforts of administers outside such extra fee tools, it would appear to be nothing more than a backdoor to charge annual fees to all those who dare resist the "Software Assurance" garbage. Oh, and them too, just more fees.
Sig under construction since 1998.
And what is wrong with an individual INI file per app and/or per user? I mean, *nix has been using that for a long time, and it sure makes down-and-dirty administration ten times easier. The registry editor is a f**cking nightmare compared to your favorite text editor and *.conf or *.rc. Security is handled through the file system. The registry was a bad idea from the get-go, but you're right, Microsoft's incompetence will be with us until the world finally tells Redmond to take their crappy operating system and shove it.
The world's burning. Moped Jesus spotted on I50. Details at 11.
There's really nothing wrong with the foundations at all. The problem has been (1) the shell and its various subsystems (particularly IE), (2) programmer practices, and (3) user practices. Microsoft is of course fully responsible for (1), and, in fairness, security for these is free even to pirates. For (2) and (3), though, while they have encouraged best practices, they have made the decision not to enforce them. Enforcement of best practices, though, would not be IMO a good idea - the user should always have ultimate control over their machine.
If you don't know where you are going, you will wind up somewhere else.
It's better because you can use a frickin text editor. The settings are discrete and can be easily copied. When I move my account to a different *nix box, I just zip up my configs, unzip them on the new account, and maybe, if locations are different, do a bit of tweaking. I've had the same damn .pinerc file for four years now. It's easy to archive, easy to restore and easy to alter. The registry is a pain to back up, can be really ugly to restore and alteration requires a stinking idiotic registry editor.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The registry and analogous flat file data stores try to achieve the same goals. I think the registry makes several mistakes:
- Consolidating all settings into one proprietary data store. This imposes a new security mechanism over that of simple file access. This unique data store does nothing by itself to "secure" the data, it's just a box. One can lock the entire box but simple users do effect changes in the registry.
- INI files are plaintext versions of some sort of file. Their manipulation could be by hand (trad *nix style), or employ one of several storage syntax mediums (XML being one) which allows general tools to work across the items.
- File-based security on INI files is stronger, and more easily managed with existing tools, than key-based security on the hive-based registry entries. Combining with journaling/versioning, INI files hold more depth than a registry (which has to import/export to a file-based representation to achieve this).
- Line-item security on INI files is not as strong, hence the danger people have in by-hand editing. This can be overcome using a syntax that allows for tool-based editing, where then INI files expose their keys, and a security table holds a File/Key/Role association.
- Shared INI files for library management (aka COM) have the same write-contention isses as the registry, so no differences there. GAC-style libraries are directory-based, which seems to lend evidence that both file and registry stores for libraries are based done higher up in the file system.
What's wrong with the registry? Sure there are better ways to do it from an end-user point of view, but you can't blame the registry for all of windows problems. All the registry is is a database of configuration options for applications, system, etc. What would you rather have, a mess of unorganized and inconsistent files in /etc and ~/.appname? In either case, the registry has NOTHING to do with spyware infection. It's merely the underlying system that gets edited once a malicious program gets in. SOMETHING has to contain system and application configuration options, and whatever it is will be called a registry. The actual implementation is irrelevant.
Whatever Dvorak would like to see replace it (notice that he didn't make a suggestion for improvement, just that "there has to be something better") will suffer the same problems as the registry if the security holes allowing unauthorized programs to edit it aren't fixed.
Both systems blow, and just as equally. It is the difference between any centralized and distributed system.
Centralzied-
Clean standard
less flexibility
single point of failure
better security (advanced ACL support, not every app has it own parser)
OS maintained
Terrible portability
Distributed
no standard exists
more flexibity
no single point of failure
weaker security (it is either put in user or etc, you do not have an option of put in etc but allow just this setting for users)
App maintained
Easy portability
Best solution is to use both and let app decide
but a nightmare for sys admins
You have to remember, the main purpose of the registry is to obscure information, not to make it easy to find and edit. Software makers want to be able to put autostart hooks, serial numbers and other such nonsense on the computers, and Microsoft gives them what they want. If you put everything in an .ini file, users would be able to find it and control it, which is exactly what software manufacturers don't want (in most cases).
They can get rid of the registry once they have "Trusted Computing" in place, as they'll easily be able to drop application information into encrypted files that the user has no way of breaking into.
Global settings go in /etc. Per-User settings go under the home directory. The default per-user settings are stored in /usr/share and copied in the first time the program is run. Wow, that was hard wasn't it?
See the way Apple has done this. Global app settings in /Library, personal App settings in ~user/Library. When I used to do desktop support (50/50 mix of OS X and Windows) all we had to do when we moved a user to a different machine was image it and copy their home directory. Easy as pie, takes about 10 minutes of my time. Wow, once again it was really hard to answer that "where does it go" question.
Gotta save a users settings when moving them to a different windows install (usually because the students laptop was so spyware ridden it was easier to just reformant)? Let the nightmare begin!
Trying to reinstall a hosed application that won't uninstall properly? Lets just see you try to track down all those registry keys. On a Mac or Linux you just remove the rc file or plist.
And what is the format of said INI file?
Once again, see Apple's plists. XML all the way, with tools to manipulate them if you don't like your text editor.
And what do the permissions need to be for the app to run? And what do the permissions need to be for a sane security approach.
Users their own config settings. If you want to restrict access to global config settings, just don't give them access to the config file. If you don't want them to run the program, don't give them read and execute permissions on the app itself. There are other operating systems out the besides windows, and they've already solved these problems. In the case of Unix, about 20 years ago. I've done Unix, Apple and Microsoft desktop administration, and while the Unix and Apple solutions do have a few quirks (Apple's system doesn't really have many), the Registry is by far the most broken and the biggest PITA.
Why?
A classic example of poor design.
By having many different INI files, the loss of one file isn't going take the whole frigging system out.
I guess convenience is more important than resiliency to some, but since that's been Microsoft's approach to damn near everything for the past 20 years it doesn't surprise me in the least...
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.