Episode 109: Want a Great Example of How to Plan for Hyperlinks as Attachments in Your Protocol? Read On.

In Episode 109, our CEO, Kelly Twigger, goes through the latest decision to look at hyperlinked attachments and why you need to know what you’re dealing with BEFORE you agree to an ESI protocol.

Introduction

Welcome to this week’s episode of our Case of the Week series brought to you by eDiscovery Assistant in partnership with ACEDS. eDiscovery Assistant is a SaaS based legal research platform and knowledge center for lawyers and legal professionals, and it is the only legal research database devoted exclusively to eDiscovery case law.

My name is Kelly Twigger. I am the CEO and founder at eDiscovery Assistant, as well as the principal at ESI Attorneys. Each week, I pick a case from our eDiscovery Assistant database and talk about the practical implications of that decision for you, your clients, and your practice.

Before we dive in, if you haven’t yet had a chance to grab our 2023 Case Law Report, download a copy of that for your perusal. Each of the decisions in eDiscovery Assistant is a public link, meaning that you can link to those decisions in your writing. You can also review the full text of the decision without having a subscription to log in.

Background

This week’s decision is from in re StubHub Refund Litig. This is a decision from April 25, 2023 from United States Magistrate Judge Thomas Hixson. If you are familiar with Judge Hixson, you know that we’ve covered a number of his decisions on the Case of the Week. He is in the Northern District of California, which is a hotbed for high profile litigation, particularly in class actions, and this one is no different. Judge Hixson has 98 cases decisions in our eDiscovery Assistant database, making him one of the top ranked judges for eDiscovery case law. And as always, his decisions are thoughtful.

Facts and Analysis

This is a very short decision, so we’ll mix the facts and the analysis together. We are before the court on a motion to compel by plaintiffs in a class action. The issue before the court is StubHub’s failure to provide attachments for emails for documents that were linked within the email but were not physically attached. This is the issue that we first saw in Nichols v. Noom in 2021, but unlike in that case, where there was no written agreement about how to handle hyperlinked documents, the parties’ language in this ESI protocol included language to deal with that situation. The protocol reads in part:

Email repositories, also known as email databases (e.g., Outlook .PST, Lotus .NSF), can contain a variety of items, including messages, calendars, contacts, tasks, etc. For purposes of production, responsive items should include the ‘Email’ metadata/database fields outlined in the Metadata Table, including but not limited to all parent items (mail, calendar, contacts, tasks, notes, etc.) and child files (attachments of files to email, hyperlinks to internal or nonpublic documents, or other items), with the parent/child relationship preserved. Similar items found and collected outside an email repository (e.g., .MSG, .EML, .HTM, .MHT) should be produced in the same manner.

 A document and all other documents in its attachment range, emails with attachments, and email or other documents together with any documents referenced by document stubs or via links to internal document sources within those emails or other documents all constitute family groups. If any member of a family group is produced, all members of that group must be also be produced or else logged as privileged, and no such member shall be withheld from production as a duplicate. Hyperlinked files must be produced as separate, attached documents.

That language is incredibly important and something that you’re going to want to note for drafting your protocols going forward. It covers all of the areas that you want to see in terms of issues with hyperlinks or stubs or other ways that documents are referenced within an email but are not physically attached.

Plaintiffs brought this motion after receiving documents and identifying an estimated 800 emails in which searches contained hyperlinks but had no corresponding attachment, meaning that StubHub did not do its production, or its collection prior to production, in compliance with the language of the protocol. The full scope of the lack of production of attachments was not known because the Plaintiffs stated that it was impossible to identify the missing linked documents from StubHub’s production without reading each document individually.

StubHub’s position in response is pretty much “all over the board”, and that’s the court’s exact language. StubHub indicates that it ran search terms on Google Drive and produced responsive documents to the plaintiffs, which, if you’re familiar with Google Drive or the decision in Nichols, you know, is the exact opposite of what the protocol language here calls for.

The Court notes that StubHub did not preserve the parent-child relationship as the protocol requires. Plaintiffs have a bunch of emails and a bunch of documents, but, “they can’t tell what document was linked to what email”. That language from the Court is very important because it is the opposite of what Judge Parker found in Nichols v. Noom.

