An interview with Ad-Aware's Nicholas Stark 199
Andrew Leonard writes: "In the wake of the Ad-Aware/RadLight spyware vs. anti-spyware showdown, Salon has an interview with Ad-Aware's Nicholas Stark, who explains in no uncertain terms Lavasoft's determination to match every move by the spyware developers."
Radsoft (Score:2, Informative)
I do not believe that it is legal to bind the usage of their software to the removal of an unrelated product.
But how is it an unrelated product? Ad-Aware goes out and specifically prevents programs like those put out by Radsoft from working properly. While I agree it isn't right that Ad-Aware is removed from the user's program without due warning, it is far from unrelated.
Re:license (illegal?) (Score:2, Informative)
Spyware -> Trojan horse (Score:3, Informative)
Although I couldn't find a definition for the term trojan horse on CERT's website [cert.org], a link was provided to the comp.virus FAQ [faqs.org]. According to it, a trojan horse is:
What RadWare's software is doing makes it perfectly clear that spyware should be treated as a trojan horse (with legal implications where applicable), beacause that's what it is.
Re:Radsoft (Score:5, Informative)
Its pretty simple. Radsoft's package can function perfectly well with Ad-Aware also installed. They have nothing directly to do with each other.
Granted, the politics and business of the two clash. I could understand that Radsoft feels threatned by Ad-aware. And it wouldn't be suprising if they took measures to protect their revenue. However, I would expect them to take steps to ensure all installed components remain installed for their application to function.
Of course, Radsoft has done a great job at displaying their attitude towards their users. Not only does their revenue apparently depend on the questionable (and apparently unappreciated by users) practice of spy-ware, but they take the same attitude to underhandedly remove software with which they have a political axe to grind.
One final point. Ad-Aware is considerably different in intent and attitude than any of the software it targets. First, the Ad-Aware user actively selects what components (including applications, libraries, registry entries, and cookies) to remove. Secondly, it is widely supported as it provides even fairly non-technical users the ability to discover hidden software installed on their systems and remove it despite the great lengths that software goes to hide and resist being removed.
If Radsoft and their clients, as well as the apparently growing number of like-minded business and applications developers, dislike the power provided by Ad-Aware then they should seriously re-examine their business plan. There is considerable resistance towards their methods. And simply attempting to remove Ad-Aware does little more than reveal their contempt for their user base.
Re:This problem can be solved by... (Score:2, Informative)
Exactly. The self-installing executable is a fine example of convenience being the enemy of security: At first, it sounds like a good idea. The program knows how to install the program you want with no interference from you. But if the program installs something you don't want, you're screwed. Why a program should have that level of trust on an OS is another issue you address in your next point:
2. This is more difficult one to implement. I think application should have some levels of access on your system and they should be disabled by default. For example, multimedia player should not be allowed to delete files or initiate outgoing network connection. Even file read can be made more granular by restricting the file mime type that an application can read. Multimedia player has no business reading any other files than ones that it knows what to do with. This sort of sandbox could make it harder for application from whacking competitor's application.
That is a tough nut to implement, I'd imagine, but the work has been done: *nix file permissions. A file has only the permissions its creator (or the superuser, root) gives it (so 'image files' can't run as programs), and an executable created by a certain user only has the permissions of that user, so it can't whack anything the user himself couldn't whack. So, on a *nix-y system, you could make AdAware untouchable to normal users and then only install software (other than AA) as a normal user. Problem solved.
Ultimately an implicit trust should be abandoned and implementing mandatory security may be the solution.
I think all multi-user OSes have reached this conclusion.
Unfortunately this is not something that can be easily added easily but rather it must be designed into the underlying system itself.
True. The file-permission system wasn't bolted on to Unix.
I'm writing this at 6:00am after staying up all night writing code so I'm sure lot of loopy ideas are leaking from my brain at the moment. This may be one of them.
These loopy ideas are what make *nix boxes so tough to crack.
Re:boot disk ad-aware needed (Score:4, Informative)
This catches any software that tries to attack the anti-virus software and the AdAware software.
Re:Adaware, while good, is similar to Radlight (Score:2, Informative)
If you're really serious about pruning out spyware from your system, you probably shouldn't be running KaZaA (or at least the regular version) in the first place, I think. That's like having a security specialist who insists on running a firewall, but leaves the settings at "low" all the time so that he can run a particular game. You can't claim to be actively concerned when you knowingly compromise your system.
Speaking of spyware, as I work tech support I can't believe how many people manage to 'infect' their systems with programs like Bonzi Buddy, Gator, and GoHip. Part of it is simply apathy; occasionally programs like Gator come as options with other apps, and from experience the casual user is terrified of ACTUALLY HAVING TO MAKE A CHOICE with their computer and accepts the default install options. Then there's the people who don't seem to realize that, when an installer for a program they don't need mysteriously pops up when they visit a site, they shouldn't install it. This is how viruses are spread... "but it was from someone I knew!"
The real kicker is that, at least once, I've actually had people blame these apps on the ISP I work for! Mind you, in the incident I'm thinking of (which only occurred last week) the customer assumed that paying for an ISP meant guaranteed technician visits for ANYTHING wrong with his service (even a five-minute "change your e-mail settings" problem) and had cancelled 3 prior ISPs to that effect, so I think it was more a question of his mental instability than any kind of major trend, but you get the idea of what kind of flak we can get at work...
Re:The Legality Of Spyware (Score:4, Informative)
First, the Latin word "virus" meant slimy liquid or offensive odor or taste. It was an abstract noun that didn't lend itself to pluralization, and in fact Latin had no plural for it. Modern languages have all invented their own plurals when "virus" entered their vocabulary: German, Viren, French and Italian, virus (they use the same word for singular and plural, like we use "deer").
Second, and most important, the OED gives only "viruses" as a proper plural for "virus."
More details on the etymology of "viruses" can be found here [perl.com].
Oh, and before you ask, it's "boxes" and not "boxen."
Thus endeth the lesson.
Linux reinstall Philosophy (Score:3, Informative)
The only real way to be sure you are free of viruses and trojans is to wipe the hard disk and reinstall your operating system and personal software.
With linux, it turns out to be simple to arrange things so that even with a lot of complicated, customized software installed on a machine, you can reformat your root partition, reinstall linux, and have your non-standard software installed and configured in under an hour. This makes it feasible to do every few weeks for your home computer.
The main reason is that most of the software configuration consists of ascii text files in
Keep your compiled software directories on a separate partition and write a script to descend into each of them and run a "make install". Then keep copies of all the
When it comes time to reinstall, reformat the root partition, reinstall linux, and then run your 2 scripts and you are back where you started, minus any viruses and trojans and exploits that managed to infest you since the last time you did this.
I wrote up an article with more detail on this on rootprompt at:
http://www.rootprompt.org/article.php3?article=
Re:This problem can be solved by... (Score:2, Informative)
Unfortunately, this won't work in Windows.
Example: you want to install a network print driver. Now, your driver needs to do a couple of things: copy itself (it's a dll) into the system directory to be loaded by the windows printing subsystem and create a bunch of registry keys the printing subsystem expects out of each "port monitor". It also needs to inform the printing subsystem to load your dll, either now (NT/2000) or after a reboot (9x). This is where it gets hairy.
The way this is done differs with every version of windows. To ameliorate the problem, MS has a win32 function that you call that does this semi-automatically (I forget what it's called, search MSDN Platform SDK for "install port monitor"). Your print driver won't work unless you call this function.
So, my basic point is that in order to install this software, you need the ability to call arbitrary functions with particular arguments. This basically means the install program must have a place where it runs an arbitrary bit of code written by the developer. You could also do whatever you like in that bit of code, such as uninstalling adaware.
I don't know about MS's new installation procedures, but I'd imagine they're pretty similar to what InstallShield does. The way InstallShield works is that you get this little GUI where you describe your app's files, registry settings, etc. From this, the InstallShield program generates a .ins file which is distributed with a more-or-less generic "setup.exe" program. The setup program also allows you to put in any code that you would like to run (the GUI has you do this in VB, but I believe you could also have it do it in C if you'd like - moot point, since you can do this stuff from VB as well as C). So, the existing installation procedures are something like what you describe except that the developer also gets to run a script of their choosing. In a way, you get the exact same capabilities as with RPM.
Now, you may say that this example is a bit unfair because this is really a device driver and you could say this "systems level" stuff is quite different from regular "application level" software.
Problem with that argument is that in Windows, there is no clear distinction between systems-level and application-level stuff. I'm a unix guy, and it's amazing how much stuff in Win32 is considered "systems level." I'd say almost any non-trivial win32 application would need to have a run of arbitrary code in the installer, whereas most RPMs don't need post-install or pre-install scripts. Underlying problem is that MS got a lot of abstractions wrong.