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.
In case you aren't ready when Dvorak makes Al Capone related references: http://en.wikipedia.org/wiki/Frank_Nitti
~jennifer.k~
Anyone who suggests 'abandoning the use of the registry' has obviously never written Windows software. What do you suggest we replace it with, INI files? What do you suppose we do about the thousands of existing applications that use the registry? How do you suggest we support access controls for individual settings and keys - make a single INI file for each one?
Changes like 'get rid of the registry' are changes you make when you release a new OS, not when you release a service pack. OS X, for example, uses flatfiles to store most (if not all) preferences, but that's something they designed in from the start.
It's pretty annoying how people always suggest blatantly stupid 'solutions' to problems instead of focusing on real fixes like better design and better testing...
using namespace slashdot;
troll::post();
Maybe because GConf is only a tool to flip switches in human readable xml files..not a registry.
Ubuntu: If at first you don't succeed, blindly slap a sudo in front of it
I forgot to turn off my CUTEftp client and left it running all night. In the morning some system had loaded some weird software called "active skin," and I had to use SpySubtract to remove 26 Registry entries...how anything manages to worm in through the open port and place items in the Registry is beyond me, but it happens all the time.
Amazing how he jumps to the conclusion that because something told him he had spyware on his system, he assumes it's because he left an FTP client in memory overnight. Interesting theory.
Because FTP clients typically aren't exploitable "through an open port", you dingleberry, let me propose an alternate theory: You're a clueless moron that doesn't understand the most basic of security concepts.
I'm a big tall mofo.
The Registry is a large, undocumented, binary file readable only by itself; GConf is a program to edit human-readable XML files.
I am not so keen on either but GConf is still the better option
Guy asked me for a quarter for a cup of coffee. So I bit him.
He has actually gone out and complained in a column about the System Idle Process taking up 98% of cpu on his Windows machine and making the box thrash.
This is the said article.
http://www.pcmag.com/article2/0,1759,1304348,00.a
>> Anyone who suggests 'abandoning the use of the registry'
>> has obviously never written Windows software. What do
>> you suggest we replace it with, INI files?
> Or property lists, yes.
Well, INI files don't scale well; not because they are flat text files, but because the way a hierarchy is modelled in an INI file is inefficient and error prone. Something in the nature of a property list would be quite reasonable.
It is also worth noting that since DotNet, lots of data that used to be in the Registry is now in XML files in the application folder. That's a big part of the XCOPY install feature MS brags about for DotNet.
>> What do you suppose we do about the thousands of existing
>> applications that use the registry?
> Wrappers for the INI/PLIST files that behave like the old
> registry calls.
Perfectly doable.
>> How do you suggest we support access controls for individual
>> settings and keys - make a single INI file for each one?
> Why not?
Well, it isn't strictly necessary to use the Registry to support access controls on keys and settings. As long as the file itself only allows administrator access, the APIs that model the current Registry APIs can implement key and value level security within the file. This would make the files read-only in a text editor for common users; however a simple editor could be created that allows the appropriate access to the individual keys via the APIs.
But INI files aren't appropriately structured for that; XML files would be better, or any number of less-verbose-than-XML text formats.
> OS X does this like a dream, I can take my Library folder with me
> and wham, everything is the way I like it on a new machine. I'm
> sure it would be possible to do something similar on Windows,
> provided I paid $50 for some crappy shareware product.
Well, it wouldn't be a crappy $50 shareware product to virtualize the Registry. Since the APIs are inside ADVAPI32.DLL, and are used during the boot process, it would be a kernel hack; generally more expensive when done third-party. MS could do it safely; third parties would need to worry about MS breaking the hack with an OS update.
The last time I took Dvorak seriously was in the late 80's. Once I got a clue, I realized he didn't have one and I started ignoring him. He isn't news, nor is he stuff that matters. He's just a lump of clay that one day will turn into worm food, like the rest of us, but unlike the rest of us, he can safely be ignored.
Word of the post: benign
How does a program run without you having any knowledge that it was started? The registry makes this easy, as there are many places for malware to hide. The argument is outdated, however, as there are good tools to find what's hiding in the 6 or 7 places in the registry that specify programs to start automatically, and malware is moving into kernel space.
Socialism: a lie told by totalitarians and believed by fools.
I could understand it if those best practices were really complicated or undocumented, but they're not. Programmers are just lazy.
He claims to be qualified to blame Microsoft for security holes in its products, doesn't he? It's clear that he was slammed by a security hole in a third-party application he was running on his system as an Administrator. (Not to mention, a third party application with a history of known defects...)
He has no business complaining about Microsoft's "protection racket" if he honestly doesn't understand that his recent issue has jack-squat to do with Microsoft.
To be fair, he was complaining about an explorer hang (he only bitched that the system was pretending to be idling).
i ntermittent-and-annoying.html
That's quite common in some situations, and Russinovitch dissecates one quite nicely in his blog:
http://www.sysinternals.com/blog/2005/08/case-of-
Later versions of CuteFTP supposedly don't contain Aureate. Supposedly. You may or may not believe them. Better to not use CuteFTP, any other Globalscape product, any Aureate/Radiate product, or any product that ever contained Aureate. Here's a old list of programs known to contain Aureate.
Aureate changed its name to Radiate. In 2001, they settled a class action over privacy issues.
Radiate tried again with "Go!Zilla". Some versions of Go!Zilla have adware and/or spyware. The current makers of GoZilla claim "The current Go!Zilla software contains no advertising. There are several older, out-of-date versions of Go!Zilla which contain advertising from 3rd parties." But then they say "Go!Zilla will make certain partner software programs available to you during the Go!Zilla trial version's installation. These products are not necessary to the function of Go!Zilla, and you may decide if wish to install them. Make sure you read the installation prompts carefully to insure you get the best installation for you. Each partner program has its own privacy policy, and Go!Zilla is careful to screen partners for product quality and responsible privacy policies."
Or, in other words, "we're going to load up your machine with adware if you're not very, very careful during the install."
Aureate/Radiate appears to be defunct. Unclear whether they went bankrupt, were acquired, or are on the lam.
AdAware can be helpful if your system is infected with Aureate/Radiate, although it may not find attacks downloaded via the security holes.
For more details about Aureate, Radiate, and CuteFTP, click here (long .pdf).
If that's the case, why does Windows XP Home Edition default to making the user's primary account an administrative account -- one which requires no password unless you tell it explicitly to require one?
In many corporate IT organizations, it's become commonplace to grant administrative privileges to a user for their local machine; they still can't use those privileges network-wide, but it gives them enough ammo to shoot themselves in the foot. It's just more practical (in the eyes of IT staffers, anyway, if not in reality) to do that, rather than have an administrative account and password that's global which everyone knows. This has the added advantage of creating an audit trail so that when a user installs some unauthorized software on a workstation, it becomes pretty easy to tell who installed it.
Logging in with an unprivileged account and then running binaries piecemeal with administrative privileges sounds great in theory, until you have to run some ill-behaved software that assumes you're already logged in as an administrator. (This happens a lot at my workplace, but I can't really elaborate more than that.) The inconvenience and impracticality really has an effect on productivity.
I'm not saying that your suggestion (using "Run As...") won't work... just that in the real world, most people would chafe if they were forced to work like that. That, plus the ill-behaved 3rd party software issue I mentioned, really makes it not a very good practical idea.
The problem with "Run As..." is that it still requires you to give out the Admin (root) password. There is no equivalent to su/sudo/setuid programs, where you can give out privileges on a per-program basis.
Would you give out the root password to your users?
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Why the registry is Good:
n (where a lot of spyware hooks itself) shouldn't even exist because it refers to machine-specific files (not user specific)
1. As of W2K, you can assign permissions (granted, useless if everybody runs as admin)
2. Program settings under HKCU follow users around (when implemented properly, this works very well)
3. Easy to read/write from
The pains of the registry often have not much to do with the registry itself:
1. Silly things like HKCU\Software\Microsoft\Windows\CurrentVersion\Ru
2. IE's poorly-implemented ActiveX plug-in architecture is not a registry problem, it is an application design problem (if IE used a flat config file to store the ActiveX info, it would still be just as bad)
3. Microsoft Office stores its configuration data as binary blobs instead of typed data - laziness that causes unnecessary cross-version compatibility issues
If Microsoft would simply disable the Run key in HKCU, set up an Execute flag (like *nix) and make it default to run as non-admin (which it does in Vista, AFAIK), it would be quite a bit more secure than it is. At any rate, though, none of these things has much to do with the registry. If startup programs were stored in a file somewhere, it would be well-known quickly enough, and we would have just as many problems. Security through obfuscation doesn't work, we all know that.
You appearently are not familiar with Dvorak or his writing. He is definately NOT a linux zealot and he always writes like that. I've been reading his articles for 15 years and he almost always makes me laugh at least once per article. This one was no exception.
Nope. He's not a troll or a zealot. He's just another pissed off user who's not afraid to tell the hard truth.