litsupport summary for the week ending on 9/21/08

A lot of important and useful information is posted to litsupport each week. However, this past week was very special. Probably due to the combination of double trouble, locally - hurricane Ike in Houston and in Texas, and globally - arguably the most serious economic crisis since the Great Depression, the group boasted precious few scientific and technical posts.

Instead, I decided to share my personal impressions of Ike in Houston. Life without electricity was not that bad. Here is a picture of me studying "Foundations of Digital Evidence," the review of which I will publish soon.

We were lucky to have a cold front to come at an unusual time, and precisely after the storm. I have grown accustomed to wait for the quiet evenings when everybody got around the table to read with the candles. Of course, laptop with wireless connection was our first priority, even if the car battery which charged it later had to be replaced.

People exhibited their best qualities. Everybody was very friendly and helpful. We felt all in the same boat with no power.

I also think that Houston got an unusual share of good luck. Papers were filled with photos of near misses. A tree almost hitting the house but not quite. A mother with the baby standing next to the house which the tree missed, hitting instead the toy house.

Many are still without power, going to work may take two hours, especially if you take the kids to a makeshift school at a new location. Many people on litsupport showed their support to friends and to all Houstonians, and this was very precious.

Best wishes to all.

Mark

This summary from the Litsupport Group postings created by the wonderful and talented members of the group has been culled by Mark Kerzner (mkerzner@top8.biz) and edited by Aline Bernstein (aline.bernstein@gmail.com).

litsupport summary for the week ending on 9/14/08

A lot of important and useful information is posted to litsupport each week. The following is a distilled summary, in the form of questions and answers.

Q. Is it really that bad in Houston after hurricane Ike?
A. Yes, pretty bad. Most people do not have power, streets are still being cleared from debris and broken glass, Galveston had it the worst, and rescue teams are still at work. However, the good side is that there are very few casualties. I am writing from a wireless laptop connected to my car power outlet.

