Gatekeeping Out of the Box

1. It is ironic that scientists studying the voting problems raised in the Florida polls say that the old ways of paper ballots and lever machines give more accurate accounts than punch cards or electronic devices.[1] A study analyzing those problems says that part of the difficulty may lie in voters’ lack of familiarity with new technologies. This article addresses a similar issue at the crossroads of law, technology, and science pertaining to standards, reliability, and evidentiary thresholds of proof: digital evidence and the software from which it is generated. Whether or not a vote gets counted or a piece of digital evidence is admitted depends on the standards that are applied to the respective processes. Ultimately it is not the technology itself, but rather the human understanding of its function and capabilities, that paints the picture of truth.

2. Just as transparency in the voting scheme and certification steeped in authority go far in resolving allegations of computer glitches, human error, or mischief at the polls, Open Source software may provide a basis for adjudging the reliability of computer experts and programs that promise to be principal sources of evidence in resolving disputes within our technology-dependent society.

3. Likewise, just as the focus of poll reform is to establish standards that will prevent the reoccurrence of the recent assault on the process, Open Source software can help anticipate legal challenges that will confront digital evidence, and enable a methodology to assess the credibility of attacks against it.

4. Digital evidence has yet to attain widespread smoking gun status. When used to prove claims, it is often a piece or two in the overall puzzle, and questions of its reliability can be quashed by assembling multiple streams of corroborating evidence. Indeed, the implementation of software reliability in industry is dubious at best, and even less clear in the context of the courtroom, where few decisions have squarely addressed more than a cursory evaluation of software reliability. Whether this dearth of judgments can be attributed in part to lack of challenges to the technology that produces digital evidence remains unclear, as there have not been many cases on point to establish precedent. The ubiquity of computer technology that permeates modern society, however, promises to make computer-derived evidence a digital eyewitness. Its reliability must , therefore, be scrutinized in accordance with legal protections.

5. This article examines digital evidence reliability by first identifying and differentiating the two competing categories of software from which this evidence is derived: proprietary and Open Source. The next section explores the standards for software reliability in both the industrial marketplace and the legal arena. Specifically, the current standards are addressed in light of their value to industry and the law, as well as their respective historical origins This sets the stage for a reconciliation of standards for reliability as between industry and the courtroom. An outline of the legal approaches to reconciling digital evidence standards and the ensuing dangers of failing to scrutinize the source of the evidence supports the conclusion that the reliability of some digital evidence is not being properly addressed. Finally, this article will advocate the merits of Open Source software as a solution that facilitates the application of appropriate legal standards to novel evidence and helps bridge the gap between the law and industry in measuring reliability.

II. A Software Primer
A. Software Reliability – An Introduction to the Issue

6. Why should the reliability of software be a concern to industry and the law collectively? There is a growing tension between the need to present probative and visual evidence of digital disputes and the legal standards for the admissibility of scientific and technical evidence.[2] In other words, the ubiquity of computer technology and pervasiveness of data derived therefrom bear a direct relation to software. Since software provides the functional link between man and machine, unreliable software is sure to have an effect on any activity within the realm of everyday communications, transportation, and even survival within a tightly coupled, high-tech society.[3] The industry that both spawns and is aggrieved by symptoms of unreliable software also drives this issue into the legal arena, where the resolution of many disputes ought to be incumbent upon the reliability of the digital evidence derived from such software. Software reliability, therefore, has immediate and profound meaning in both industry and the courtroom.

7. The mention of digital evidence conjures up thoughts of crime scenes, computer cops, and monomaniacal digital bandits – the stuff of “Mission Impossible,” handled by the likes of “techies” named Morpheus, and far removed from the concern of Jane Q. Public. In reality, however, digital evidence is not just a byproduct of computer hacker incidents, but is present in virtually any dispute where there exist data relevant to a civil claim or crime. Like other forms of evidence – hair, blood, eyewitness accounts, or paper documents – its form, prevalence, and existence help clarify competing stories about the reenactment of an event. Furthermore, the reliability of both the physical and digital evidence can be scrutinized by examining the forensic science involved in its identification, collection, preservation, and analysis.

8. Unlike other forms of evidence where the source is not called into question, however, the reliability of digital evidence hinges on the source being somewhat reliable. That source is the software that generates, processes, and stores data. With blood evidence, for example, we do not question whether Jack Doe’s body reliably produces the DNA found in the blood. Either we can DNA-type the blood, or we cannot, and unreliable forensics will not change Jack’s DNA into Jill's DNA. With digital evidence, on the other hand, not only will unreliable forensics change the identifying, correlative, and corroborative properties of such evidence, but unreliable software is also capable of maligning the very data upon which a dispute is based or resolved, regardless of exemplary forensic practices.

