I’m saddened to share that Monica Bay, the forceful, revered former editor of Law Technology News (now Legaltech News) has died after a long, debilitating illness. Though a durable resident of New York City and Connecticut, Monica’s life ended in California where it began. Monica described herself as a “provocateur,” an apt descriptor from one gifted in finding the bon mot. Monica was a journalist with soaring standards whose writing exemplified the high caliber of work she expected from her writers. I cannot overstate Monica’s importance to the law technology community in her 17 years at the helm of LTN. Monica mentored multitudes and by sheer force of her considerable strength and will, Monica transformed LTN from an industry organ purveying press releases to an award-winning journal unafraid to speak truth to power.
In her time as editor, Monica was everywhere and indefatigable. Monica was my editor for much of her tenure at LTN including nine years where I contributed a monthly column she dubbed “Ball in Your Court” (see what I mean about her mastery of the well-turned phrase?) We had a complicated relationship and butted heads often, but my submissions were always better for Monica’s merciless blue pencil. I owe her an irredeemable debt. She pushed me to the fore. You wouldn’t be reading this now if it weren’t for Monica Bay’s efforts to elevate me. The outsize recognition and writing awards I garnered weren’t my doing but Monica’s. If life were a movie, Monica would be the influential publisher who tells the writer plucked from obscurity, “I made you and I can break you!” And it would be true.
This elegy would have been far better if she’d edited it.
Trying to illuminate Monica, I turned to Gmail to refresh my memory but backed off when I saw we’d shared more than 2,200 conversations since 2005. I’d forgotten how she once loomed so large in my life. In some of those exchanges, Monica generously called me, “hands down my best writer,” but I wouldn’t be surprised if she said that to everyone in her stable of “campers.” Monica knew how to motivate, cajole and stroke the egos of her contributors. She was insightful about ego, too.
In 2010 when I carped that there’s always too much to do, and always somebody unhappy with me, she counseled, “Like me, you are an intense personality, and we can be difficult to live with at times. but that intensity and drive is also what makes you who you are, why you are successful, and why you are a breathtakingly good writer. My favorite people in the world are ‘difficult.’”
I wince as I write that last paragraph because as much as she was brilliant in managing egos, Monica didn’t love that part of her work. She confided, “I think we have to be mindful that we don’t exercise our egos in a way that constrains — or worse case, cripples — those around us. That’s the hard part.”
Monica observed of a well-known commentator of the era, “he wouldn’t be able to write if he had to excise ‘I’ from his vocabulary… he annoys me more than the Red Sox or Jacobs Fields gnats.”
That reminds me that Monica had a personal blog called “The Common Scold.” She named it for a Puritan-era cause of action where opinionated women were punished by a dunk in a pond. I mostly remember it for its focus on New York Yankees baseball, which became a passion for Monica when she moved east despite a lifelong disinterest in sports. Monica, who insofar as I knew, never married, often referred to herself in the Scold as “Mrs. Derek Jeter.” She was quirky that way and had a few quirky rules for writers. One was that the word “solution” was banned, BANNED, in LTN.
To her credit, Monica Bay wasn’t afraid to nip at the hand that feeds. Now, when every outlet has bent to the will of advertisers, Monica’s strict journalistic standards feel at once quaint and noble. Consider this excerpt from her 2009 Editorial Guidelines:
“Plain English: Law Technology News is committed to presenting information in a manner that is easily accessible to our readers. We avoid industry acronyms, jargon, and clichés, because we believe this language obfuscates rather than enhances understanding.
For example, the word “solution” has become meaningless and is banned from LTN unless it’s part of the name of a company. Other words we edit out: revolutionary, deploy, mission critical, enterprise, strategic, robust, implement, seamless, initiative, -centric, strategic [sic], and form factor! We love plain English!”
Monica was many things more than simply an industry leader, from a wonderful choral singer to the niece of celebrated actress, Elaine Stritch. She was my champion, mother figure, friend and scold. I am in her debt. And you are, too, Dear Reader, for Monica Bay pushed through barriers that fell under her confident stride.
Fifteen years ago, when Monica lost her father, and my mother was dying, we supported each other. Monica called her dad’s demise the “great gift of dementia from the karma gods. No pain, just a gentle drift to his next destination.” That beautifully describes her own shuffle off this mortal coil. As the most loving parting gift I can offer my late, brilliant editor, I cede to her those last lovely words, “just a gentle drift to [her] next destination.”
[I have no information about services or memorials, but I look forward to commemorating Monica’s life and contributions with others who loved and admired her]
I’ll need to dust off the cobwebs as I haven’t been in this space in quite some time! I’ve not had much to say, and honestly, if I didn’t sneak “ChatGPT” into the title, who’d notice? Preparing for a September 20th presentation to an international conclave of forensic examiners in Phoenix, I extensively revised and expanded my guide for testifying experts, now called “Being the Better Expert Witness: A Primer for Forensic Examiners.” I describe it thus:
This paper covers ways to become an effective witness and pitfalls to avoid. They say lawyers make notoriously poor witnesses and I have no illusions that I’m a great witness. But after forty years of trial practice and thirty as a forensic examiner, I’ve learned a few lessons I hope might help other examiners build their skills in court.
In the paper, I discuss the difficulty computer forensic examiners face honing their testimonial abilities because it’s rare to be interrogated by a lawyer who truly understands what we are talking about. Most interrogators work from a script. They know the first question to ask, but not the next or the one after that. Pushed from their path, they’re lost. Computer forensic examiners have it easy on the stand. Deep fakes notwithstanding, computer-generated evidence still enjoys an aura of accuracy and objectivity, and the hyper-technical nature of digital forensics awes and intimidates the uninitiated. Thank you, CSI, NCIS and all the rest! But sooner or later, computer forensic examiners will square off against interrogators able to skillfully undermine ability and credibility. I want them to be ready.
As I’m wont to do, I ambled down memory lane:
“Evidence professor John Henry Wigmore famously called cross-examination “the greatest legal engine ever invented for the discovery of truth.” Apparently, every lawyer who writes about cross-examination is obliged to say that. Likewise, every trial lawyer aspires to do a great cross examination, and every judge and juror aspires to hear one. Yet, as I observed at the start, they are rare.”
“Forty years ago, my boss was on the trial team of a lawsuit between Pennzoil and Texaco that resulted in the biggest plaintiff’s verdict of the era and a three-billion-dollar settlement—back when that was a lot of money. The lawyer for Texaco, the big loser, was named Dick Miller, and my boss used to say of him, “Dick Miller has two speeds: OFF and KILL.” I’ll never forget that because it encapsulates how some lawyers approach cross-examination. A truly devastating cross examination flows from applying lessons learned from the raptors in Jurassic Park: get the prey to look one way, while the attack comes from another.“
“In court, that entails laying a trap and not springing it too early. Skilled cross examiners box witnesses in and seal off points of retreat before the witness recognizes the need to run. The very best cross examiners don’t spring their traps during the cross; they save that for final argument.”
“The greatest teacher of cross-examination I’ve ever come across was a former prosecutor, judge and law professor named Irving Younger, who died about 35 years ago. Younger’s famous lecture on the topic was called “The Ten Commandments of Cross-Examination.” I’ve listened to multiple versions of his talk over the years and all are magnificent. Stirring. Funny. Unforgettable. Younger opined that a lawyer must try about 25 cases to begin to be skilled in cross-examination, but he GUARANTEED that any lawyer strictly adhering to his Ten Commandments would be able to conduct a reasonably effective cross-examination. Of course, he added, no lawyer is capable of sticking to all his commandments until the lawyer has about 25 trials under his belt!”
“I do not have ten surefire commandments that will guarantee you won’t get in trouble on cross-examination, but I have a lifetime in court (much of one anyway) and many years teaching law to draw on in offering advice on what to expect on cross plus a few suggested techniques that I GUARANTEE will help you become a better witness.”
I’m proud to be the first to announce that the Electronic Discovery Reference Model (EDRM) has developed a specification for cross-platform identification of duplicate email messages, allowing for ready detection of duplicate messages that waste review time and increase cost. Leading e-discovery service and software providers support the new specification, making it possible for lawyers to improve discovery efficiency by a simple addition to requests for production. If that sounds too good to be true, read on and learn why and how it works.
THE PROBLEM
The triumph of information technology is the ease with which anyone can copy, retrieve and disseminate electronically stored information. Yet, for email in litigation and investigations, that blessing comes with the curse of massive replication, obliging document reviewers to assess and re-assess nearly identical messages for relevance and privilege. Duplicate messages waste time and money and carry a risk of inconsistent characterization. Seeing the same thing over-and-over again makes a tedious task harder.
Electronic discovery service providers and software tools ameliorate these costs, burdens and risks using algorithms to calculate hash values—essentially digital fingerprints—of segments of email messages, comparing those hash values to flag duplicates. Hash deduplication works well, but stumbles when minor variations prompt inconsistent outcomes for messages reviewers regard as being “the same.” Hash deduplication fails altogether when messages are exchanged in forms other than those native to email communications—a common practice in U.S. electronic discovery where efficient electronic forms are often printed to static page images.
Without the capability to hash identical segments of identical formats across different software platforms, reviewers cannot easily identify duplicates or readily determine what’s new versus what’s been seen before. When identical messages are processed by different tools and vendors or produced in different forms (so-called “cross-platform productions”), identification of duplicate messages becomes an error-prone, manual process or requires reprocessing of all documents.
Astonishingly, no cross-platform method of duplicate identification has emerged despite decades spent producing email in discovery and billions of dollars burned by reviewing duplicates.
Wouldn’t it be great if there was a solution to this delay, expense and tedium?
THE SOLUTION
When parties produce email in discovery and investigations, it’s customary to supply information about the messages called “metadata” in accompanying “load files.” Load files convey Bates numbers/Document IDs, message dates, sender, recipients and the like. Ideally, the composition of load files is specified in a well-crafted request for production or production protocol. Producing metadata is a practice that’s evolved over time to prompt little argument. For service providers, producing one more field of metadata is trivial, rarely requiring more effort than simply ticking a box.
The EDRM has crafted a new load file field called the EDRM Message Identification Hash (MIH), described in the EDRM Email Duplicate Identification Specification.
Gaining the benefit of the EDRM Email Duplicate Identification Specification is as simple as requesting that load files contain an EDRM Message Identification Hash (MIH) for each email message produced. The EDRM Email Duplicate Identification Specification is an open specification, so no fees or permissions are required to use it, and leading e-discovery service and software providers already support the new specification. For others, it’s simple to generate the MIH without redesigning software or impeding workflows. Too, the EDRM has made free tools available supporting the specification.
Any party with the MIH of an email message can readily determine if a copy of the message exists in their collection. Armed with MIH values for emails, parties can flag duplicates even when those duplicates take different forms, enabling native message formats to be compared to productions supplied as TIFF or PDF images.
The routine production of the MIH supports duplicate identification across platforms and parties. By requesting the EDRM MIH, parties receiving rolling or supplemental productions will know if they’ve received a message before, allowing reviewers to dedicate resources to new and unique evidence. Email messages produced by different parties in different forms using different service providers can be compared to instantly surface or suppress duplicates. Cross-platform email duplicate identification means that email productions can be compared across matters, too. Parties receiving production can easily tell if the same message was or was not produced in other cases. Cross-platform support also permits a cross-border ability to assess whether a message is a duplicate without the need to share personally-identifiable information restricted from dissemination by privacy laws.
IS THIS REALLY NEW?
Yes, and unprecedented. As noted, e-discovery service providers and law firm or corporate e-discovery teams have long employed cryptographic hashing internally to identify duplicate messages; but each does so differently dependent upon the process and software platform employed—sometimes in ways they regard as being proprietary—making it infeasible to compare hash values across providers and platforms. Even if competitors could agree to employ a common method, subtle differences in the way each process and normalize messages would defeat cross-platform comparison.
The EDRM Email Duplicate Identification Specification doesn’t require software platform and service providers to depart from the proprietary ways they deduplicate email. Instead, the Specification contemplates that e-discovery software providers add the ability to produce the EDRM MIH to their platform and that service providers supply a simple-to-determine Message Identification Hash (MIH) value that sidesteps the challenges just described by taking advantage of an underutilized feature of email communication standards called the “Message ID” and pairing it with the power of hash deduplication. If it sounds simple, it is–and by design. It’s far less complex than traditional approaches but sacrifices little or no effectiveness or utility. Crucially, it doesn’t require any difficult or expensive departure from the way parties engage in discovery and production of email messages.
WHAT SHOULD YOU DO TO BENEFIT?
All you need to do to begin reaping the benefits of cross-platform message duplicate identification is amend your Requests for Production to include the EDRM Message Identification Hash (MIH) among the metadata values routinely produced as load files. As a prominently published specification by the leading standards organization in e-discovery, it’s likely the producing party’s service provider or litigation support staff know what’s required. But if not, you can refer them to the EDRM Email Duplicate Identification Specification & Guidelines published at https://edrm.net/active-projects/dupeid/.
HOW DO YOU LEARN MORE?
The EDRM publishes a comprehensive set of resources describing and supporting the Specification & Guidelines that can be found at https://edrm.net/active-projects/dupeid/. All persons and firms deploying the EDRM MIH to identify duplicate messages should familiarize themselves with the considerations for its use.
EDRM WANTS YOUR FEEDBACK
The EDRM welcomes any feedback you may have on this new method of identifying cross platform email duplicates or on any of the resources provided. We are interested in further ideas you may have and expect the use of the EDRM MIH to evolve over time. You can post any feedback or questions at https://edrm.net/active-projects/dupeid/.
For the second class meeting of my law school courses on E-Discovery and Digital Evidence, I require my students read the fourteen Sedona Conference Principles from the latest edition of “Best Practices, Recommendations & Principles for Addressing Electronic Document Production.” The Sedona principles are the bedrock of that group’s work on ESI and, notwithstanding my misgivings that the Principles have tilted toward blocking discovery more than guiding it, there’s much to commend in each of the three versions of the Principles released over the last twenty years. They enjoy a constitutional durability in the eDiscovery community.
When my students read the Principles, I revisit them and each time, something jumps out at me. This semester, it’s the musty language of Principle 9:
Principle 9: Absent a showing of special need and relevance, a responding party should not be required to preserve, review, or produce deleted, shadowed, fragmented, or residual electronically stored information.
The Sedona Principles, Third Edition: Best Practices, Recommendations & Principles for Addressing Electronic Document Production, 19 SEDONA CONF. J. (2018)
Save for the substitution of “electronically stored information” for the former “data or documents,” Principle 9 hasn’t been touched since its first drafts of 20+ years ago. One could argue its longevity owes to an abiding wisdom and clarity. Indeed, the goals behind P9 are laudable and sound. But the language troubles me, particularly the terms, “shadowed” and “fragmented,” which someone must have pulled out of their … I’ll say “hat” … during the Bush administration, and presumably no one said, “Wait, is that really a thing?” In the ensuing decades, did no one question the wording or endeavor to fix it?
My objection is that both are terms of art used artlessly. Consider “shadowed” ESI. Run a search for shadowed ESI or data, and you’ll not hit anything on point but the Principle itself. Examine the comments to Principle 9 and discover there’s no effort to explain or define shadowed ESI. Head over to The Sedona Conference Glossary: eDiscovery and Digital Information Management, and you’ll find nary a mention of “shadowed” anything.
That is not to say that there wasn’t a far-behind-the-scenes service existing in Microsoft Windows XP and Windows Server to facilitate access to locked files during backup that came to be called “Volume Shadow Copy Services” or “VSS,” but it wasn’t being used for forensics when the language of Principle 9 was floated. I was a forensic examiner at the time and can assure you that my colleagues and I didn’t speak of “shadowed” data or documents.
But whether an argument can be made that it was a “thing” or not twenty years ago, it’s never been a term in common use, nor one broadly understood by lawyers and judges. It’s not defined in the Principles or glossaries. You’ll get no useful guidance from Google.
What harm has it done? None I can point to. What good has it done? None. Yet, it might be time to consign “shadowed” to the dustbin of history and find something less vague. It’s not gospel, it’s gobbledygook.
“Fragmented” is a term that’s long been used in reference to data storage, but not as a synonym for “residual” or “artifact.” Fragmented files refer to information stored in non-contiguous clusters on a storage medium. Many of the files we access and know to be readily accessible are fragmented in this fashion, and no one who understands the term in the context of ESI would confuse “fragmented” data or documents with something burdensome to retrieve. But don’t take my word for that, Sedona’s own glossary backs me up. Sedona’s Principle 9 doesn’t use “fragmented” as Sedona defines it.
If the drafters meant “fragments of data,” intending to convey “artifacts recoverable through computer forensics but not readily accessible to or comprehended by users,” then perhaps other words are needed, though I can’t imagine what those words would add that “deleted” or “residual” doesn’t cover.
This is small potatoes. No one need lose a wink of sleep over the sloppy wording, and I’m not the William Safire of e-discovery or digital forensics; but words matter. When you are writing to guide persons without deep knowledge of the subject matter, your words matter very much. If you use a term of art, make sure it’s a correct usage, a genuine one; and be certain you’ve either used it as experts do or define the anomalous usage in context.
When I fail to do that, Dear Reader, I hope you’ll call me on it, too.
Periodically, I strive to pen something practical and compendious on electronic evidence and eDiscovery, drilling into a topic, that hasn’t seen prior comprehensive treatment. I’ve done primers on metadata, forms of production, backup systems, databases, computer forensics, preservation letters, ESI processing, email, digital storage and more, all geared to a Luddite lawyer audience. I’ve long wanted to write, “The Annotated ESI Protocol.” Finally, it’s done.
The notion behind the The Annotated ESI Protocol goes back 40 years when, as a fledgling personal injury lawyer, I found a book of annotated insurance policies. What a prize! Any plaintiff’s lawyer will tell you that success is about more than liability, causation and damages; you’ve got to establish coverage to get paid. Those annotated insurance policies were worth their weight in gold.
As an homage to that treasured resource, I’ve sought to boil down decades of ESI protocols to a representative iteration and annotate the clauses, explaining the “why” and “how” of each. I’ve yet to come across a perfect ESI protocol, and I don’t kid myself that I’ve crafted one. My goal is to offer lawyers who are neither tech-savvy nor e-discovery aficionados a practical, contextual breakdown of a basic ESI protocol–more than simply a form to deploy blindly or an abstract discussion. I’ve seen thirty-thousand-foot discussions of protocols by other commentators, yet none tied to the document or served up with an ESI protocol anyone can understand and accept.
It pains me to supply the option of a static image (“TIFF+”) production, but battleships turn slowly, and persuading lawyers long wedded to wasteful ways that they should embrace native production is a tough row to hoe. My intent is that the TIFF+ option in the example sands off the roughest edges of those execrable images; so, if parties aren’t ready to do things the best way, at least we can help them do better.
Fingers crossed you’ll like The Annotated ESI Protocol and put it to work. Your comments here are always valued.
I’ve long been fascinated by electronic search. I especially love delving into the arcane limitations of lexical search because, awful Grinch that I am, I get a kick out of explaining to lawyers why their hard-fought search queries and protocols are doomed to fail. But, once we work through the Seven Stages of Attorney E-Discovery Grief: Umbrage, Denial, Anger, Angry Denial, Fear, Finger Pointing, Threats and Acceptance, there’s almost always a workaround to get the job done with minimal wailing and gnashing of teeth.
Three consults today afforded three chances to chew over problematic search strategies:
First, the ask was to search for old CAD/CAM drawings in situ on an opponent’s file servers based on words appearing on drawings.
Another lawyer sought to run queries in M365 seeking responsive text in huge attachments.
The last lawyer wanted me to search the contents of a third-party’s laptop for subpoenaed documents but without the machine being imaged or its contents processed before search.
Most of my readers are e-discovery professionals so they’ll immediately snap to the reasons why each request is unlikely to work as planned. Before I delve into my concerns, let’s observe that all these requests seemed perfectly reasonable in the minds of the lawyers involved, and why not? Isn’t that how keyword and Boolean search is supposed to work? Sadly, our search reach often exceeds our grasp.
Have you got your answers to why they may fail? Let’s compare notes.
When it comes to lexical search, CAD/CAM drawings differ markedly from Word documents and spreadsheets. Word processed documents and spreadsheets contain text encoded as ASCII or Unicode characters. That is, text is stored as, um, text. In contrast, CAD/CAM drawings tend to be vector graphics. They store instructions describing how to draw the contents of the plans geometrically; essentially how the annotations look rather than what they say. So, the text is an illustration of text, much like a JPG photograph of a road sign or a static TIFF image of a document—both inherently unsearchable for text unless paired with extracted or OCR text in ancillary load files. Bottom line: Unless the CAD/CAM drawings are subjected to effective optical character recognition before being indexed for search, lexical searches won’t “see” any text on the face of the drawings and will fail.
M365 has a host of limits when it comes to indexing Cloud content for search, and of course, if it’s not in the index, it won’t turn up in response to search. For example, M365 won’t parse and index an email attachment larger than 150MB. Mind you, few attachments will run afoul of that capacious limit, but some will. Similarly, M365 will only parse and index the first 2 million characters of any document. That means only the first 600-1,000 pages of a document will be indexed and searchable. Here again, that will suffice for the ordinary, but may prove untenable in matters involving long documents and data compilations. There are other limits on, e.g., how deeply a search will recurse through nested- and embedded content and the body text size of a message that will index. You can find a list of limits here (https://learn.microsoft.com/en-us/microsoft-365/compliance/limits-for-content-search?view=o365-worldwide#indexing-limits-for-email-messages) and a discussion of so-called “partially indexed” files here (https://learn.microsoft.com/en-us/microsoft-365/compliance/partially-indexed-items-in-content-search?view=o365-worldwide). Remember, all sorts of file types aren’t parsed or indexed at all in M365. You must tailor lexical search to the data under scrutiny. It’s part of counsels’ duty of competence to know what their search tools can and cannot do when negotiating search protocols and responding to discovery using lexical search.
In their native environments, many documents sought in discovery live inside various container files ranging from e-mail and attachments in PST and OST mail containers to compressed Zip containers. Encrypted files may be thought of as being sealed inside an impenetrable container that won’t be searched. The upshot is that much data on a laptop or desktop machine cannot be thoroughly searched by keywords and queries by simply running searches within an operating system environment (e.g., in Windows or MacOS). Accordingly, forensic examiners and e-discovery service providers collect and “process” data to make it amenable to search. Moreover, serial search of a computer’s hard drive (versus search of an index) is painfully slow, so unreasonably expensive when charged by the hour. For more about processing ESI in discovery, here’s my 2019 primer (http://www.craigball.com/Ball_Processing_2019.pdf)
In case I don’t post before Chanukah, Christmas and the New Year, have a safe and joyous holiday!
In a case where I’d identified evidence of a departing employee’s data theft, plaintiff’s counsel sought an affidavit in support of a motion to gain direct access to the new employer’s data storage to see how the stolen data was distributed and used. I replied that I could supply the testimony but offered that the wiser strategy was not to move for direct access but instead seek an agreement or order that the other side’s forensic expert hew to an agreed-upon examination protocol. That would afford opposing counsel a proper opportunity to withhold and log content deemed privileged or otherwise outside the scope of discovery.
I’ve worked both sides–and the middle–of countless so-called “bad leaver” cases, where employees are accused of taking data from one employer to another to secure a better job or a competitive advantage. When I’m in the middle, I’m a court-appointed neutral examiner and, in that trusted role, it’s appropriate that I see the whole picture by looking at all implicated devices and accounts: the sources from which data was taken, the transfer media and the target devices and accounts where stolen data and its progeny reside. As a neutral examiner and attorney, I’m well-situated to balance the need to know what happened against the need to guard against improper or abusive discovery.
But when I’m acting for the party suing a competitor alleging data theft, viz., as a partisan expert, the party suspected of benefitting from the theft must be protected from unduly intrusive access to their devices. Both sides have trade secrets requiring protection and both engage in privileged communications with counsel. As well, material encountered on examination often has no relevance yet hurts and shames just by being divulged.
As a partisan working for one side or the other, I’d like to be able to say, “trust me, I’ll be bulwark against revealing your privileged communications and irrelevant stuff,” but that’s not a role I covet absent considerable trust and an express agreement. Trying to be partisan and neutral fosters divided loyalties, and as an attorney, I’m obliged to avoid conflict of interest or anything that looks like it. Lay examiners should, too.
Trust is devoutly to be wished in these situations…but it’s hard to trust those you believe to be thieves. Justified or not, that mistrust frequently extends to those protecting the thieves, i.e., their counsel. So, in the absence of trust in people, the law trusts in sound and transparent processes. In these matters, a well-crafted forensic examination protocol ensures that the right evidence is scrutinized in the right ways, and material legitimately withheld is protected.
By setting out what devices and sources need to be examined, what artifacts must be assessed and reported upon and how much oversight and transparency is allowed, the opposing expert serves as proxy for my hands and eyes. Keyword searches and hash matching alone don’t cut it; a good examination protocol encompasses the singular signs of data theft and makes it difficult to suppress indicia of bad behavior. A good protocol makes production of evidence and artifacts the rule unless there’s legal justification to withhold relevant and responsive evidence—and then there must be disclosure via a privilege log or other means. I discuss drafting forensic examination protocols further in this article. The points made in the article are just a start: proper protocols are tailored to the issues and evidence in the case, and constructed to promote integrity of process.
Can all this be abused? Sure. But, effective e-discovery is a marathon, not a sprint. Certainly, this is true of efforts to seek sanctions. If the process just described can be proven to have been gamed or corrupted, judges respond aggressively to protect the integrity of their courts, among those responses the turnover of an opponent’s devices, that is, the dread direct examination.
So, the takeaway: though sometimes direct access can be secured by agreement, don’t jump straight to a motion to compel access to an opponent’s computers and data storage when the other side says “no.” Instead, pursue alternatives that fairly balance legitimate needs for disclosure against legitimate needs to protect trade secrets, privacy and privilege. Do this using a well-crafted forensic examination protocol that obliges the other side to engage competent people, deploy them competently and afford reasonable transparency. The other side remains responsible for discovery until it’s clear they can’t be trusted. Then, follow up by asking the Court to appoint a properly trained and -certified neutral examiner. Seeking to compel access to an opponent’s digital media is a last resort and should be treated as an extraordinary remedy—a punishment for discovery abuse more than a tool of discovery.
I’m a tool guy. I pride myself on having the right tool for the task at hand. Digital forensics demands a broad range of specialized software, adapters, cabling, screwdrivers and spudgers. Yes, “spudger” is a real word. The forensic examiners I know enjoy swapping tool recommendations because often having the right tool to collect or parse electronic evidence means the difference between a quick victory or an agonizing series of defeats.
Delving deeper into the Alex Jones Discovery Debacle in a Law.com article bylined by Emily Cousins, I saw mention of Jones’ counsel passing around a “white hard drive” bearing no label or markings, nothing whatsoever advising the drive held privileged attorney-client records and court-protected documents.
After twenty-odd years as a certified digital forensic examiner and ESI Special Master, I’m custodian for countless hard drives and storage media holding sensitive data—media in all colors, shapes and sizes. One common thread across all is the adhesive paper label affixed to each. Arguably, the most valuable tool in my forensics lab is an 18-year-old Brother QL-500 label printer purchased secondhand from a clearance bin at Office Depot. The 1-1/7″ x 3-1/2″ labels it spits out aren’t as slick as the Mylar bar codes used in other shops, but they’re a quick, cheap and nearly idiot proof alternative. Leastwise, this idiot would be lost without them.
You’d be amazed how much information fits on a little paper label; but, even if it’s no more than a matter name and “PRIVILEGED AND CONFIDENTIAL – SUBJECT TO PROTECTIVE ORDER,” that might have proved sufficient to forestall the ugly spectacle of Jones’ Connecticut counsel invoking the Fifth Amendment at a disciplinary hearing.
In a similar vein, a five-cent paper label affixed to the back of a laptop or phone is an effective, low-tech way to remind custodians and IT personnel that the device is subject to legal hold before it gets wiped, discarded, sold or traded in. Is it ALL you need to do for a defensible hold? Clearly not, but shouldn’t labeling physical media be as much a part of your routine, prudent processes when handling sensitive media as it is part of mine?
I don’t do paper; but my paperless practice demands I keep track of and protect physical media. Encryption of contents plays a key role, as does a sound chain-of-custody; yet it’s the old-school paper labels that still save the day.
Brother no longer makes the QL-550, but sells suitable alternatives. Dymo markets a LabelWriter 550 that looks like my Brother’s twin brother.
Poring over Requests for Production this morning, I was gratified to see the client sought native forms of electronically-stored information; but the request said only, “All documents shall be Bates stamped and provided in native format.” Is that sufficient? To me, specifying forms of production is best done via an agreed ESI production protocol, but failing that, requesting parties should supply more detail than simply asking for “native format.” I believe requests need to lay out the forms sought for particularized types of ESI and specify the essential ancillary metadata to be produced in load files.
Requesting native forms in discovery demands a few adaptations versus the way hard copy documents were sought in years past. Take that request, “All documents shall be Bates stamped and provided in native format.” If a document is supplied natively and not printed out or “flattened” to a static TIFF, where do you “stamp” the Bates number? The solution is simple (in the file name and load file), but not obvious to lawyers unschooled in e-discovery.
Specifying more than “native format” in the request is sensible because much ESI doesn’t lend itself to production in its “true” native forms. The “true” native form of email is typically a database of multiple user accounts holding messages, calendars, contacts, to-do lists, etc. An opponent need not (and won’t) produce such a massive, undifferentiated blob of data. So the better practice is to specify preferred near-native forms be produced; that is, forms that preserve the integrity and utility of the evidence and support the granularity needed for discovery of only relevant, non-privileged material. As well, providing a load file specification ensures you obtain metadata values that only the producing party can supply (like Bates numbers, originating hash values, source paths and custodians). Too, you want that metadata in a structure suited to your needs and tools.
Native productions are more utile and cost-effective, but only to requesting parties prepared to reap their superior utility and savings. One reason why producing parties have gotten away with producing inefficient and unsearchable static image formats (TIFFs) for so long is because TIFF images can be viewed in a browser; hence, recipients of TIFF productions can read documents page-by-page without review software. Yet, that easy access comes at a perilous cost. TIFF productions are many times larger in byte volume than native production of the same material, making it significantly more costly for requesting parties to ingest and host the evidence. Moreover, TIFF images tend not to work well for common formats like spreadsheets and PowerPoint presentations, and don’t work at all for, e.g., video and sound files. Finally, evidence produced as TIFF images gets shorn of metadata and searchable electronic content, requiring that the stripped metadata and searchable content be produced separately and reconstructed using software to comprise, at best, a degraded “TIFF Plus” facsimile of the evidence.
For these reasons and more, requests for production must either succeed the entry of an agreed- or court-ordered production protocol or requesting parties must include useful and practical instructions about the forms of production right in the body of the Request.
To simplify my client’s task, I drafted an Appendix to be grafted onto the Requests for Production and suggested my client take out “All documents shall be Bates stamped and provided in native format” and substitute the phrase: “All production should be produced in accordance with the instructions contained in Appendix A to this Request.” It’s not perfect, but it should get the job done.
The Appendix I supplied reads as follows, and I don’t offer it as a paragon of legal draftsmanship. Each time I create something like this, it’s a struggle deciding what details to omit versus supplying all features of a full-fledged production protocol. I’ve kept it to about 1,000 words, and a tad verbose at that. It’s for you to decide if it adds substantial value over simply asking for “native format.” Tell me what do you think in the comments. If you’d like a Microsoft Word version of Appendix A to play with, you can download it from this link: http://craigball.com/Request_for_Native_Production-Appendix_A.docx
Appendix A: Forms of Production
I. Definitions
“Electronically Stored Information” or “ESI” includes communications, presentations, writings, drawings, graphs, charts, photographs, posts, video and sound recordings, images, and other data or data compilations existing in electronic form on any medium including, but not limited to: (i) e-mail, texting, social media or other means of electronic communications; (ii) word processing files (e.g., Microsoft Word); (iii) computer presentations (e.g., Microsoft PowerPoint); (iv) spreadsheets (e.g., Microsoft Excel); (v) database content and (vi) media files (e.g., jpg, wav).
“Metadata” means and refers to (i) structured (fielded) information embedded in a native file which describes the characteristics, origins, usage, and/or validity of the electronic file; (ii) information generated automatically by operation of a computer or other information technology system when a native file is created, modified, transmitted, deleted, or otherwise manipulated by a user of such system; (iii) information, such as Bates numbers, created during the course of processing documents or ESI for production; and (iv) information collected during the course of collecting documents or ESI, such as the name of the media device, or the custodian or non-custodial data source from which it was collected.
“Native Format” means and refers to the format of ESI in which it was generated and/or as used by the producing party in the usual course of its business and in its regularly conducted activities. For example, the native format of an Excel workbook is a .xls or .xslx file and the native format of a Microsoft Word document is a .doc or .docx file.
“Near-Native Format’ means and refers to a form of ESI production that preserves the functionality, searchability and integrity of a Native Format item when it is infeasible or unduly burdensome to produce the item in Native Format. For example, an MBOX is a suitable near-native format for production of Gmail, an Excel spreadsheet is a suitable near-native format for production of Google Sheets, and EML and MSG files are suitable near-native formats for production of e-mail messages. Static images are not near-native formats for production of any form except Hard Copy Documents.
II. Production
1. Responsive electronically stored information (ESI) shall be produced in its Native Format with Metadata.
2. If it is infeasible to produce an item of responsive ESI in its Native Format, it may be produced in a Near-Native Format with options for same set out in the table below:
Source ESI
Native or Near-Native Form or Forms Sought
Microsoft Word documents
.DOC, .DOCX
Microsoft Excel Spreadsheets
.XLS, .XLSX
Microsoft PowerPoint Presentations
.PPT, .PPTX
Microsoft Access Databases
.MDB, .ACCDB
WordPerfect documents
.WPD
Adobe Acrobat Documents
.PDF
Photographs
.JPG, .PDF
E-mail
Messages should be produced in a form or forms that readily support import into standard e-mail client programs; that is, the form of production should adhere to the conventions set out in RFC 5322 (the internet e-mail standard). For Microsoft Exchange or Outlook messaging, .PST format will suffice. Single message production formats like .MSG or .EML may be furnished, if source foldering data is preserved and produced. If your workflow requires that attachments be extracted and produced separately from transmitting messages, attachments should be produced in their native forms with parent/child relationships to the message and container(s) preserved and produced in a delimited text file.
Social Media
Social media content should be collected using industry standard practices incorporating reasonable methods of authentication, including but not limited to MD5 hash values. Social media and webpages should be produced as HTML faithful to the content and appearance of the native source, or as JPG images with a searchable, document-level files containing textual content and delimited metadata (including “likes” and comments)
3. Paper (Hard-Copy) documents or items requiring redaction shall be produced in static image formats scanned at 300 dpi e.g., single-page Group IV.TIFF or multipage PDF images. If an item uses color to convey information and not merely for aesthetic reasons, the producing party shall not produce the item in a form that does not display color. The full content of each document will be extracted directly from the native source where feasible or, where infeasible, by optical character recognition (OCR) or other suitable method to a searchable text file produced with the corresponding page image(s) or embedded within the image file. Redactions shall be logged along with other information items withheld on claims of privilege.
4. Each item produced shall be identified by naming the item to correspond to a Bates number according to the following protocol:
i. The first three (3) characters of the filename will reflect a unique alphanumeric designation identifying the party making production.
ii. The next eight (8) characters will be a unique, consecutive numeric value assigned to the item by the producing party. This value shall be padded with leading zeroes as needed to preserve its length.
iii. The final six (6) characters are reserved to a sequence consistently beginning with a dash (-) or underscore (_) followed by a five-digit number reflecting pagination of the item when printed to paper or converted to an image format for use in proceedings or when attached as exhibits to pleadings.
iv. This format of the Bates identifier must remain consistent across all productions. The number of digits in the numeric portion and characters in the alphanumeric portion of the identifier should not change in subsequent productions, nor should spaces, hyphens, or other separators be added or deleted except as set out above.
5. If a response to discovery requires production of discoverable electronic information contained in a database, you may produce standard reports; that is, reports that can be generated in the ordinary course of business and without specialized programming. All such reports shall be produced in a delimited electronic format preserving field and record structures and names. If the request cannot be fully answered by production of standard reports, Producing Party should advise the Requesting Party of same so the parties may meet and confer regarding further programmatic database productions.
III. Load Files
Producing party shall furnish a delimited load file in industry-standard Opticon and Concordance formats supplying the metadata field values listed below for each item produced (to the extent the values exist and as applicable):
FIELD
DEFINITION
CUSTODIAN
Name of person or source from which data was collected. **Where redundant names occur, individuals should be distinguished by an initial which is kept constant throughout productions (e.g., Smith, John A. and Smith, John B.)
ALL_CUSTODIANS
If deduplication employed, name(s) of any person(s) from whom the identical item was collected and deduplicated.
BEGBATES
Beginning Bates Number (production number)
ENDBATES
End Bates Number (production number)
BEGATTACH
First Bates number of first attachment in family range
ENDATTACH
Last Bates number of last attachment in family range (i.e. Bates number of the last page of the last attachment).
ATTACHCOUNT
Number of attachments to an e-mail.
ATTACHNAMES
Name of each individual attachment, separated by semi-colons.
PARENTBATES
BEGBATES number for the parent email of a family (will not be populated for documents that are not part of a family)
ATTACHBATES
Bates number from the first page of each attachment
PGCOUNT
Number of pages in the document
FILENAME
Original filename at the point of collection, without extension of native file
FILEEXTENSION
File extension of native file
FILESIZE
File Size
FILEPATH
File source path for all electronically collected documents and emails, which includes location, folder name, file name, and file source extension.
NATIVEFILELINK
For documents provided in native format only
TEXTPATH
File path for OCR or Extracted Text files
FROM
Sender
TO
Recipient
CC
Additional Recipients
BCC
Blind Additional Recipients
SUBJECT
Subject line of e-mail.
DATESENT (mm/dd/yyyy hh:mm:ss AM)
Date Sent
EMAILDATSORT (mm/dd/yyyy hh:mm:ss AM)
Sent Date of the parent email (physically top email in a chain, i.e. immediate/direct parent email)
MSGID
Email system identifier assigned by the host email system.
IRTID
E-mail In-Reply-To ID assigned by the host e-mail system.
CONVERSATIONID
E-mail thread identifier.
HASHVALUE
MD5 Hash Value of production item
TITLE
Title provided by user within the document
AUTHOR
Creator of a document
DATECRTD (mm/dd/yyyy hh:mm:ss AM)
Creation date
LASTMODD (mm/dd/yyyy hh:mm:ss AM)
Last Modified Date
The chart above describes the metadata fields to be produced in generic, commonly used terms. You should adapt these to the specific types of electronic files you are producing to the extent such metadata fields are exist in the original ESI and can be extracted as part of the electronic data discovery process. Any ambiguity about a metadata field should be discussed with the Requesting Party prior to processing and production.
Yesterday, I posted on the inadvertent production of privileged texts and other matter in the Alex Jones defamation trial. In the day that’s passed, the Austin, Texas jury returned a compensatory damages verdict of $4.1 million dollars, and minutes ago, assessed punitive damages of $45.2 million. More has come to light overnight respecting the lawyers’ errors, confirming what I’d only been able to speculate about yesterday. Now, I want to add a point about features of Texas law that very well could determine if there will be a mistrial or a new trial on appeal.
In yesterday’s post, I explored the Texas rules of procedure and evidence permitting a party who unwittingly produces privileged data to “snap back” that evidence by belatedly asserting its privileged character and demanding return (Tex. R. Civ. P. Rule 193.3 and Tex. R. Evid. Rule 511). I also touched on counsel’s ethical duty to notify an opponent who has mistakenly supplied material relating to a lawyer’s representation of a client (ABA Model Rule of Professional Conduct 4.4b).
Concluding yesterday’s post, I posed questions:
Was a new link to a collection scrubbed of privileged content ever supplied?
Why didn’t defense counsel promptly object at trial and protect the record?
Will we next need to discuss the crime/fraud exception to attorney-client privilege?
One of these now has an answer: Based on remarks of counsel at a hearing on Defendants’ Emergency Motion for Enforcement of Protective Order dated December 2, 2021 (filed August 4, 2022), the updated link promised was never supplied. Further, no subsequent assertions of privilege or other action pursuant to Tex. R. Civ. P. Rule 193.3 were made by Defendants. It appears the ball was dropped, prompting one to wonder whether defense counsel hoped he would wake up and find it was a bad dream (like–DATED REFERENCE WARNING–Pam seeing Bobby Ewing in the shower). In the run up to a high-profile trial, it’s more likely it just slipped through the cracks.
Since defense counsel Andino Reynal clearly didn’t expect the text messages to emerge at trial, it remains a conundrum why defense counsel failed to object when they came up and were shown to the jury. Take it from someone who spent decades trying cases in Texas courts and another decade teaching electronic evidence at Texas’ premier law school (whaddya mean “which one?“), when improper evidence that hurts your client is mentioned to a jury panel, let alone proffered for them to see, counsel must leap to his feet and assert a prompt, clear objection. There are exceptions to this, but any trial lawyer worth his salt understands the duty to protect the record by timely objection. Even if you’re loath to appear obstructionist by objecting, you nevertheless rise and say, “Objection. May we approach, Your Honor?” Then, quietly make your record at the bench.
This is rooky stuff: You protect the record by timely objection or waive grounds for that objection.
While I’m pointing fingers, I’m wondering why on Earth plaintiffs’ counsel Mark Bankston thought he could broach allegations of discovery misconduct in front of a Texas jury?!?
This point hasn’t come up in any reporting I’ve seen but the Texas Supreme Court takes a dim view of litigants airing the dirty linen of discovery abuse to jury panels. Texas’ approach is in marked contrast to Federal practice where judges let juries hear questions of spoliation. In Texas, as a matter of law, the trial judge determines whether spoliation has occurred and what sanctions to impose. Evidence of spoliating conduct is inadmissible in Texas. Brookshire Bros., Ltd. v. Aldridge, 438 S.W.3d 9 (Tex. 2014)
An argument can be made that spoliation is one thing and telling the jury that opposing counsel “messed up” and supplied documents meant to stay hidden is something else. Perhaps; but, I’ll bet my boots there was a pretrial order on a Motion in Limine barring mention of discovery disputes without first seeking leave of court. Too, the Texas Supreme Court’s concern that juries may be prejudiced by discussion of matters reserved exclusively to the Court’s determination would seem to hold true for telling juries that opposing counsel “messed up.”
There’s been a lot of digital ink devoted to lambasting defense counsel for his mistakes, but in his fervent (and understandable) eagerness to tag Alex Jones, it remains to be seen if Plaintiffs’ counsel overstepped and the whole damages phase must be retried. If so, UGH, just UGH!
P.S. I just noticed that plaintiffs’ counsel practices with a Houston firm with “Ball” in its name. That’s not me nor anyone in my family. No connection whatsoever.
Ball in your Court 