Ascending to the Cloud Creates Negligible E-discovery Risk

Cloud computing platforms (a set of pooled computing resources that are powered by software and delivered over the Web) have been generating quite a bit of press in the last year. Indeed, just recently computing giant Microsoft launched its Microsoft 365 cloud computing platform, designed to rival Google’s "mega-cloud" platform, which launched in May 2010. Since the release of the first commercial cloud computing platform by Amazon in 2006, cost-conscious companies have been racing to evaluate the pros and cons of moving their computing operations to “the cloud.” According to the Booz, Allen, Hamilton technology consulting firm, “Cloud computing may yield:

Life cycle costs that are 65 percent lower than current architectures

  • Benefit-cost ratios ranging from 5.7 to nearly 25
  • Payback on investments in three to four years."

Notably absent from that cost-benefit analysis, however, is the effect cloud computing may have on the costs and risks associated with conducting electronic discovery. Those engaged in such activities may well ask the question, “Will the savings companies expect from moving their data to the cloud be absorbed by the additional costs/risks created by conducting e-discovery in the cloud?”

The short answer is no. Although there are risks associated with conducting e-discovery from the cloud, they are remote, manageable and eclipsed by the savings companies should expect from cloud computing. Some of the riskiest aspects of conducting e-discovery in the cloud are:

  • The loss/alteration of data and associated metadata
  • The potential violation of international data privacy laws by illegally disclosing data in the jurisdiction in which the cloud is located
  • The unintentional waiver of the attorney-client privilege by co-mingling data or disclosing attorney client communications to third parties
  • The failure to properly and timely implement and monitor litigation holds

Fortunately, companies can easily manage the risk of altering metadata and the risk of violating international data privacy laws by insisting the service agreement with their cloud provider:

  • State that none of the company’s data may be stored outside the United States
  • Provide a detailed mechanism for how the cloud will implement litigation holds
  • Address how metadata will be created and stored in the cloud environment

Similarly, companies can minimize the risk of waiving the attorney-client privilege by including “no waiver” language in their cloud computing service agreements and establishing security protocols to prevent the inadvertent disclosure of communications to the administrators of the cloud or any other third party.

When the technology has improved and cloud computing administrators have developed expertise at responding to e-discovery requests, companies might even enjoy e-discovery cost savings by moving their data to the cloud. “If the cloud fulfills its promise and supplants the hodgepodge of local hard drives, LAN servers, and removable storage that now house our data, the cloud will emerge as the simpler, ‘one-stop shop’ for preservation and search in electronic discovery,” Craig Ball, an expert on trends in e-discovery, predicts.

In fact, that technology already has been developed and is in use for other applications. In late 2010, Facebook (currently the largest functioning equivalent to a cloud computing environment) added to its regular user interface a one-button preservation tool for capturing user content. Now, by simply clicking the “Download Your Information” button (and providing the appropriate password), Facebook users can request a neatly packaged zip file containing all of their videos, messages, wall posts, friend lists and other profile content — it doesn’t require a professional background in information systems to comprehend how similar technology can be applied to collect corporate data stored in the cloud.

Furthermore, cloud administrators saddled with the responsibility of responding to many subpoenas or production requests on behalf of myriad clients will, in time, develop an expertise in culling, processing and producing data. In turn, cloud users will undoubtedly benefit from advances in technology as well as the experience that cloud administrators have gained in responding to e-discovery requests.

The hope is that these efficiencies will translate directly to the end-user. At the end of the day, in-house counsel should be confident that (if managed properly) the benefit of moving a company’s data to the cloud outweighs the risks and costs associated with producing data from the cloud as part of a lawsuit.

                                       *                                                   *                                                *

This article was originally published by Steven Hunter, a Quarles & Brady partner, in Inside Counsel.

Google Docs Ready for (Legal) Primetime?

