Letter to the Editor(s) of The New York Times

By Lysandra Ohrstrom | January 22, 2010

New York Times reporters John Markoff and Ashlee Vance correctly pointed out that nations, private corporations, and even bands of rogue programmers are capable of covertly tunneling into information systems, by exploiting bugs in a program’s source code in their January 20th story, “Fearing Hackers Who Leave no Trace.”

Unfortunately, this paragraph appears more than half way through the story. Rather than address the real reasons that proprietary systems are so vulnerable to security breaches or the comparative protections afforded by free software, Vance and Markoff stuck to the usual formula of the Times’ technology stories: the “intellectual property” parable. The good guys (“innovative,” commercial technology companies like Google and Cisco) struggle to protect the integrity of their source code–their “crown jewels”–from the nefarious designs of the bad guys (hackers).

“If hackers could steal those key instructions and copy them, they could easily dull the company’s competitive edge in the marketplace,” Vance and Markoff write. “More insidiously, if attackers were able to make subtle, undetected changes to that code, they could essentially give themselves secret access to everything the company and its customers did with that software.”

The ability to make “subtle, undetected changes” to a system’s source code is indeed the cause of frequent security breaches, but it is much harder for ill-intentioned hackers to “leave no trace” in free software. The solution is not to block access to source code, as the authors imply, but keep it open so that anyone can detect modifications, see who made them, and why. The reason closed, proprietary systems have proven to be less secure than free software alternatives over the years is more to do with the absence of a third-party audit function and accountability trail, than threats from “hackers.”

Markoff and Vance conclude their story with a quote from a security expert who acknowledges that technology companies have implemented “more complex systems for viewing and changing source code” lately to combat this problem, but “one of the greatest vulnerabilities remains the people element.” Free software has proven that the people element can also be a source of security.

I can only assume the confusing tangle of inaccuracies, contradictory conclusions, and false assumptions Markoff and Vance reported were fed to them by a PR agent or cobbled together after a day-long conference hosted by the Homeland Security Council. Vance quotes a member of the Council’s advisory board, Jeff Moss, in the article he co-wrote with Markoff and in a separate story published under his own byline on January 21, “If your Password is 123456, Just Make It HackMe." Vance describes him as a security expert in the first story and the founder of a popular hackers conference in the second.

As a non-profit law firm for Free and Open Source Software programmers, the SFLC admittedly has a stake in promoting the projects developed by its clients. So rather than take my word for it, listen to the comments of readers like Wai Yip Tung from San Francisco. “This article have a very confused idea around source code and security,” Tung writes in a comment. “Have you ever heard of Open Source software? (e.g. Firefox) Everyone has access to its source code but it does not make it any less secure. In fact security expert have an opposite opinion. It is critical that source code is available for audit by a wide range of people before we can have confidence of its security. This is a worthless article in my opinion. It stroke fear in the wrong places and shed little light on where the vulnerability really is.

I have to disagree that their effort was entirely worthless. Markoff and Vance inadvertently ended up writing an unqualified endorsement of free software in The New York Times.

Clarification: The “hackers” who break into computers with the intent to cause harm are distinct from from the community of programmers who create clever solutions to bugs in source code. A more accurate label for the activity in this story is malicious hacking or cracking.

Please email any comments on this entry to

Other SFLC blog entries...