Further, the Court notes that even though their Joint Discovery Letter brief raised documents stored in SharePoint and Tableau, StubHub did not search for responsive documents in those repositories to find the linked documents. The Court then notes specifically that as to Google Drive, StubHub offered multiple explanations for why it was hard to locate the linked documents — maybe the document was moved to a different place, maybe encryption methods had changed, rendering the links untraceable. They then added additional problems about loss of personnel, a change in document systems, and the difficulty of versioning in Google documents. StubHub did acknowledge that it doesn’t really know why they were unable to produce most of the links. They offered to meet and confer with the plaintiffs, and if there are any particular emails that plaintiffs considered important, StubHub could try to find the linked documents. That’s where StubHub lies.

The language from the court following those positions is as follows, and I love this language. It is what I preach each week here on the Case of the Week, and it is so crucial, I want you to copy and paste this language. If you’re in litigation support, I want you to send it to your attorneys. If you’re in-house counsel, I want you to send it to outside counsel. If you’re outside counsel, I want you to send it to in-house counsel as to why you need to get ahead of these issues before litigation starts. Here’s the language:

Let’s get back to basics. Litigants should figure out what they are able to do before they enter into an agreement to do something. Litigants should live up to their agreements, especially when they are embodied in court orders, as the ESI protocol is here. And if for some reason a party learns that a so ordered discovery agreement has become impossible to comply with, the party should promptly move for relief with a good showing that despite its best efforts, compliance is impossible. In this case, StubHub has decided to do “none of the above”. Its document production is in violation of the ESI protocol, StubHub hasn’t done everything it could, it hasn’t moved for relief from the protocol, and it hasn’t settled on a clear story for why producing the linked documents can’t be done.

Following that language, the Court finds that the best approach is to hold StubHub to its agreement to produce documents linked as attachments, and order StubHub to produce those documents by the pre-established production date (that is not mentioned in this decision). According to the Court, if StubHub fails to do that in any way, within 14 days after production, StubHub must produce a 30(b)(6) witness with full knowledge of everything StubHub and its vendors did in attempting to produce linked documents as attachments required by the ESI protocol.

Takeaways

What are our takeaways here?

The decision from Judge Thomas Hixson is pretty clear — if you negotiate a protocol on how to handle and produce ESI, the courts will enforce it, and they will hold you to its provisions. Don’t agree to anything in a protocol unless you have the tools in place to make sure that you can comply. In this instance, although it’s not widely discussed in this decision, StubHub didn’t use a tool from Google Mail to collect. They probably used Google Mail’s collection tool, but they didn’t use a tool that allowed it to gather the documents that are referenced in the emails by hyperlinks from Gmail.

The Noom case specifically listed the tool that is commercially available to perform that task. So, there’s really not an excuse that I can see here for StubHub not to have it. If you are a service provider, law firm or a consultant, or anyone who’s offering collections as part of your capabilities to clients, you need to have a tool in your arsenal that will capture the documents that are linked, contain stubs, whatever the technology is that requires that you be able to keep the attachments with the original email.

This really appears to be a case of attorneys signing off on a protocol without supervising collection and review or without even knowing what the implications are of the particular sources of ESI at issue. Kudos to the plaintiffs for including well thought through language in the protocol. And who knows? I don’t know — maybe that’s even something defense counsel negotiated, but it seems off that they would negotiate that language and then not provide for it within the productions.

Beyond the protocol, this decision and more recent case law on Google Mail and Teams make it very clear that in-house and outside counsel need to understand the sources of ESI at issue with a client and have a plan for collection, review, and production of that material, including the hyperlink issue that is raised here. We are seeing additional metadata fields that are needed, additional collection issues, production issues with context around instant messaging, and so on and so on. All of those are happening in the case law. This is getting harder — not easier — and you need to get prepared.

Conclusion

That’s our Case of the Week for this week. Thank you so much for joining me. We’re back again next week with another decision from our eDiscovery Assistant database. As always, if you have a suggestion for a case to be covered on Case of the Week, drop me a line. If you’d like to receive the Case of the Week delivered directly to your inbox via our weekly newsletter, you can sign up on our blog. If you’re interested in doing a free trial of our case law and resource database, you can sign up to get started.

Thanks so much, and have a great week.