Today's predominant word processors are Microsoft Word and Corel WordPerfect. MS Word is also offered as a web-based application or Saas (Software-as-a-Service).  However, there is a newer type of document collaboration, where numerous people have access to the same document so that they can all contribute and monitor changes made by others.  These types of applications are becoming more common.  For example, Google has begun to offer its own Google Word Processor called "Google Docs" -- which allows users to share and collaborate on documents. 

What does it matter which type you use in your business?  Here's one comparison between the Google and Microsoft web products.  But there's much more when it comes to the battle between WORD v. GOOGLE DOCS.

Sass and Microsoft Word.  SaaS, which Word uses, is really a form of cloud computing, or internet-based computing. Applications such as a word processor is accessed via the Internet, and the resulting data created by the user (documents) is stored on servers managed by particular service providers. This form of service delivery has a siginificant advantage over "localized" computing from a cost and management standpoint.  For example:

  • By paying a SaaS provider to run applications and store documents, businesses no longer have the need to purchase/upgrade their word processing software.
  • It reduces and/or allows the redeployment of hardware (servers) used to store documents.
  • Applications can be accessed anywhere, anytime as long as the user has Internet access.
  • For remote users, an iPhone, iPad, Blackberry, or other Android-powered phones can be used to access documents, and there is no need to login to an internal network using software such as Citrix or any flavors of VDI.
  • SaaS providers typically guarantee 24/7 access due to elaborate network redunduncies.
  • Fewer or no technical staff is needed to manage software and handle storage issues.  This frees them up for other tasks.

Google DocsDepending on your perspective, Google Docs could be a blessing or a curse. Documents created by Google Docs are devoid of metadata. This means that no document scrubbing (e.g., iScrub) is needed before they're being sent to a recipient. There is no chance of inadvertently disclosing confidential information.  Additionally, numerous people can be in the document at one time, make changes, and monitor the changes others are making.  This can work wonders for collaboration.  Unfortunately, there are some down sides for Google Docs:

  • Google Docs tracks all document edits in the form of a "revision history" trail that cannot be eliminated by the user. This same trail could potentially be subpoenaed by the courts for e-discovery purposes.  Google Docs, and Gmail, stores everything. 
  • Google Docs exists as an independent product from Document Management Systems (DMS). As a result, it cannot be integrated with an in-house DMS or part of a company's overall enterprise content management (ECM) strategy.  In other words, you can't develop a record retention policy that can be followed with these documents. 
  • The document versioning method is quite different. For example, a particular MS Word document in a DMS such as iManage will present itself as "document_number.1" and a new version is saved as "document_number.2". The same document created in Google Docs will present itself as two separate entries in the "revision history". Hence, a Google Docs document would be saved as "document_name" and a new version would be saved as a separate document but renamed as "document_name_revised".  As a result, there is no easy way to move all the separate entries into a DMS as a single document with different versions.

Google Docs may be more appealing to smaller businesses that do not want to worry about internal networks and in-house DMS issues.  But large or small, whether Google Docs is a feasible solution depends on your business infrastructure, records compliance requirements, and the resources available to manage it.  Before taking the plunge, consult with Google, your legal department, and perhaps your existing e-discovery vendor on how Google handles litigation holds and document search and retrieval in e-discovery situations.

Regardless of its short-comings, Google Docs could be a solution for certain businesses that don't require a DMS and the main focus is document collaboration without overburdening the IT staff.

Arizona Supremes: Metadata Subject to Public Records Law

Arizona is suddenly on the cutting edge of e-discovery law, with a new decision from the state's supreme court. 

In what freedom-of-information advocates hailed as a groundbreaking victory, the Arizona high court held Thursday that when a public entity maintains a public record in electronic format, any attached metadata also constitutes a public record subject to disclosure.

Writing for the unanimous Court, Justice Scott Bales stated that "[i]t would be illogical, and contrary to the policy of openness underlying the public records laws, to conclude that public entities can withhold information embedded in an electronic document, such as the date of creation, while they would be required to produce the same information if it were written manually on a paper public record."

