Technology for Lawyers and Paralegals: Evidence Authentication - Web Site Content

Electronic evidence presents unique authentication challenges. What are the specific issues for web site contents?

Judge Grimm on Evidence

In his memorandum opinion in Lorraine v. Markel Am. Ins. Co., 241 F.R.D. 534 (D. Md. 2007), Magistrate Judge Grimm remarks that "considering the significant costs associated with discovery of ESI, it makes little sense to go to all the bother and expense to get electronic information only to have it excluded from evidence or rejected from consideration during summary judgment because the proponent cannot lay a sufficient foundation to get it admitted."

In this issue we investigate ways to authenticate and bring into evidence web site contents, and potentially challenge the same.


Laying foundation and challenging it

As Judge Grimm explains, whenever ESI is offered as evidence, the following evidence rules must be considered: (1) is the ESI relevant as determined by Rule 401 (does it have any tendency to make some fact that is of consequence to the litigation more or less probable than it otherwise would be); (2) if relevant under 401, is it authentic as required by Rule 901(a) (can the proponent show that the ESI is what it purports to be).

It is item (2) that poses most significant technological challenges. If an item of evidence can be easily forged by a lay person, a developer, or a hacker, it is inherently inadmissible, because it may not be what it purports to be.

Let us review some simple ways in which a web site content can be forged. The first way is explained in a PDF file which can be downloaded from here.

In short, one saves the real web site with the web browser "File-Save Page As" command. This creates a local copy of the page on one's hard drive. This local copy looks just like the original site, except that the URL indicates that it comes from the local hard drive. We then modify the content with the text editor, re-display it in the browser, but before printing the site we substitute the URL. This can be accomplished in under one minute and can turn a story of a happy marriage into a story of divorce.

This explains why a web site printout is inherently unreliable and can not be brought into evidence without additional effort. See St. Luke's Cataract & Laser Inst., P.A. v. Sanderson (M.D.Fla.,2006.Slip Copy) 2006 WL 1320242 where an affidavit from an Internet Archive representative with personal knowledge was required (but more on this later), and Telewizja Polska USA v. Echo Star Satellite Corp. 2004 U.S. Dist. Lexis 20845, 2004 WL 2367740 (N.D.Ill.)

As a next step, the attorney may try to bring a witness to authenticate the site content. This witness may be directed to type in the URL in the browser, then testify about what he has read. This approach, however, can be challenged on two points. Web sites today are dynamic, displaying different content to different users. Virus writers use this to hide malicious sites or valid sites which have been infected by them. Such sites display malicious contents to the user only once. Alternatively, the site may change the verbiage in a slight way in a matter of seconds, so that the witness can be challenged on the basis of his inability to correctly preserve every word of the page. If the witness saves the contents in a Word file, we face the problem of authenticating this Word file, which we discussed in another post.

Another attempt may be to subpoena the web site's administrator and make him testify about the site content. Again, this testimony is open to challenge. For one, hackers may get access to the site and modify it contents. To rebut this challenge, we would have to verify the site's defenses, which is not an easy task. Even if we succeed in reasonably proving that the site has not been hacked, there is another beast lying in wait: dynamic modification of site content, known technically as JavaScript DOM injection. This technique was recently used to infect more than 10,000 Italian web sites. Simply put, web sites do not only serve the contents of the web pages residing on the servers. In addition, web servers have cache, which can be modified to show words, links, and images never intended by their owners. In the attack mentioned above, Google search results would display the injected content, offering the users to click on the links leading to hackers' sites.

In addition, in the last example multiple users from many parts of the world were shown the content injected by hackers, for which the owners of the site could hardly be held responsible. Thus, testimony of multiple users from many places in the world would be of no avail.

Finally, let us analyze the conclusions of St. Luke's Cataract & Laser Inst., P.A. v. Sanderson (M.D.Fla.,2006.Slip Copy) 2006 WL 1320242. Here the court decided that websites are not self authenticating and therefore the court required a statement or affidavit from an Internet Archive representative with personal knowledge of the contents of the Internet Archive website.

Note that although the court found this sufficient in 2006, today it could have been open to challenge once again. If the sites can be statically or dynamically made to display any contents that the hacker wants, then the Internet Archive is irrelevant and the testimony of the representative testifying on how his system works does not help. He may know how his system works, but if the system can be easily duped, then his words do not help the problem at hand, that is, the authentication of the contents as the official point of view of the site owners.

Step by step approach

If all or most of the attempts to bring the web site contents into evidence based on technology can be challenged, do we have any way to use the web site content in trial? The answer is yes, and it is based on the combination of legal and technical knowledge which looks deeper into the web site development.

Let us first look at the means provided by the rules of evidence. As explained in Judge Grimm memorandum quoted above,

1. Authentication also can be accomplished in civil cases by taking advantage of FED. R. CIV. P. 36, which permits a party to request that his or her opponent admit the "genuineness of documents."
2. At a pretrial conference, pursuant to FED. R. CIV. P. 16(c)(3), a party may request that an opposing party agree to stipulate "regarding the authenticity of documents," and the court may take "appropriate action" regarding that request.
3. If a party properly makes his or her FED. R. CIV. P. 26(a)(3) pretrial disclosures of documents and exhibits, then the other side has fourteen days in which to file objections. Failure to do so waives all objections other than under Rules 402 or 403, unless the court excuses the waiver for good cause. This means that if the opposing party does not raise authenticity objections within the fourteen days, they are waived.

These were the ways of authentication for web site based on evidence rules, and they would apply to other kinds of evidence as well. It is time now to look at the specific ways for web sites.

Web sites do not exist in vacuum, and their contents, when published, is not pulled from thin air. Rather, it is kept on the web developer computer. Therefore, a discovery request to produce the development environment on the web developer is more germane and is closer to the source. The web developer machine is less likely to get hacked, because it is not directly accessible from the outside web. This answers the hacking challenge. It may also contain multiple copies of the contents, thus helping to establish the authenticity even further. Moreover, in today's development environment, it is often not one but multiple developers that are creating the contents. The production request against all of these computers will cross-confirm the contents.

Just as important, a production request aimed at the developer machines will turn up email communications between the developer and the management. After all, it is the management who is ultimately responsible for the web site pronouncements.

More often than not, the web site code is also stored in version control system, such as CVS, subversion, or SourceSafe. These systems are designed to keep every version of the files changed by developers, with the developer attribution, and often developer comment.

The requests discussed above should serve as a solid foundation to authenticate the web site content in question. The developer's machine containing email and instant messaging communications with the management will give additional insights into the reasons and timing/contents of the changes.

To summarize, a solid understanding of both the technical and the legal issues involved in web site development will help to lay proper foundation in getting the web site evidence admitted in court.

The author gratefully acknowledges the editing help and numerous suggestions of Kelvin Rocquemore, Esq., of Trial Solutions.

The author is also thankful to his colleagues at the litsupport discussion group, whose discussions provide him with much inspiration and knowledge.