Q. A What are the requirements for the business case to bring ESI processing in-house?
A. In addition to investigating the list of vendors (LAW, IPRO's e-Capture, Discovery Cracker, Extractiva, eDiscovery Tools, ImageMAKER Discovery Assistant) and their capabilities, one should also consider

1. Data! If you have a data set and an audit of each file this will help tremendously in evaluating any tool;
2. It will help to do some basic tests of a few programs on the market this year with your .PST sample set;
3. One industry consultant reports that the best score for the programs that he tested with his .PST set was 84%;
4. Some programs are unable to go unlimited nesting of attachments, read attachments and embedded items in Adobe 8 files and read container files within container files.

Q. Can a law firm require unlimited liability in agreements with 3rd party ESI vendors?
A. A few national law firms (AmLaw 50) have been demanding and getting agreements of unlimited liability. Those vendors signing have predominantly been smaller players so it does not mean much to the law firms. However, there has been one upper tier vendor that signed on for unlimited liability.

Q. What are the pros and cons of using XML to store and retrieve EDD information.
A. A complete discussion is found on litsupport here, but in brief it would depend on which kinds of EDD information, as below,

The PROS:
- XML can incur less overhead than a database, and may fetch relational data quicker;
- file-based - easy to relocate and move around;
- can be understood by any platform and language;
- well-formed XML stores relational and hierarchical data logically and
efficiently;
- smaller XML files can fit entirely into memory, and once there, can be
queried nearly instantaneously.

The CONS:
- Write-once, read-many - not for rapidly or frequently changing data;
- No ACID compliance (Atomic, Consistent, Isolated and Durable);
- XML prefers to be read end-to-end;
- XML is a single-threaded;
- XML is file-based rather than server-based;
- XML has no business logic or constraints.

More pros and cons can be advanced depending on the file system, server, and implementation.

This summary from the Litsupport Group postings created by the wonderful and talented members of the group has been culled by Mark Kerzner (mkerzner@top8.biz) and edited by Aline Bernstein (aline.bernstein@gmail.com).

litsupport summary for the week ending on 9/07/08

A lot of important and useful information is posted to litsupport each week. The following is a distilled summary, in the form of questions and answers.

Q. A solution to grab an entire website for display during trial without having Internet access?
A.

1. Adobe 8 has a webcapture function. For embedded flash videos one can keep a screenshot in the adobe pdf webcapture and then use the free open source CamStudio to record the audio and video right off the screen. It does loose a little resolution, but it is good enough for the purpose;
2. Save the embedded videos (directly from hosting website or using the stream capturing software) to your laptop local drive and fix the html links to point them. This may require editing the JavaScript;
3. HTTrack can collect the page or the site, Area Tube helps download videos from YouTube and MySpace;
4. Teleport;
5. wget (some programming in Perl or other language may be required);
6. Camtasia can create a movie of a site;
7. And in all these cases the authentication of the web site evidence is not obvious.
   

Q. Can we rely upon the log to identify the custodian of a document despite the location of the documents on a network share (either Home share or Departmental share)?
A. This approach is not defensible for many reasons:

1. One cannot rely on the metadata value in the file or from the backup software to determine the author of the document. A document can be authored by John, e-mailed to Jane, modified by Jane and forwarded to Ted, who saves it to his personal folder on his department's file server;
2. In a corporation, just with hires and fires over time one can not expect the log to be accurate - especially with unstructured data;
3. Most OS and user environments do not have reliable metadata.

A practical approach may be to first set acceptance criteria (i.e. what percentage error you are willing to tolerate) and then do a representative sample of known folders and check. If that field is consistent and matches to the known authors, document it and make sure that counsel understand and approve the methodology.

This summary from the Litsupport Group postings created by the wonderful and talented members of the group has been culled by Mark Kerzner (mkerzner@top8.biz) and edited by Aline Bernstein (aline.bernstein@gmail.com).

Old-School Attorneys Face E-Discovery of New World

Two years ago, Patrick McLaughlin used a Dictaphone when working on pleadings for his criminal cases. But times have changed for the assistant U.S. attorney, who has graduated from using the recording device – to dictating to his legal secretary.

“I never became comfortable with the idea of sitting down and typing out documents,” said McLaughlin, 58, who prosecutes drug traffickers and money launderers for the U.S. Attorney’s Office.

He’s one of many trial lawyers who started practicing before the Internet came into common use. They are now facing a changing legal landscape as technology takes a larger place in the world of law, specifically in the area of electronic discovery.

read complete story...

Did the opposing side hide some files?

In usual requests for production, you have to rely on the opposing party to follow the correct protocol and to produce all relevant ESI. To verify or challenge the protocol, you need to substantiate the claim, pointing out the ESI that has not been produced. But how can one point to the information if it has not been produced? We seem to have a vicious circle.

There is a way, however, and this way includes correctly crafted requests for metadata production. The request needs to be specific enough, so that it is not considered a fishing expedition. It has to be simple, so that it is not overburdensome. All this means that you have to do your home work with both the FRCP rules that apply and the technology that is relevant. This article from the Metropolitan Corporate Counsel explains how to ask for Windows metadata, such as registry and log files, in the proper way.

litsupport summary for the week ending on 8/31/08

A lot of important and useful information is posted to litsupport each week. The following is a distilled summary, in the form of questions and answers.

Q. Is there a simple way to have Microsoft Exchange Outlook to curtail, organize and push retention of email? For example, after the received date turns 90 plus days old - the application would push the question to purge the email, save, etc.
A. Outlook 2007 policy. Just change the Archive to delete. Not perfect or granular (i.e. folder dependent), but easy if you want everything over 90 days to go away. If you use a local PST for your 'permanent' records, it should work.


Q. Should one give a negative review of a vendor on the litsupport group?
A.
Yes. This is what the group is for, and users will not be swayed by the negative report one way or the other. Otherwise the group becomes a place for vendors to stroke each others' egos and gang up on anyone with an honest review. What else is one to do if one's job got messed up by a vendor?
No. Other vendors will not be willing to work with a firm that published a negative review, because they will be afraid of a scathing review of them; one might violate an NDA; quashing negative responses to anything is simply a natural response for some; private messages are very appropriate given that litsupport is a large group, and posting on it can mean loss of business and reputation to some firms; after all, problems happen.

This summary from the Litsupport Group postings created by the wonderful and talented members of the group has been culled by Mark Kerzner (mkerzner@top8.biz) and edited by Aline Bernstein (aline.bernstein@gmail.com).

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.