The following is Part IV in a multi-part series on issue spotting in ediscovery. Being able to identify the issues with existing and any potentially lost data early in your case allows you to understand risks and craft an appropriate strategy for dealing with your client’s data, and what you need to request from the other side and third parties. Each type of data has its own issues to consider, and this series will highlight some of those issues and how you should factor them into your discovery strategy for a matter. Part I in the series, How and When to Start covered understanding the big picture and creating a discovery strategy. Part II in the series, Social Media discusses the unique issues to be considered when social media is implicated in discovery. Part III on Photos and Video talks through the considerations you’ll want to focus on when dealing with those types of data.
Texting and instant messaging have become the new email, especially in personal communications, but increasingly in business communications too. Whatsapp messages, text messages and other instant messages were identified and used as evidence in the impeachment proceedings in 2020, and showed detailed exchanges between witnesses leading to the firing of the US Ambassador to Ukraine. We are seeing the use of these platforms as evidence in every kind of case as employees work to communicate fast and furious on issues after the duty to preserve has arisen.
Whether your custodians are using iMessage, WhatsApp, Facebook Messenger, Signal, Yammer, Teams, Slack or any other application that allows for the sending of text or instant messages, you need to be thinking about them in advance of asking for them or providing them in discovery. There are several unique considerations for these types of data that you will want to factor in during your planning.
Location, Location, Location
First, an understanding of each of the various platforms is key, as each one operates differently in how and where information is stored and how you can go get it. For example, text messages are generally only available on the device that they are sent from and the device receiving the text. That means if I send a text to you right now, that text message is available on the device I send it from and the device on which you receive it. That is complicated if your custodian uses a service like iMessage and perhaps receives their text messages on multiple devices. Apple allows a user to connect their phone number that sends and receives texts to an iPhone, iPad, multiple computers, etc. Basically, anywhere you can log in with your Apple ID, you can connect your text messages. That matters because if a phone is lost, which happens regularly, and text messages need to be preserved, you may be able to find them on another device.
The overriding point for preservation and collection of text messages is that they are NOT kept by the service provider — AT&T, T-Mobile, Sprint, etc. There is some legislation out there to try and allow for that capture by the telecommunications provider, but it’s limited to specific circumstances in a criminal context that will not be applicable in civil discovery. The only information those service providers can give you are the timestamps of messages and the recipients.
Other instant messaging services like Slack and Teams are stored at the server level and can be accessible from an admin console instead of individual devices. Both services (and others) allow for a user to view messages and act upon messages on laptops and mobile devices, but manage the communications on a server platform so that preservation and collection can be done without access to the devices.
Know where information lives for each of your sources of ESI in this realm and what access you need to go and preserve and collect messages.
Format
Once you know where the messages live and how to get to them, you need to consider the format for collection and review. This again varies by platform.
There are three primary considerations here 1) making sure the messages correspond to a person’s name or account, versus by phone number, 2) making sure the messages appear in a format that the person to whom evidence is submitted will recognize and 3) collecting messages in a way that allows them to be full text searchable during review.
The first item — making sure the messages correspond with a person’s name or account — is key. Because Whatsapp, text messages, Signal and other services are all tied to a user’s phone number, if the name of the user is not in the device that you collection messages from, you’ll only receive the phone number versus a witness name when the message string is produced.
I’ve received text strings and whatsapp messages produced in redacted pdfs that include up to ten people on them, all identified by phone number, with no corresponding list of phone numbers to assist in identifying who said what to whom. This can be an incredibly difficult issue to deal with after production, as the producing party can argue that producing in pdf format to preserve the visual nature of these messages is reasonable. And without metadata (i.e. phone numbers in the correct field), there is no way to assign a name to a phone number in a review platform to allow that data to be searched and filtered by a custodian’s name. Instead, that metadata has to be manually coded for each text string, a very painful process that is not easy, because you don’t have the names to code. Seeing the problem? I can’t sort by John Doe’s text messages across ALL collected texts from multiple custodians because John’s name does not appear in the metadata. Yes, you can full text search, but it will be ugly.
So what is the solution? Negotiate having all messages be collected after user names are entered into the device they are collected from, OR request data in two formats — pdf and csv. The CSV format will generally allow you to upload specific fields to metadata fields that you customize in your review platform. However, in order for the pdf view of that string to be attached, you’ll have to upload it as the image to the record. Redactions can then be made on the pdf image, and the redacted image can be produced with the corresponding metadata from the CSV. It’s a complex process, so you have to think about it up front.
The second piece on Form — having a format the trier of fact, mediator, special master, judge, etc. will recognize — is critical so that the reviewer follows the content of the string and does not lose focus trying to follow how messages fit together. For example, a Celebrite image of a mobile device that collects text messages dumps them onto a spreadsheet (think Excel) with no display of the messages the way you are used to seeing them. Most will use a separate program to load the Celebrite file and allow for a re-creation of the visual. If you can skip that step, and just get both the pdf and the csv formats up front, you won’t have to explain your process if questioned and you won’t have to find a second solution to re-create the visual.
Slack is becoming a more popular form of evidence and the export from Slack is a JSON file that requires a separate tool to put it back together. Using a collection tool that already provides you with a viewable file that appears just as it does in Slack saves a step. Alternatively, some review programs have started adding viewers to their toolkits to allow the loading of the JSON files directly that lets you see the Slack strings or channels as they would appear in the platform.
The third piece on Form is again about planning — making sure that you will be able to search and filter the data you receive from IM and text messaging applications. This goes hand in hand with the other two items listed here, but focuses specifically on the ability to search and filter for these types of data within your review platform. Often, you’ll need to come up with specific metadata fields for a platform and include them in your list of metadata fields in your ESI protocol. That requires knowing the sources of ESI prior to negotiating the protocol and thinking through exactly what you need and how you’ll use the data. At a minimum, you’ll want to assign a custodian to data as well as the To/From fields, and make sure that the full text is searchable. OCR is always a possibility, but not as accurate as getting the full text of the string in a csv that is loaded and can be searched.
Retention/Deletion Policies
There are two issues with retention/deletion of these forms of data — user behavior and platform behavior.
Like all ESI, preservation of data on these platforms is in the hands of the user, so you need to be actively pursuing identification and collection of data as soon as your duty to preserve arises. Similarly, if you know that custodians at an opposing party will have data in these sources, you will want to include them in your preservation letter to the other side early. Once data is deleted by a user, restoring it can be expensive or impossible.
Each platform behaves differently in how long data is stored, the length of time data is kept after being deleted by a user, and what can be restored. I could devote a post to each platform’s policies, and we’ll plan to do that as we address each in the Sources of ESI section of eDiscovery Academy, launching this summer. If you are interested in learning about that resource, let us know here.
Finally
Instant Messaging and Texts are in almost every kind of litigation today, and planning for them in your ESI protocol and considering the unique features of each platform is critical to getting evidence that you can use effectively. Start experimenting with collecting your own data to see what lives there and how it loads into a platform — learn what you need to know BEFORE you have data in a case. Failure to do so can risk sanctions for failure to preserve or additional costs in needing to manipulate data because you received a form that is reasonable, but not necessarily useful.