9. Thus, the reliability of software within industry has sobering ramifications for a legal system that requires similar assurances from its evidentiary offers of proof. If industry cannot rely on or has no way of determining whether a piece of software does only what it purports to do, how can courts settle conflicting accounts arising from or backed by this software? One logical conclusion is that the challenge of judging fact from falsehood in litigating disputes will take on the characteristics of an historical fiction novel, albeit one in which discerning truth would be more a function of the attorney’s or author’s persuasive style than of reference to irrefutable historical records.

10. Regardless of whether reliable software has a profit margin, the omnipresent evidence created by software, the relevance of this digital data in virtually every type of legal dispute, and the legal principles governing the admissibility of evidence are subtly affecting industry’s need to develop reliability software. How this can be actualized in an industry where software has been and continues to be developed with reliability as an afterthought is where the Open Source model of software development may be useful. This is because the propagation of Open Source software in industry is fueled by the desire for reliable software, which is measured by standards and principles similar to those courts use to determine evidentiary reliability - empirical testing, subjection to peer review and publication, determination of error rate, and general acceptance within the relevant community.

B. Distinguishing Open Source Versus Proprietary Software

11. It is important at the outset to identify and differentiate between the two competing categories of software from which digital evidence is derived: proprietary and Open Source. This process is significant because judicial recognition that any “computer-generated” evidence be a product of a “standard” computer program or system in order to gain admission has migrated to issues surrounding software.[4] Furthermore, the distinction is crucial to understanding the nature of the issues involving the reliability of digital evidence, as well as to appreciating the solution offered herein.

12. “Standard” computer technology, so far as software is concerned, inexorably refers to COTS (Commercial Off-The-Shelf) products, which are publicly available, ready-made software that can be purchased from a manufacturer.[5] Examples include Microsoft Office, Network Solutions' Check Point RealSecure IDS, Lotus Notes, MacIntosh Operating System, Computer Associates' Inoculate IT, and Norton Anti-virus. The pertinent characteristic of this “standard” software is that it is proprietary, meaning that its underlying source code is not freely available to be viewed or changed.

13. In contrast, the features characterizing “nonstandard” software – customizable, able to be manipulated, not necessarily commercially marketed – typify Open Source software. Open access to a computer program's source code is the central defining point for Open Source software, as well as what primarily distinguishes it from proprietary programs. Some prominent examples include RedHat Linux, BIND, and Apache web server software. [6] Open Source is used to describe the conditions under which software source code used by computers is made available to others apart from the developer.[7] Reliability is a significant motivation behind the Open Source movement. This is effectuated by making the code available over the Internet for extensive testing and widespread review to find faults, as well as to catalog responsive code changes, and to maintain concurrent quality control. The software code or some subset can be integrated, packaged, branded, and sold by a developer to customers.[8]

14. Proprietary software is often referred to as a “black box” because, without access to the source code, one can only conjecture as to what happens between the data input and data output stages (except, of course, for the programmer and manufacturer). Without access to these “blueprints ” a computer professional is left to infer, based on his knowledge and experience, the causes of and solutions to software problems. Open source software demystifies many of these problems by exposing the source code to the public arena. In this way, those with programming skills can “see” what the software is really doing, diagnose problems, and substantiate predicted results of future occurrences.

15. The exercise of distinguishing between proprietary and Open Source software for the purposes of evidentiary implications is not intended to paint the former as “bad” and the latter as “good.” Nor does the proposed judicial utility of Open Source software preclude economic entitlement, intellectual property protection or technological advancement.[9] Rather, it is intended to stimulate critical analysis of how the legal challenges confronting digital evidence can be overcome by embracing new concepts that comport with evidentiary jurisprudence.

III. Reliability Standards for Software

A. The Importance of Standards to the Law and Industry

16. Why is it judicially rational to recognize Open Source software as a mechanism to foster reliability standards for digital evidence? To begin, a standard is any set of conditions that describes a desired or ideal state of something and that can be used to describe or evaluate actual examples of this thing.[10] In the context of software and evidence, standards are one response to the difficulties of evaluating reliability and of mitigating the troubles that accompany imperfect information.[11] Our legal system is guided by notions of reasonableness and judged by objective standards representing society’s values. Yet, despite the fact that software is the interface between humans and the machines that permeate modern life, there is no agreement on “specific” processes or standards regarding the reliability of software systems.[12]