The issue arose when a recently-demoted Phoenix police officer filed an administrative complaint and a federal lawsuit alleging employment discrimination.  In connection with the litigation, the officer also submitted a public records request to the City of Phoenix, seeking notes that his supervisor made that were kept in his personnel file.  After the City produced the notes in paper copy, the officer came to suspect that the notes, which had been created on a computer, had been backdated.  He sought production of the associated metadata so that he could determine when the document at issue was created or modified and by whom.  The City of Phoenix denied his request, citing a 1952 Arizona Supreme Court case in support of its assertion that metadata did not constitute a public record.

In overruling the Court of Appeals - which had upheld the trial court's ruling that the City need not produce the metadata - the Arizona Supreme Court adopted the reasoning of the dissenting judge below, Judge Norris, who argued that metadata is not an "electronic orphan," but instead part of the computer-created document itself.  If the computer-created document is a public record, the Court reasoned, the attached metadata necesarily is as well.

The Court also sought to allay concerns that the ruling would create an "administrative nightmare" for public entities, finding that a public entity can satisfy a public records request by producing the requested records in native format.  The Court, however, expressly declined to address whether and when a public entity has the duty to preserve public records in electronic format.

As Arizona goes, so goes the nation?  A Washington Court of Appeals ruled last summer in O’Neill v. City of Shoreline, 145 Wash. App. 913, 187 P.3d 822 (Wash. Ct. App. 2008) that the electronic version of an e-mail, along with the associated metadata, constitute public records subject to that state's public records law.  Unlike the Arizona law, however, the Washington public records act specifically provides that such items are subject to disclosure.  That case is now pending before the Washington Supreme Court.

Edmund Hillary Knows Beans About Metadata

"Because it is there" may be a perfectly adequate response to the question of why you want to scale a mountain (although it invites the follow-ups of "are you crazy?" and "does your spouse know you spent four thousand dollars on climbing gear?"). It does not, however, cut it when a judge asks why you want a mountain of metadata. 

The court in Dahl v. Bain Capital Partners, LLC, 2009 U.S. Dist. LEXIS 52551 (D. Mass. June 22, 2009) reminds us of this fact.  In that case, a requesting party sought every last scrap of metadata associated with the electronically stored information produced by the other side. The producing party refused, instead offering to hand over just 12 fields of metadata. Ignoring the inevitable follow-up question, "Does your client know you spent four thousand dollars on a discovery dispute over metadata?", the requesting party took the issue before the court. 

The Dahl court explained that the goal of discovery is still to uncover admissible evidence, no matter how many new and exciting areas of information may exist for attorneys and their clients to fight over.  Not all metadata leads to admissible evidence, and so sweeping requests for metadata (regardless of its likely utility) are unnecessarily costly and burdensome -- a fact also recognized in the Rule 34 Advisory Committee Notes.  Accordingly, the court ruled that the requesting party should tailor its metadata requests to specific word documents, emails, or sets of email in an effort to reduce the burdens of production, thereby increasing the likelihood of prudent and efficient litigation.

As has been noted on this very same website, about three inches down from this post, attorneys should be aware that a successful discovery process requires knowledge of both the technological peculiarities of ediscovery and the established procedures and limits of discovery.  The Dahl opinion confirms that observation.

SharePoint has a Sibling: E-Discovery Blessing or Curse?

Back in January 2008 a Network World article indicated that Forrester Research analysts predicting Microsoft SharePoint grabbing a huge share of the Web 2.0 market-- and they were right!

According to a recent Byte and Switch article, Microsoft's SharePoint had an adoption rate of about 55 percent by the end of 2008. Most if not all companies deploy MS Sharepoint as an enterprise portal technology to replace their static Intranet and enhance work collaboration. Naturally it generates tons of content that all need to be organized, stored, and retrieved in some fashion.

Since SharePoint content management is atypical of organizing and retrieving emails and files stored in a document management system (DMS), that translates into another layer of complexity when it comes to e-discovery- at least from a technical perspective.

