Earlier this week, Microsoft revealed that it has been going into users' computers and removing outdated Tor clients. At first glance, this might seem like a crazed, misplaced attack on the Tor network, not unlike a campaign by a certain Irish politician, but the issue runs deeper than first thought.

Editor's Note, January 24, 2014: According to a Microsoft spokesperson, "Microsoft Malware Protection Center (MMPC) has protections to remove the services started by the Sefnit malware, but it does not uninstall Tor, remove any Tor binaries, or prevent users from using Tor.”

The problem begins with the Sefnit botnet, which uses the Tor network to conduct its communications. Dealing with a botnet is a tough problem, despite how noisy they can be. Even when security researchers identify a machine that is compromised and they technically have the ability to control it themselves, cleansing an infection is wrought with legal and ethical dilemmas.

Why not instruct each individual bot to clean itself? It has been done before. The US Federal Bureau of Investigation trialled doing so with the Coreflood botnet, but, according to Trend Micro, 10 percent of zombies in its test environment crashed. Aside from now potentially breaking the law by accessing a computer without authorisation, the well-intending party could have just crashed someone's machine.

And who knows what that machine was used for. Perhaps it's some college student working on their term paper. Maybe it's a server responsible for managing a small city's traffic systems. What if it's someone's life support system?

Instead, researchers use a more indirect method of sinkholing botnets — law enforcement agencies ensure that DNS requests for known malicious servers that control botnets aren't returned with valid results, cutting them off from their masters. Similarly, the Australian-developed iCode seeks to place infected machines in a walled garden at the ISP level.

While these issues are an important step in the right direction against botnets, they are solutions that are only effective on a network they have control over. Due to how Tor's network works (and in this way provides anonymity), sinkholing is ineffective, and walled gardens are impossible.

Logically, Microsoft is right to go about tackling the problem at the application layer, with its tools removing the Sefnit botnet infection. Sefnit has no positive purpose, so ethically, this should be OK, and Microsoft's removal tool requires the customer's permission, addressing the legal implications.

The dilemma that remains unanswered, however, is what happens when non-malicious software is installed at the same time. Sefnit uses an older Tor client to communicate, and Tor, by itself, is not malicious.

The Tor client used by Sefnit is version 0.2.3.25, which Microsoft points out has several vulnerabilities, including two buffer overflows and a heap corruption flaw. These could likely be used to remotely execute arbitrary code, leaving the victim's machine open to attack even if Sefnit is removed.

The argument that Microsoft now essentially uses to justify its actions is that if this software, which cannot be automatically updated, opens the user to attack through known vulnerabilities, it too should be considered something that should be removed.

The Tor Project worked with Microsoft, permitting it to update its signatures to remove old versions of the Tor service. This effectively means that the Tor Project found it acceptable for its older software to be marked as malicious, but it also does not speak on behalf of its users.

Where everything comes undone is when Microsoft's argument is extended to beyond the botnet. If the argument that the risks of old, outdated software makes it OK to mark it as malicious, why should Microsoft stop there? Why do we need to wait for a botnet to be present before taking action? If another piece of software opens the user up to attack, isn't it, too, malicious by Microsoft's argument?

It would improve things for Adobe, which has seen a huge improvement in the later versions of its Reader software. Its newer releases use sandboxing, which have halted attacks, but the feature isn't included in its older versions, where it has the most trouble with reports of customers becoming victims.

The answer is in how valuable a piece of software is, even if it is full of vulnerabilities. Users continue to use Java because they have to for web conferences or even for gaming (Minecraft, anyone?). Microsoft makes this decision on behalf of the user, unfortunately, which means it does not address the ethical side. It's not long before someone questions how useful a piece of software really has to be before its security flaws make it a candidate for automatic removal.

If you don't believe me, wait and see what happens once Microsoft's long-term support for Windows XP runs out on April 8. I don't see it turning around, marking its own operating system as malicious, and uninstalling it for users' greater good.