17. To be sure, there are numerous technical standards being developed for the world wide web, e-commerce and the Internet that have addressed reliability indirectly by focusing on security.[13] History, however, suggests that whenever a major technology or industry has proliferated sufficiently to affect society at large, some measure of social control has followed.[14] This trend has resulted in public health, safety and environmental needs being addressed by laws that incorporate industry-born technical standards by encouraging reliance on them or by adopting those standards by reference.[15] Nevertheless, there is no software Underwriters Laboratory to denote third party certification of reliability; nor is there a software equivalent to the National Electrical Code to provide a common framework from which reliability determinations can be spawned and infused into local codes. Perhaps the closest attempt to duplicate such standards in the software industry has been declared “dead.”[16]

18. To illustrate this point, one relevant study found 250 different standards applying to the engineering of software, yet observed that these were essentially ineffective, and concluded that software technology was too immature to standardize.[17] Regardless of whether this reasoning holds true at present, the fact remains that software continues to be developed within an alphabet soup of standards. Thus far, many standards that do exist are aimed at promoting interoperability. For example, the well-established “syslog” protocol that allows machines to send event notification messages across Internet Protocol (IP) networks to a central server has become the de facto standard for logging system events.[18] The scalability and flexibility that allow for interoperability between various applications and operating systems, however, are often achieved by sacrificing reliability.[19]

19. The legal implications of this discordance of standards in industry are far-reaching. On one level, the utility derived from having standards is comparable between the judicial and industrial arenas. Standards help simplify the decision-making process for determining reliability. In the context of determining the admissibility of evidence, they act as a measuring stick for judges and juries; whereas in industry, they influence the sale of goods for those who are shopping for reliability. Further, standards assuage decision-making for producers of reliability–whether they be developers and vendors in industry, or computer forensics professionals–by narrowing choices.[20]

20. Related to this decision-making streamlining is the added benefit of third party validation, which is aimed at providing objectivity and independent assurances. Although the software industry is riddled with authoritative groups like the federal government and independent standards-setting organizations (e.g., IETF, NIST, IISP, ANSI, FIPS[21]), the lack of consensus among this amalgamation has not eased decision-making regarding software reliability. Translated into the courtroom, the law finds no clear authority with which to resolve the issue of “circumstantial guarantees of trustworthiness” of evidence derived from such software.

21. Another benefit of accruing standards of reliability for software is grounded in self-perpetuation. The existence of standards invites scrutiny that serves as a check on flaws and accentuates unreliable factors. The underlying rationale is that reliability is enhanced as an end result.[22]

22. Most significantly, standards bear directly on the interplay between industry and the legal system. Insofar as the existence of and adherence to software standards can provide protection from legal liability and facilitate claim settlements, the lack of standards can produce the opposite effect. For instance, a legal system bombarded by and ill-equipped to handle issues involving the disputed validity of software-derived evidence (including creation, identification, collection, preservation, and analysis) could result in the admission of evidence the foundation for which is unreliable; the exclusion of digital data that is vital to a claim at hand; the necessity for government regulation to provide clarity; and/or a disincentive to litigate disputes due to tremendous case backlog or, in the best case scenario, escalating pay-to-prove expenses.

1. Industry Standards for Reliable Software

23. In order to grasp how the Open Source model can facilitate reliability determinations of digital data within legal standards, it is necessary to understand how industry values and measures software reliability under proprietary models. To begin, software’s historical origins, both economic and technical, gave rise to the current disconnect between proprietary software and reliability.

a) History and Origin

24. Drawing on the metaphor that organisms are a product of their environment,[23] software[24] reflects the values of its originating environment and the motivations driving its current distribution. Specifically, reliability was not a consideration shaping early software development in the personal computer (PC) environment. This era was characterized by isolated desktops wherein software failures had no way of propagating to other machines, and data had not yet attained its current lifeblood status. Also, errors and malfunctions were an accepted part of the organizational and programming culture, where notions of computer security and intrusions were embryonic. This acceptance was illustrated by wholesale abdication of responsibility by software developers, represented by shrinkwrap licensing.[25]

25. In addition, the economic breeding ground for software was not conducive for dissatisfied customers to leverage financial influence upon vendors and developers. This climate resulted, in part, because software could be bought separate from the computer, unlike with its mainframe predecessors. Further, when personal computer (PC) popularity ignited, market share became the key to corporate success and personal financial gain. Market share bore a direct relation to market entry and increased features. Thus, reliability of software became the bastard stepchild to the motivations shaping market share – reduced time spent on testing, and features du jour.[26]