One thing for sure -- Sharepoint is highly scalable. That means it has the technical ability to handle a large number of documents or concurrent users. The downside is that SharePoint data files are stored in such a way that it is difficult to manage and backup down to the folder / document level)-- until now. In collaboration with Microsoft, Mimosa Systems recently announced that they've created a version of NearPoint (an email and file archiving solution) to work with SharePoint content archiving, data protection and e-discovery support.

The Nearpoint/Sharepoint integration claims to:

  • Manage data storage costs with complete capture of all SharePoint content including documents, lists, sites and site collections, site configuration and custom metadata.

  • Expedite e-discovery processes with integrated search and in-place legal holds across SharePoint server, email and file system content.

  • Improve recovery service levels with comprehensive data protection for SharePoint server to allow easy recovery of individual items or complete sites.

That sounds all well and good but getting it to play well with your company's other network gadgets and appliances could be a daunting task. Regardless, having a data map to catalog your company's records would be a great start.

In addition to data mapping, it is critical to set up proper corporate governance policies that reflect business process changes to take advantage of SharePoint's Content Types (think metadata), Site ColumnsWorkflow, and Security features. Simply put, the corporate governance policy is a set of roles, responsibilities, processes and rules defined within the enterprise to guide content producers in using the SharePoint Portal and all its functionalities. Without a policy that everyone can follow, SharePoint quickly becomes a hodgepodge of unwieldy data. A lack of consistency will result in poor enterprise search and retrieval for e-discovery purposes. Blessing or curse? It's what you make it.

For more information on data mapping, stay tuned to future free webinars similar to this one we offered.

Location, Location, Location

 King Edward VII was widely known for his infidelities, and his wife, Queen Alexandra, had to pretend to ignore his affairs and wild escapades. But she got the last word. In a famous, albeit  apocryphal, anecdote, as the King lay on his deathbed in 1910, the faithful and grieving Queen was stricken with one reassuring thought, and she supposedly turned to the King’s aide and said: "Now, at least I’ll know where he is."

  Although Queen Alexandra may have been comfortable with the King’s   whereabouts after his death, organizations cannot and should not take the same comfort with respect to their electronic files. E-files that have been deleted in accordance with an organization’s document retention policy may not be where an organization thinks those files are - gone. To the contrary, the files may be dangerously lurking in the deep dark corners of the organization’s information systems.


Unfortunately, when it comes to electronic documents, common document retention and deletion policies and procedures simply may not adequately protect sensitive information from falling into the hands of others. Deleting an e-mail or electronic document may not completely remove the data from a computer or computer system. Instead, the deleted information often remains there, typically on the computer's disk drive, until it is overwritten by other information.  The data can often be recovered using software tools designed for recovering deleted information.


When electronic information has not been completely deleted from a computer system, the information may be subject to discovery in litigation.  Kenneth L. Stein and Richard H. An, writing for The Privacy and Data Protection Legal Reporter, point out a number of cases where information that was thought to have been deleted from a computer system came back to haunt an organization in connection with litigation. In one such case, “forensic analysis of deleted electronic files established that the defendant had perjured himself in his sworn declarations to the court about having had no contact with a certain individual”. See YCA, LLC v. Berry, No. 03 C 3116, 2004 U.S. Dist. LEXIS 8129, at *20-24, 22 (N.D. Ill. May 6, 2004)… In another, “forensic officers were able to recover deleted computer images of child pornography, which led to a lengthy prison sentence for the defendant.” See Anderson v. McBride, No. 2:05-CV-1089, 2006 WL 2468284, at *2 (S.D. Ohio Aug. 24, 2006).

At the end of the day, a company should implement policies that both retain the documents that might be relevant to litigation, and destroys the documents and metadata that might be sensitive and private. A document retention policy that includes automatically deleting e-mails and electronic files, without also wiping the underlying data in those e-mails and files, leads to a false sense of security.

The lesson: unlike King Edward VII, who was safely interred in the chapel at Windsor Castle and hasn’t been seen since, your e-files are not dead and buried until the underlying data is wiped clean. Don’t let your metadata come back to haunt you.

Getting TIFFed Off: The Dangers of Not Going Native with ESI . . . Or, The Perils of Killing the Bunny

