Legal Ethics and Open Source Software Security

The issue of security has long been a staple part of discussions about open source software. Writing in 2005 for CSO, an IDG Communications news website specializing in computer security, Simson Garfinkel challenges the "many eyes" argument of open source advocates (The Security of Open Source Software). Garfinkel notes that while in theory, vulnerabilities in open source are likelier to be found and corrected because many people will look for them, that doesn't always happen in practice. Sometimes, the people looking aren't well trained, or, worse, they are malefactors looking for flaws to exploit.

Some other common perceptions about open source software are discussed by Nick Heath in a 2013 article on ZDNet, a CBS B2B site focused on IT, Six open source security myths debunked - and eight real challenges to consider. The "many eyes" theory is one of the myths Heath refutes, but he also points out that as to whether open source is more secure than proprietary software, there's no real evidence either way.

More recently, Maria Korolov, also writing for CSO, discusses the extensive use of open source code by software developers, Open source software security challenges persist. In Korolov's view, the problem is not the security of open source software per se, but the lack of awareness of what applications include open source components. As a result, keeping up with security patches is difficult, to say the least.

Lawyer-Client Confidentiality

One software user community with particular concerns about security is the legal services industry. On one hand, email, word processing, cloud storage, and various other applications allow attorneys to be much more productive. At the same time, however, attorneys are bound by ethical rules regarding client confidentiality and privileged communication. One expert in legal ethics, Stuart Teicher, has gone so far as to say that lawyers should avoid open source software altogether: Open Source Software Could Be Off Limits To Lawyers. While there may be valid concerns about the security of open source software, many of the alarms sounded by Teicher are based on misconceptions or are otherwise unfounded.

Teicher begins his analysis with a review of the history of ethics rules relating to the use of email. After the Federal law against wiretapping was amended in the 90's to cover electronic communications, he notes, it became permissible for lawyers to communicate with clients with email. Even when free email services like gmail began scanning recipients' mail to select and display targeted advertising, state ethics authorities held that it was okay for lawyers to use such services. Since the scanning was done by computers and not by humans, they explained, there was no increased risk of others obtaining access to the e-mails' content.

The reasonable expectation of privacy standard that has guided the use of free email services for lawyer-client communication was recently updated by the American Bar Association Standing Committee On Ethics And Professional Responsibility. Formal Opinion 477R, Securing Communication of Protected Client Information was published in May 2017, coincidentally just months after Teicher's article. The update clarifies the connection between duties of client confidentiality and competent representation, which requires lawyers to keep abreast not only of relevant law but also of advances in law office technology that have become essential to almost every aspect of law practice. It is further recognized that lawyers who keep highly sensitive client information are likely to be targeted "by nefarious actors throughout the internet." Such information may require a higher degree of security than that afforded by unencrypted email. It should be clear, however, that avoiding open source software altogether, were it even possible, would not provide greater security.

Objections To Open Source

In making his case against open source, Teicher focuses on one of its essential features. While it is true that "the characteristic that makes open source software 'open' is that any programmer could change the source code," it doesn't follow, as Teicher suggests, that rogue programmers can insert malicious code willy-nilly into any and all open source applications. Open source is, by nearly any measure, far more prevalent on the web than proprietary, closed source software. Mr. Teicher's website is a good example, built with Wordpress (an open source content management system), itself written in PHP (an open source programming language), and typically run on Apache (an open source web server) with MySQL or MariaDB (both open source RDBMS's) as the back end database, all running on a Linux (open source operating system) server.

Teicher argues that quality control measures and supervisory procedures of commercial firms justify the expectation that their software does not contain some form of spyware. The point is well taken if you're comparing quality control by a large company having a vested interest in maintaining its reputation for reliable software with, say, an individual developer who sells apps on the Chrome Web Store. Not so, however, in the case of Wordpress or PHP or Apache or any of the other open source systems that much of the Internet and the World Wide Web depend on. All of these systems are backed by well defined standards and mechanisms for continuing maintenance and development.

It's also worth pointing out that intentional insertion of malicious code into a program as it is originally distributed isn't the only way privacy may be compromised. Security flaws or vulnerabilities in software are more likely to result from logic errors, or "bugs" in common parlance. (Teicher refers in his article to "web bugs" but "spyware" would be a more appropriate term for his intended meaning. A web bug, or web beacon, does not contain code. It is used to track visitors to a web page or to verify whether email has been opened by the recipient.) A common error in software might be failure to check an input buffer, for example a name or email address field on a form, to make sure the user doesn't enter more characters than allowed. A malicious user could enter a very long "name" that overflowed the memory buffer and replaced the original code in the memory past the buffer with spyware. Granted, it should be easier to figure out how to do this with open source, but the malicious user would need to craft the input and find victims before those victims applied a security patch.

Making Open Source More Secure

The concern Teicher expresses, that peer pressure to uphold ethical standards in the open source developer community has no formal enforcement, would be valid if that were the only quality control measure applied to open source software. It is not. Indeed, far more significant than the fact that anyone can change the code is that anyone can examine the code. For just that reason, as noted above, there's been a long running debate as to whether open source is actually more secure than closed source. I find it interesting that Teicher did not mention the Heartbleed bug as evidence that open source cannot be relied on to be secure. Some open source advocates credit the open source community for finding the Heartbleed bug, but it's also true that it went undiscovered for a couple of years following its release. Even if the programmers who wrote the original code with the Heartbleed bug were considered unethical for failing to test their work more thoroughly, it doesn't mean they acted maliciously, and it certainly doesn't follow that proprietary software production is immune from such errors.

Heartbleed focused attention on the extent to which our entire technology infrastructure depends, either directly or indirectly, on open source software. In response to Heartbleed, several leading tech firms formed a coalition to fund open source projects deemed critical to that software infrastructure. The message here is that the makers of "corporate-purchased software" have fully embraced and acknowledged their dependence on open source, and they are directing their resources to insure its quality and reliability. Emblematic of this trend is the recent decision by IBM to acquire Red Hat, one of the largest distributors of open source software.

Teicher correctly advises that lawyers need not avoid all open source applications, "just the sketchy ones." If security is a concern, though, it doesn't matter whether it's open or closed source-- "corporate-purchased software" is just as likely to be "sketchy" as open source software. Whatever faith one might have in their quality control measures and supervisory procedures, the way large IT firms deal with user privacy should hardly instill confidence in their ethical standards. That's a lesson we should have learned long ago in the wake of the Sony rootkit scandal.