b) Software Reliability Standards at Present

26. Against this backdrop of software being developed largely irrespective of reliability, we arrive at the current divergence of standards and dearth of incentives to invest in reliable software. On one hand, lack of accountability in the software industry is a disincentive to producing reliable software. Imagine a society where doctors could use newfangled procedures to treat patients, yet were unencumbered by malpractice liability if someone lost the use of a kidney or reared a child with only one ear. In fact, the computer industry is no stranger to instances of software exposing personal banking records, causing the demise of entire networks, and even facilitating physical harm – oftentimes without matching repercussions upon the developers.[27] Society has become desensitized to the panoply of deficiencies in some software such that customers have become unwitting crash test dummies in the product development cycle.[28]

27. In a sense, reliability can be inferred when a party is held responsible if someone/something is not what it claims to be. A doctor’s professional vows and integrity, backed by insurance and certifying authorities, provide some objective criteria for gauging reliability in the medical arena. Ultimately, litigation ensures that these measurements are not toothless. This is in stark contrast to the software industry, where developers are motivated by market pressures that traditionally have neither embraced reliability nor penalized unreliability.[29]

28. Indeed, the market does not reward reliable software, at least as far as the shortsighted definition of reliability paints it as an impediment to improved functionality, features, and speed. The costs of improving reliability boil down to the production costs of integration and testing.[30] Apparently a piece of software with quick time-to-market, a fancy user interface, and code reminiscent of Swiss cheese is more valuable than one that has undergone significantly more quality control testing to ensure that the hack-of-the-week does not shut down a system.

29. This distills another disincentive to invest in reliable software, one rooted in the lack of a widely recognized and measurable definition of reliability. Despite the fact that software customers (read: everyone) are steered by concerns for functionality, consumer choices are at some level based on reliability. For instance, Jack Consumer generally seeks products that are sold widely or by a familiar vendor. In this way there is a propagation of this perception of reliability. This purchasing and production of reliability, however, is occurring within a context of imperfect information.[31] The lack of both agreed upon standards to test reliability and a recognized body to conduct assessments has led to a distortion in the mass consumer market of what reliability means. This deficiency has provided fertile ground for the proliferation of software that addresses well-known, visible, and publicized problems based on maligned information.

30. Apart from the social misconception of reliable software, what does software reliability mean to computer industry professionals? Accepting that there are various ways to describe these attributes, reliable software can be characterized by most, if not all, of the following attributes: authenticity (that the data came from or is what it purports to be, and that the software performs as described); integrity (that the data is accurate); availability (that the data is accessible, and that the software does not fail or cause other components to fail); and supportability (that the software has dependable, strong, available support--especially in a production environment).[32] This high-level definition is important in assessing how industry criteria square with legal standards for the reliability of evidence, and ultimately, how the Open Source model may facilitate proper analysis of evidence derived from software.

2. Legal Standards for Reliability

31. A basic legal tenet governing the admission of evidence is that it must be relevant, competent, and material to the case at hand. For evidence that is scientific, technical or of a specialized nature, the Federal Rules of Evidence and case law provide standards used by trial courts to determine if such evidence gets admitted.

32. The foremost case establishing guidelines for evidentiary reliability was Daubert v. Merrell Dow Pharmaceuticals in 1993.[33] Daubert involved challenges to the admission of scientific evidence, and aimed to bring clarity to the reliability requirements enunciated in the Federal Rules of Evidence.[34] The guidelines established in Daubert require trial courts to consider the following factors in their role as gatekeepers of admissibility:

· Has the scientific theory or technique been empirically tested; or, is it falsifiable?

· Has the theory or technique been subjected to peer review and publication?

· What is the known or potential error rate?

· Is the theory or technique generally accepted within the relevant scientific community?[35]

33. These criteria are the Court’s attempt to meet the “standard of evidentiary reliability” by ensuring that technical evidence is grounded in knowledge derived from the methods and procedures of science. By tying the validity of the knowledge to the underlying scientific methodology, the Court defines reliability as something that can be validated by testing and supported by more than subjective beliefs or unsupported speculation.[36]