For a full understanding of the Great TIFF v. Native Debate and the dangers of choosing the wrong side, try this. Picture a bunny.

Why not? Spring is near, and Easter is only a month away. So, picture a bunny. You can cuddle it, watch its little nose twitch, listen to its heartbeat, even observe its behavior and follow it home. If you are one of those lucky creatures who speak bunny -- like computer programmers speak source code -- you can politely inquire where it's been, what it's seen and who it has spoken with.

Electronically-stored information (ESI) such as e-mails and spreadsheets, is like that living bunny. It exists in pure native form, possessing an exotic birthday suit from which can be gathered the hidden details known as metadata -- who authored the data, who sent and received it, the underlying formulas behind the numbers in an Excel spreadsheet, where files or e-mails were stored, who read or possessed them, when they were created, accessed, modified and saved. Such ESI produced by a party is fully searchable. Like the bunny, it can talk to your opponent, and tell them things.

But herein lies the nasty little secret: attorneys and their clients do not want the bunny to talk to their opponents. In fact, they would love to produce ESI in such a way that their opponents cannot communicate with the bunny. But in most cases, their opponents' requests for production specifically ask them to turn over the bunny. So what can they do?

Picture that bunny, dead. Whacked. A poor dead bunny, handed over to the other side. No pulse. No heartbeat. You can't follow a dead bunny home. You can't talk to it, and it certainly can't talk back. That dead bunny is a TIFF, or "Tagged Image File Format," like a PDF. When the bunny is snuffed and the electronic data "TIFFed" -- i.e., printed out in hard copy and then re-scanned -- it becomes dead and frozen, rather than dynamic and searchable. What you see is what you get. The hidden information, the ability to search millions of pages of text for smoking gun language, and to peek at its living history, is lost. And your opponent has no way to recreate it. There is no way for him to resuscitate that bunny. Sure, he can take a DNA test of the dead bunny: convert the tiny elements of TIFF images -- the individual letters, like the Ts, As, Gs and Cs of a double helix -- into searchable text format through optical character recognition ("OCR"). But OCR does not solve the main problem: identification of the lifeblood, the living metadata of the bunny's life history (the who, what, where, when and why) that does not appear in the TIFFs.

Still, what's wrong with this? Why not always produce ESI in TIFF rather than native metadata form? Why not always produce a dead bunny? Isn't this a perfect solution? Unfortunately, no -- as one law firm, two lawyers, and their very unhappy client just learned in Bray & Gillespie Mgmt. LLC v. Lexington Ins. Co., No. 6:07-cv-222-Orl-35 KRS (M.D. Fla. Mar. 4, 2009). In short, Lexington wanted a live bunny and requested all ESI in native format without any alteration or deletion of metadata. Its opponent Bray & Gillespie (B&G) produced a very dead bunny, and was called out by the court for doing so. And that was before B&G's counsel began lying about who killed the bunny and when.

At issue were material misrepresentations made by two individual partners at B&G's counsel, Reed Smith: Berringer (who was involved in discovery) and Ellison (who was not). Berringer told the court that its client B&G killed the bunny by printing its ESI in hard copy and sending it to its former counsel Anderson Kill, who then scanned the documents to create the TIFFs that Reed Smith later produced when they took over the case. But Berringer's information was third-hand, and wrong. He could have contacted Anderson Kill, reviewed the original database, or talked to his client to determine the truth. He did nothing. Even an early draft of a declaration from B&G's vice president stated "electronic documents were extracted directly from individual computers" and given to Anderson Kill. These paragraphs were mysteriously omitted from the final version of the declaration.

The court found that B&G and its counsel had deliberately ignored evidence that in fact, the ESI had been obtained from the client in native and fully-searchable electronic form with metadata, in an Introspect database. In other words, Anderson Kill obtained a live bunny from the client. The bunny was then killed -- converted to TIFFs "using a program that was set to selectively exclude certain types of metadata" before production, which "removed or significantly degraded Lexington's ability to search the ESI and, accordingly, that it was not in a reasonably usable form as required" by Rule 34 of the Federal Rules of Civil Procedure.

