The question of how to handle “modern attachments” has become the hot topic that’s sweeping the ediscovery landscape this year. Major litigation involving Uber Technologies has led to extensive conversations on how to navigate ediscovery that involves hyperlinked files. Brett Burney breaks down the issue and explains what you can do to get ahead on this new data challenge.
Don’t look now, but technology is throwing another wrench into our familiar ediscovery processes. And this one is proving to be quicksand disguised as concrete.
For decades (centuries?) the legal profession has relied upon an orthodox definition of a “document” being a static, unalterable, trustworthy declaration in physical form. We made adjustments for the digital world and settled on the phrase “electronically stored information” (ESI) to accommodate producible evidence. The Federal Rules of Civil Procedure (and most state rules) list “documents, ESI, and tangible things” that can be targets for production requests in discovery. But the rest of humanity had other plans.
How do we describe a “document” that can be contemporaneously edited and modified, and is essentially a collaborative white-board in the cloud? There is no static “version” to land upon, so therefore it is difficult to capture all the edits into a convenient package for review and production. Fortunately, Judge Johnston in the DR Distributors opinion reminded us that “E-discovery is still discovery … The same basic discovery principles that work for the Flintstones still work for the Jetsons.” My only addition to this perceptive reflection is that we have to understand the different toolsets between chisels and lasers.
You’ve Got Mail! And (Maybe) Some Attachments!
Let’s turn to email, and specifically attachments. Email has long been the beginning focus of any data collection effort for discovery. Once people started using email to communicate, gossip, and transport files, it became the primary target for any production request. The ediscovery world was able to adjust many years ago to comprehensively and adequately collect both the email messages (parents) along with the attached files (children) so that entire “families” were collected together.
But why attach a file to an email message when you can simply link to it? Sometimes the file is so large that it won’t send as an attachment through a legacy server, so providing a link allows the recipient to download the file on their end at their convenience.
Or perhaps you want multiple people to collaborate on a document with you. When you send a “traditional” email attachment, you have a copy of the file on your computer, and subsequently your recipient downloads a copy to their computer. When they make changes and send it back, now there’s another two copies to track, and it multiplies from there. If you link to a document in OneDrive or Dropbox, then you can all work from a single instance of the file without juggling unnecessary copies of orphaned files.
This approach is much more functional, feasible, and is the inevitable future for digital collaboration. People will still use “traditional” email attachments just like some folks still seek out vinyl records, but convenience and accessibility will continue to drive us to the cloud.
Paperclips and Hyperlinks
So what do we call this new form of attachment? Suggestions so far include modern attachments, cloud attachments, linked attachments, pointers, hyperlinked files, and more. Perhaps the actual technical terminology shouldn’t matter as much as the “intent” of the person that is communicating – did the sender of the email INTEND to include a specific file as part of the overall communication?
If we consider the paper world (as we are prone to do), this would be the equivalent of a cover letter that references a report or memo, and all those documents are bound together with a paperclip. One would have difficulty arguing that the cover letter should be produced but not the referenced files. That’s why an email attachment has always been indicated by a paperclip – we intuitively know the email (cover letter) and attachments (clipped files) are to be produced together as a family.
But today we have emails that simply include a link to a file (the modern attachment), which is technically similar to including a hyperlink to a website or blog post. Hardly anyone is going to require a producing party to collect an entire website just because someone referenced the site in an email. This is why it’s necessary to consider whether the sender intended to link to a file that should be included in the family, thereby encapsulating a complete communication of correspondence.
It’s easy to recognize and gather “traditional” email attachments, but “modern attachments” are not so tidy. They require extra steps to collect, starting with an awareness of their existence and the temerity to maneuver through the potential evidentiary conundrums.
Modern Challenges with Modern Attachments
One of the reasons we like to refer to “modern attachments” is because over the years, the ediscovery industry has learned to competently deal with traditional MIME–associated attachments. We’ve streamlined the process of collecting everything in a nice, static package. That’s because these files captured a moment in time – we could collect an attachment and know that it was the exact version sent and received in the original correspondence.
But there are significant and unique questions associated with modern attachments. First, is there even a tool that can actually collect the linked files? Traditional email attachments are directly associated with the messages they’re attached to, but linked files are completely dissociated from the parent message and stored in a completely different location. Does that require a manual collection project? Microsoft now provides a checkbox for collecting “cloud attachments from items found in your search results,” but only for eDiscovery Premium subscribers (E5). Is there a good argument here for a burdensome collection or disproportional production request?
The more convoluted question is what version of the “modern attachment” should be collected, preserved, and produced? The amazing feature of files stored in the cloud is that they can be edited and modified in real-time so that multiple folks can collaborate on the document in tandem. Should we collect the current version as it exists as of the time of the production request? Or should we endeavor to rollback to the version that existed when the email was sent? And how does this affect the trigger for legal holds and preservation?
Hints of Guidance from the Courts
It’s always helpful to see how courts wrestle with unique and developing questions like this, and thankfully we have a little bit of high-level guidance so far:
Nichols, et al. v. Noom Inc. (S.D.N.Y. March 11, 2021)
One of the first opinions on the topic has been slightly snubbed because the court apparently chose not to recognize “hyperlinked documents” as attachments. But the onus was actually on the parties, since the court stated, “Notably, the ESI protocol negotiated by the parties and later entered by the Court does not state hyperlinked documents are part of ‘family groups.’”
That simply means the parties either ignored this component or purposefully chose to overlook it because they didn’t want to go through the task of collecting and producing the hyperlinked files. Notably, the protocol did request that the defendant must collect from both Gmail and Google Drive, but the specific issue of “modern attachments” was not addressed.
Read the full decision on eDiscovery Assistant
In Re Acetaminophen (S.D.N.Y. January 17, 2023)
This order provided an example of an ESI protocol that explicitly described “email attachments” and embedded files as “modern attachments.” It further described them as, “hyperlinks pointing to files stored in the cloud or a shared repository such as SharePoint … instead of being directly attached to a message as has been historically common with email communications.” At least here, the legal obligation had been addressed which the court could reference, but that obviously didn’t provide a lot of details to navigate the technical challenges and hurdles.
Read the full decision on eDiscovery Assistant
In re StubHub Refund Litigation (N.D. Cal. April 25, 2023)
Another ruling in favor of the requesting party for “modern attachments” because the language in the ESI protocol specifically addressed the issue.
Read the full decision on eDiscovery Assistant
In re Uber Technologies, Inc., Passenger Sexual Assault Litigation (N.D. Cal. April 23, 2024)
In the Uber Technologies case, the technical challenges loomed large. The court learned that “Google Vault does not export, collect, or connect the contemporaneous versions of hyperlinked documents with the corresponding emails or messages in which they are found,” so this posed a dilemma that both parties tried excruciatingly hard to resolve. We did receive a judicial acknowledgement and definition of modern attachments, although Judge Cisneros stopped short of imposing the full duty to collect and produce them:
“‘Attachment(s)’ shall be interpreted broadly and includes, e.g., traditional email attachments and documents embedded in other documents (e.g., Excel files embedded in PowerPoint files) as well as modern attachments, pointers, internal or non-public documents linked, hyperlinked, stubbed or otherwise pointed to within or as part of other ESI (including but not limited to email, messages, comments or posts, or other documents). This definition does not obligate Uber to produce the contemporaneous version of Google Drive documents referenced by URL or hyperlinks if no existing technology makes it feasible to do so.”
Picking Up Scattered Paperclips
At this stage in the wild journey of modern attachments, we have three main beacons to guide us in how to manage the current and coming chaos:
1. Education and Competence
Reading posts like this already puts you on the right path to at least recognizing the existence and challenges of collecting and producing modern attachments. The education part includes understanding the capabilities of cloud storage platforms (e.g. Dropbox, OneDrive, Google Drive, etc.) as well as administrative suite tools including Microsoft Purview and Google Vault.
2. Sharing and Conferring
If you learn your client is actively linking to files from email and collaboration platforms, that’s something you can share with opposing counsel in discovery discussions. Likewise, it’s important to address whether the opposing party is linking to files so that can be adequately addressed and requested.
3. Crafting a Comprehensive ESI Protocol
All those discussions should then be incorporated into a formal agreement or ESI protocol that can be filed with the court and leaves no open questions for parties during production.
Most of us are confident that ediscovery processes and tools will catch up with society’s preference for the flexibility and convenience of linked files, but it will obviously take time. The best strategy right now is to simply stay educated and aware – ignoring the issue will not solve anything. As Craig Ball recently stated on the topic, “waiting until the crisis stage to begin thinking about how to deal with [modern attachments]” is a poor choice.
If you need assistance in addressing modern attachments, feel free to reach out to the resources at Nextpoint and Nextpoint Law Group – we’re here to provide competent guidance for the thorny discovery issues that you’re required to navigate. In the meantime, check out our ESI protocol checklist to help you create comprehensive protocols that address the complex questions of ediscovery like modern attachments.
★ More on Modern Attachments in eDiscovery
Nextpoint hosted a webcast on the issue of modern attachments in partnership with EDRM, featuring speakers Brett Burney, Doug Austin of eDiscovery Today, and Kelly Twigger of eDiscovery Assistant. The panelists held a thoughtful conversation that dove deep into the legal and technical questions at play, and they offered insights for navigating the complex challenges surrounding modern attachments in ediscovery.