34. Kumho Tire v. Carmichael extended the Daubert guidelines to nonscientific evidence. It gives trial judges the discretion, based on the facts of the case, to determine which Daubert criteria should be applied to determine reliability, as well as whether those criteria are satisfied.[37] The Court interpreted the reliability requirement of Federal Rule of Evidence 702 to apply to the word “knowledge,” not to “scientific, technical or other specialized.”[38] In other words, expert testimony can be based on no scientific knowledge in a particular field in order to meet the standard of evidentiary reliability.

35. At first glance, this ruling appears valuable to elucidating standards of reliability for nonscientific evidence. The Court assumes, however, that the four factors devised to measure the reliability of scientific evidence can be applied just as effectively to evaluate technical or specialized evidence. That is to say, the use of scientific methodology to gauge the reliability of scientific knowledge[39] (validation through testing) is the same criterion courts may use to adjudge, for instance, reliability of technical knowledge. If knowledge is based on experience or subjective interpretations that are not susceptible to validation through testing, those factors do not provide assistance in evaluating the reliability of that knowledge.[40]

36. Indeed, trial judges are not required to use all of the Daubert factors, but may consider them based on the circumstances of a particular case.[41] This flexibility is no less troublesome since it purportedly brings the issue full circle: trial judges are tasked with gatekeeping the reliability of nonscientific expert testimony, but are left alone to choose which keys will open the lock. This has set the stage for continuing controversy and lack of consistency among jurisdictions in developing and applying standards for admitting nonscientific evidence.[42]

37. A judge’s handling of novel scientific evidence, for example, is made easier when the underlying knowledge can be readily mapped against the Daubert criteria, as is often the case with knowledge rooted in academic or laboratory settings. Whereas, technical knowledge that may accompany the introduction of some forms of digital evidence, generally represents complex and uncharted territory for judges. Coupled with the fact that the claimed expertise may have evolved from an experience-based body of knowledge (i.e. computer forensics, intrusion detection, computer security), the discretion to allow such technical evidence to go before a jury is less predictable.

B. Reconciling Industry and Legal Standards for Reliability

38. How does the admissibility of software-derived evidence square with (1) the lack of industry standards for software reliability coupled with (2) unclear legal standards for the reliability of computer-derived evidence?

1. Presumption of Reliability Afforded by Courts?

39. It is not an overstatement to say that digital evidence may carry an aura of infallibility in the public’s eyes, a fact that may facilitate settlements and discourage technical challenges during litigation. Computer technology is afforded a presumption of reliability because there is a common belief that machines are immune to human frailties, desires, and whims that can lead to erroneous information or misinterpretation.[43] The dangers of placing such unbridled faith in automated systems without appropriate checks, however, are a no less serious matter, as illustrated both within and outside legal contexts.[44]

40. Just as the degree of proof necessary to support a chain of custody depends on the nature of the proffered evidence, the mutability of digital evidence makes its digital pathways important in establishing reliability.[45] This approach contrasts with that used to analyze a 19th Century ruby-crested urn that has visibly unique characteristics that are resistant to change, thus making such strict determinations of reliability unnecessary.[46] Similarly, the strictness with which the reliability requirement is applied to software-derived evidence should rest on the importance of the evidence and the extent to which its probative value depends on its accurate and unchanged condition.

41. Indeed, the familiar and neat package in which software can display data and the complexities of examining what happens to digital evidence from creation through end product mean that a more watchful eye and steady gavel are needed. The myriad of possibilities contributing to an undetected error in computer-derived evidence includes: errors introduced at one or more of several processing stages; software programmed with errors, programmed to permit errors to go undetected, or programmed to introduce errors into the data; or data rendered inaccurate or biased.[47]

2. Judicial Approaches to Reconciling Reliability of Digital Evidence

42. In order to answer the aforementioned question of squaring admissibility with reliability, an assessment of the threshold of scrutiny for computer-derived evidence is needed. The majority of relevant evidentiary challenges have addressed: (a) the authenticity of the evidence; (b) hearsay rule violations and satisfaction of the Business Records Exception; and, (c) the propriety of admitting computer-derived evidence as demonstrative rather than substantive evidence. This is the framework within which judicial discretion has been exercised to control the admission of computer-derived evidence and establish the appropriate standard for evaluating computer-derived evidence.