Berringer waited until near the end of a hearing before the court to admit that the bunny had been obtained alive. Even then, he did not disclose what metadata was in the Introspect database or how the ESI was transferred to the database; did not disclose the existence of the Target Hard Drive with the original production or that Reed Smith had a copy of it. Instead, Berringer and Ellison made material misrepresentations as to why they did not produce this live bunny: they blamed Anderson Kill's refusal to allow them access to the database, which was not true. The court found that B&G “directly or through their agents deliberately manipulated the electronically stored information in such a way as to withhold from the defendants the information that had been requested, specifically metadata,” and ordered production of the live bunny.

The end? Not even close. B&G produced the bunny -- alive, but with an impaired memory, or limited metadata. In short, they gave up a lobotomized bunny. The court responded by requesting a supplemental response addressing why sanctions should not be imposed upon B&G and its counsel. After a second hearing, the court found that Lexington was severely prejudiced, and ordered production of the entire Introspect database in whatever form Lexington wanted, with all costs borne by B&G, and 60 days of extra discovery for Lexington to conduct any follow-up. The court then turned to the issue of Rule 37 sanctions for killing the bunny, lying about it, and then following up with a brain-damaged bunny:

Anderson Kill, the original law firm that gathered the data: NO SANCTIONS. The firm, Anderson Kill, was off the case by the time production occurred and gave Reed Smith full access to all data. While responsible for putting together the TIFF disks, it was open with Reed Smith about the fact that had been transferred from native electronic format with metadata, to TIFF format. And it did not produce the TIFFs.

A new attorney on the case who joined after the discovery misconduct: NO SANCTIONS. But the court warned him against "blindly relying on outside counsel falls short of the duty he has as an officer of the court, as counsel of record, and as an advocate for his client."

Ellison, counsel of record that was not responsible for the discovery misconduct: SANCTIONS. The discovery misconduct was done under his supervision, making him “an attorney advising” the defendant on the discovery misconduct, and thus personally liable for Rule 37 sanctions.

Berringer, counsel of record responsible for the discovery misconduct: SANCTIONS, pending a hearing. The court issued an order to show cause as to why Berringer should not be personally sanctioned for his misconduct.

Reed Smith, the law firm of both counsel of record: SANCTIONS. Law firms that employ attorneys who "have engaged in a pattern of withholding and concealing information concerning discoverable material and misrepresenting to the court and opposing counsel material facts about numerous failures to comply with discovery requests and Court orders -- including falsely blaming a lack of third-party cooperation and fabricating a false story about the form in which ESI was gathered and stored" are subject to "significant sanctions." The Firm and its counsel were jointly and severally liable for Lexington's fees and costs.

The court rejected all of B&G counsel's excuses for killing the bunny, including that: (1) Lexington did not provide adequate notice of its requests for metadata because they was buried in "five pages of boilerplate definitions and instructions"; (2) re-production would be too burdensome as it would require a new privilege review -- which was not true, because the documents in the Introspect database had already been reviewed for privilege; and (3) B & G was entitled to produce ESI as maintained in the usual course of business and in a reasonably usable form -- an odd argument, since maintenance of ESI in the "usual course of business" was in native metadata form anyway.

The lessons here are many, and clear.  Counsel at Reed Smith could have avoided this whole mess by confirming the trail and treatment of ESI as it passed hands from the client to opposing counsel. Similarly, the court noted that B&G and its counsel could have easily resolved the dispute before either hearing by handing over the live bunny: "by producing the complete metadata load files from the Introspect database for the TIFF images." So, don't kill the bunny. Don't lie about who killed the bunny and when. Don't try to get away with it using lame excuses as to why you killed the bunny. And don't try to redeem yourself with a brain-damaged bunny. Instead, to avoid sanctions, especially when document requests specifically ask for ESI in native format (as almost all do now), turn over the bunny.

Alive and kicking.

