As I discussed last week, Kevin Clark, Litigation Support Manager at Thompson & Knight LLP, submitted two terrific topics that I not only thought would be great to cover on the blog, I also decided to get Craig Ball’s perspective on both of them.  In last week’s post, he discussed the considerations associated with embedded graphics in emails.  Today, he discusses considerations associated with links to files in emails.

My statements/questions to Craig regarding links to files in emails was as follows:

We’re also seeing more links within emails in lieu of attachments.  Often those are links to files stored in OneDrive or SharePoint, but they could be other sources which may or may not maintain an edit history and may or may not still be available.  I think that production of the sources (including third-party cloud sites like Salesforce or Twitter) comes down to “possession, custody and control”, so links to sites and sources where you’re in control of the data need to be preserved/produced.  But what happens if the source you link to has been changed since it was linked?  If that was after the duty to preserve began and it’s been changed, that’s spoliation of data.  But if it was before that duty, but after the linking to the source – and a maintenance history isn’t kept (e.g., deleted file in Sharepoint, deleted tweet, changed report in Salesforce) – then what?  You lose the ability to know what that source looked like at the time it was linked.  Attachments are static, linked files are not.

We’ve always had the possibility that some linked data can’t be produced as it’s no longer available (especially to third party sites out of the production party’s control).  But it’s never been an extensive issue up to now.  Do you see a potential problem here as more organizations link to sources of ESI instead of producing them as static attachments, increasing the risk that that version of the file won’t be there at litigation time?

Craig’s response:

I ran into this several years ago in a case where responsive emails linked to “attachments” in a Google Drive repository controlled by the producing party.  You see this a lot when an attachment is larger than Gmail’s 25MB limit.  The links supplied were cypher strings giving no clue as to the filenames of the target files and “dead” to anyone without access rights, which the producing party were understandably dead set against giving my clients.  

I should add that we had many documents they’d collected from Google Drive; we simply lacked the means to pair the obscure hyperlinks in the transmitting messages with the targeted files.  The Rosetta Stone to accomplish the pairing lay with the producing party, who threw up their hands claiming there was nothing they could do to fix it without re-collecting and -processing. 

The requesting party approached me to figure out a solution.  I responded:

1. E-mail message bodies were produced, and these messages transmitted “attachments” that, because of large file sizes or system configuration, were supplied only as inactive links to downloadable files in Google Drive rather than by embedding the attachment.  Accordingly, all the plaintiffs received were hyperlink pointers to files the Plaintiffs lack privileges to retrieve and where the name of the linked file cannot be determined.  Again, all we have are pointers to ciphernames of linked files, not the files themselves (leastwise not so we can pair a loose file with its attachment link).  When loose files were supplied, their cipher names were NOT supplied making it impossible to link a message with its referenced, linked attachment.
2. Unless the messages are re-collected using a proper method that retrieves both message body and attachment and preserves the parent-child relationship, the only data point linking the two is the cipher text link address contained in the transmitting message but not currently paired with the file’s name.  However, if the fully qualified names of the linked attachments could be paired with each attachment’s ciphertext “link” name, then a pairing of parent transmitting message and “attached” linked file might be achieved.
3. Generating a file listing that pairs a file’s fully-qualified name in Google Drive with its hyperlink is a straightforward task that can be achieved by either a few lines of scripted code in Google Drive or by use of a free Google Webstore app called download-link-generator. 

Was I right?  I believe so, but the other side declined to test the solution.  Perhaps, they were suspicious of a fix being cheap and easy (and proffered by the other side) when their vendor claimed it required a costly do-over.

My case was easy because there was a simple, post hoc fix.  More often, you must collect the messaging using a method that retrieves linked attachments and preserves the parent-child relationship with the transmitting message. Indeed, it’s an issue of care, custody and control.  The party obliged to collect and produce the messages and attachments isn’t relieved of that duty because they’ve stored their data in a cloud repository anymore than a party who stores records in a rented office may do so.  They have a legal right and the practical ability to access the evidence.

If a link to a third-party target file is dead before the duty to preserve attaches, it’s dead.  If the legal right and practical ability to reach the target item was extinguished before there was an opportunity to repatriate the linked data, where’s the culpability?   But we cannot break live links to evidence carelessly and belatedly, then expect there will be no costs or consequences. 

Linking to dynamic documents is always going to be a hard problem to resolve because it goes to the authenticity of the evidence.  By what theory are linked items only discoverable as they existed at a past moment in time?  The “attachment” was not a static document; it was a link enabling access to a dynamic document expected (or, at least, permitted) to change over time.  How is that link any less discoverable–or its linked, dynamic target less relevant or authentic–because it has changed over time?  That’s a hard question to address in the abstract.  If a producing party wants to restrict access to one iteration at one moment in time, then shouldn’t they preserve that version?  Else, by failing to act in a timely way or track revision histories, should the producing party gain the privilege to supply no version at all? 

Some might say that the potential that a linked file may have changed since it was transmitted is just too bad.  Maybe it’s spoliation; maybe not.  That’s a fact-based, case-specific inquiry.  It’s not as though we haven’t always faced similar challenges when dealing with a party’s sloppy records and information management. 

The answer works out to, “Do it right or prepare to do it again.”

In the final analysis, the problem can often be more-or-less solved after-the-fact, but it’s tedious and expensive to do so.  We have the tools that can download the linked items if we act to do so in a timely and diligent manner; but parties tend to rely upon old workflows born from 1990’s-era POP3 mail, and we have the Streetlight Effect where they collect from a source where it’s easy even if it’s the wrong source.  If judges don’t kick some ass, parties will never do better than old tools and obsolete workflows. 

Thanks again to Craig for that response and to Kevin for the topic suggestion!

So, what do you think?  Do you agree with Craig on considerations for links to files in emails?  Please, be like Kevin(!) and share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by my employer, my partners or my clients. eDiscovery Today is made available solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Today should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.