Whether or not these thresholds are appropriate for determining the reliability of the underlying software is an important question to which officers of the court should demand a clear answer. Whereas courts are generally aware of the reliability concerns attendant on digital evidence, there have been no reported decisions that squarely address Daubert challenges to proprietary commercial software. Reliability determinations have thus far been made indirectly by inquiring, most notably, about the mechanical operation of computer hardware, the accuracy of the human involvement in the data handled by the computer, the commercial availability and use of the program, and the proponent’s familiarity with the software. The standards mandated by Daubert, Kumho, and Federal Rule of Evidence 702, however, demand inquiry into the validity of the scientific theory behind both the specific software technique and the application of those techniques encoded in the software. A more direct and less circumstantial satisfaction of proof calls for analysis of the source code, which is the direct blueprint for a particular piece of software. The proprietary nature of commercial software, however, impedes application of this standard by spurning access to the source code. This has impeded courts from pursuing the easy question, “How reliable is the source code,” and facilitated lower thresholds of scrutiny that seek to prove reliability in circuitous ways.

a) Authenticity Analysis

44. Evidence can be admitted by a judge upon the showing of a proper foundation that often entails the establishment of its authenticity and reliability. These preliminary determinations can occur under the auspices of Federal Rule of Evidence 901’s requirement that the matter in question is what it is claimed to be, or via the more demanding showing of reliability addressed in F.R.E. 702. The purpose of this initial screening is to ensure that there is a modicum of reliability upon which a jury can then decide what weight that evidence should carry in resolving the issue at hand. The degree of scrutiny applied to determine whether or not computer-derived evidence goes to a jury is unsettled.

45. To date, computer-derived data have gained admission upon a foundational showing that the computer process or system produces accurate results when used and operated properly and that it was so employed when the evidence was generated. Federal Rule of Evidence 901 affords a presumption of authenticity to evidence such as x-rays, photographs, tape recordings, computer-generated records or scientific surveys produced by an automated process that is shown to render accurate results.[48] This presumption of reliability has been commonly extended to software performing data storage, collection or retrieval functions.[49] Consequently, a majority of the cases considering the admissibility of such evidence have done so in the context of computerized business records that are maintained or prepared by electronic computing equipment.[50]

46. A Texas appellate court, for instance, determined that the computer system that produced and displayed company payroll information, and upon which the expert’s testimony was based, was sufficiently authenticated under a state equivalent to F.R.E. 901(b)(9) and did not require an evidentiary hearing.[51] This decision was based on the prosecution’s introduction of evidence that the IBM System 38 computer and its programs were in proper working order when they produced the display, that they had done so in the past, and that the technology behind computer-generated displays was trustworthy, reliable, and standard to the computer industry. Further, the systems administrator testified about his years of experience in performing monthly tests on the payroll data system, and stated that the system and its monitoring programs were reliable.

47. The irony of this holding underscores the significance of examining the reliability of the software producing the digital evidence. The Defendant was being charged under a violation of the state penal code for harmful access to computer systems. It was alleged that he maliciously modified the source code to his employer’s network software to delete a series of computer files bearing critical company information. The defense challenged the reliability of the computer-generated display, which formed the basis of the systems administrator’s conclusion that the malicious code caused the deletion of about 160,000 records from payroll. By overruling the objection to the payroll display evidence, while simultaneously upholding Defendant’s conviction for manipulating the software that generated such evidence, the Court failed to consider that the software manipulated to produce aberrant results was the same software that was trusted to produce reliable evidence.

48. Authentication standards are meant to ensure that the evidence is what it purports to be, and how rigorous a foundation is needed to make this finding depends on the existence of something that can be tested.[52] This is primarily accomplished through the testimony of a witness who can speak to the identity and accuracy of the computer-derived evidence. The rationale is that the availability of a witness who can be cross-examined about the actual event and its link to the digital exhibit is a sufficient guarantee of authenticity.[53] In the context of photographs, for instance, a witness familiar with the picture need only attest that it is a “fair and accurate portrayal” of the scene.[54] Computer-derived evidence has been extended a similar presumption of authenticity by some courts, as long as a computer operator, who is familiar with the process undertaken by the software, testifies.[55]

49. The threshold for authenticating computer-derived evidence, however, is ambiguous. Some recommend a higher standard than that applied to photographs,[56] whereas others advocate giving judicial notice of the authenticity of computer-derived evidence under F.R.E. 901(b)(9), which governs authentication of evidence describing a process or system. One of the foremost cases in defining a standard demanded that the proponent of the evidence show the competency of the computer operator; the type of computer used and acceptance in the field as standard and efficient equipment; the procedure for input and output of information, including controls, tests and checks for accuracy and reliability; the mechanical operation of the machine; and the meaning of the records themselves.[57] This rigorous authentication requirement for computer-generated evidence, however, has been eschewed by most courts.[58]

b. The Hearsay Rule and the Business Record Exception

(i) An Analysis

50.