Cirrus, Stratus, Cumulus - What's in Your Cloud?

It's official. The Big Blue (a/k/a IBM) joined other technology behemoths such as EMC, Cisco Systems, and Sun Microsystems by creating a Cloud Computing Division to handle the increasingly complex digital information environment, as reported by eWeek.

Not only is this a significant business development for technology companies that span the globe, but it is also a recognition of the importance of a single point of contact in terms of managing data centers to supply infrastructure for cloud-type services.

Although cloud computing is as pervasive and complex as the classification of clouds in atmospheric terms, it can be summed up as computing from anywhere at any time, as IBM articulated in its overview of cloud computing. Despite this massive web of interconnectivity, it can also be cohesive, if it is well-managed.

But what does cloud computing have to do with e-discovery? When information is transported across the Internet, it is done in the form of bits and bytes wrapped in data packets, which contain lots of information about the information that is being transmitted. Each data packet has a header and a "payload." While the header keeps overhead information about the packet, the service and other transmission-related things, the payload is the data itself.

A packet header includes the source IP address, the destination IP address, and the type of service. If you compare data packet delivery to the US Postal Service, a data packet would be similar to an envelope with the sent and return addresses (header) along with the actual sealed document (payload) delivered via First Class or Standard (type of service). So, in essence, a data packet contains information not dissimilar to metadata in any electronic documents.

On the issue of discoverability, we all know that metadata can be subject to discovery.  Courts have held that when a party is ordered to produce electronic documents, as they are maintained in the ordinary course of business, the producing party must produce those electronic documents with the metadata intact.  See Williams v. Sprint/United Mgmt. Co., 230 F.R.D. 640 (D. Kan. 2005).  On the flip side, the Federal Rules do allow a party being asked to produce metadata to move for a protective order if the requested metadata is "not reasonably accessible" and will result in "undue burden and cost."  See F.R.C.P. Rule 26(c) and Rule 26(b)(2)(B)

The question remains, however, will data packets be handled in the same way as metadata?

Now that the major tech players have separate divisions to handle cloud computing, it presents potential advantages in retrieving data that proved to be difficult to track in the past, particularly for law firms and companies that have a multinational presence. This may be good news for the e-discovery universe since data and packets can now (at least in theory) be traced or retrieved in a more controlled manner. Unlike language issues in e-discovery, the world of data packets still conveys itself in expression of zeros and ones.  However, it might be bad news for companies that are trying to reign in their e-discovery costs and obligations.

Regardless of technological advances, it remains to be seen whether courts will require technology companies to retain "records" of transient information such as the astronomical number of data packets that traverse through the Internet by the millisecond.

Ode to E-Discovery in 2008

Flooding the internet, they consistently accrue:
Blawgs offering e-discovery 'Year in Review's;
But these go on about facts and case histories too,
Before getting to the point of what you can and can't do.

Why not cut to the chase? Why not give it up straight?
Stripped below are the basics of two thousand and eight.
We'll start off with the general dos and the don'ts;
The haven'ts, the shouldn'ts, the emphatically won'ts.

Quite instructive are Canon's and Keithley's examples
Of "lackadaisical attitude" of defendants. As samples:
Do not find that hard drive behind the client's home door,
When discovery has been ongoing for a year or for more.

Do not stumble on computer reports you said "did not exist"
In an e-folder marked "Reports" that you for some reason missed.
And periodically remind clients and their IT personnel
Of the need to preserve the source code that was written on that Dell.

When you don't produce e-mails, the court said in Peskoff
Explain your search method and why, at production, you scoffed.
But if you contributed to information deletion or loss
And the court orders recovery, you won't get your costs!

Do not say you've e-searched when it's just a tall tale:
This was sanctioned under Rule 26 in R&R Sails.
There were costs sanctions also in Ajaxo, among a larger plethora.
And sanction of termination in Arteria and also Pandora.

In Keithley sanctions were imposed even on a party pro se
And in Schwarzenegger for "foot dragging" and a "litany of delays."
But take heed, warned O'Keefe -- don't request termination on whim.
Do not "strike at a king" unless you're sure you'll "kill him."

O'Keefe (plus Equity, Victor) gave lawyers heart attacks.
For saying that search term effectiveness is for experts to crack;
And that if lawyers pick and evaluate the key words instead
They are moving toward places "where angels fear to tread."

The courts warned that when using a method of searching
Learn first of its weaknesses through prior researching.
This was why D'Onofrio rejected what both experts said
And created a brand new search protocol method instead.

Rule 502 on preventing waiver through "reasonable steps"
Saw decisions pronouncing judgment on various missteps.
Alcon acknowledged that the Rule's very recent debut
Was designed to avoid "expensive, painstaking review."

Despite this pronouncement, some courts have cried "waived"
As to attempts made in hindsight to have privilege saved.
Rhoads found possible waiver for documents mistakenly produced
If they were not in the privilege log – there could be no excuse.

And failure to take measures that could prevent waiver
Like claw-back agreements, or Sedona-type saviors
Led to Victor’s conclusion, which uncommonly held
That the attorney-based privilege at issue was quelled.

Moving on, Mancia addressed the Rule 26 obligation
To meet early on regarding e-preservation,
Proclaiming "adversarial conduct" in e-discovery condemned
As a "burden to the American judicial system."

Some courts dove in early to prevent such discord,
Ordering forensic exams to preserve evidentiary records.
To conserve ephemeral info in Xpel, it was fair;
And when defendants were evading service, it was ordered in Allcare.

Other examples included when a party was unable
or unwilling (in Canon) to preserve/produce on the table.
Just remember: as emphasized in Sterle and Square D
Do not interfere with a court-ordered forensic decree.

Rodman, Reinhard and Younessi addressed nonparty subpoenas
And the protection of confidential, trade secret arenas.
Where nonparties are concerned and offer up much resistance
In-house searches are fine, or neutral expert assistance.

The debates continue on metadata versus non-native tracks
And Aquilar labeled metadata as being "the new black."
That court ordered re-production of non-natives with meta
Though the recipient was required to pay costs, as pro rata.

But not all courts required conversion to a metadata mode.
Extra burden led D'Onofrio to an "only if necessary" ode.
And Autotech said doc requests must actually require "native" --
You can't ask for it in hindsight by getting creative.

Yet if e-documents already exist in original native form
And the requests do not contain any language that informs,
White condemned the conversion to non-native in litigation
Since this is done just to increase the opponent's frustration.

Finally, social networks are making an appearance in law
And becoming a most popular e-discovery draw.
The field is wide open on the extent to which these
Are discoverable and admissible, or cannot be seized.

Flagg required defendants to give ISPs consent
And to produce ISP-retrieved records of texts that it sent.
And in Australia a court made clients even more nervous
By allowing Facebook to be used as a method of service!

We hope you've enjoyed this short "Year in Review"
And that all of this knowledge is useful to you.
We await more developments in two thousand and nine;
And wonder whether and where courts will draw any lines.


**For a complete list of the cases discussed above, please contact the author.

Metadata in digital photographs

I recently handled a case where opposing counsel repeatedly emailed to me photographs purportedly evidencing her client's factual assertions.  Naturally, my clients and I had troubling questions regarding, among other things, (1) whether all of the photographs were taken on the same date at roughly the same time, (2) the source of the photographs, and (3) whether the photographs had been altered.  In the future, there may be a way to obtain that information from the photographs themselves, although, unfortunately, that information may have limited reliability.

A blog called "Out of the Box Lawyering" has a very interesting and useful recent post about a Microsoft program called Photo Info that potentially enables you to obtain from the digital version of a photograph data such as:

  • the time and date the photograph was taken;
  • the model of the camera with which the photograph was taken;
  • technical information that could bear on whether the photograph was altered;
  • other information relating to the "author" of the photo.

Although this tool has interesting ediscovery implications, the fact that the program itself allows people to change or augment that very metadata likely limits the evidentiary value of that metadata.