When it comes to metadata, is it a document or is it just data? This is a question often posed in electronic discovery. When you think of electronic documents you often think of the electronic file itself, such as an email or Microsoft Excel spreadsheet. However, each of these has a set of accompanying data that unto itself is a piece of evidence. The problem is that this underlying metadata is not a logical "document" per se, but more just a block of bits and bytes.
Why is this even a topic of discussion? Good question! As depicted in the screenshot associated with this article, a document is defined by Google as "a piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record." Given this definition, metadata is a document, as it can stand alone as a piece of evidence. The problem is that a lot of the metadata used in investigations was never meant to be printed to a sheet of paper, which is how the legal world often defines a document. This clash in definition creates confusion and obstacles when it comes to production of electronic evidence, specifically metadata artifacts.
Let's explore this using geolocation data as an example. Let's say you use a mapping program on your smartphone to get directions. In order to get those directions, you input an address and the application goes to work to locate where you are and then plot the best route to your desired destination. You see a street map with a marker, as well as a highlighted route. What the smartphone saves in the background is a longitude and latitude of your current location as well as the longitude and latitude of your desired destination. The map is dynamically retrieved using these coordinates. As you travel, the application is continually looking up your coordinates so that it can adjust the route accordingly, including updating the distance to your destination so that it may calculate your approximate arrival time. There is a lot going on here!
Furthermore, as you travel, you may have to adjust your route due to road construction or some other obstacle, such as slow traffic. By doing so the application has to perform additional coordinate lookups. These are often saved multiple times throughout this operation to a small database on your phone. How this all comes together is quite complicated and when you think about it, pretty impressive given the amount of data that is leveraged to make your commute more convenient.
Often times metadata relevant to investigations was never stored as a document (as defined by the legal community). Instead it exists as a data entry warehoused in a database for the computer operating system or application to use as a reference.
But what does all of this have to do with documents? Another good question, and the one at the heart of our problem! The coordinates saved by your phone are just a pair of numeric values. Well, they are more complex than that, but for simplicity sake we are focused on the "document" aspect of these values. If you asked someone to print them out, they would not provide much information without an actual map. Therein lies the problem. The map is dynamically retrieved by the application and not stored locally. Absent the originating program, the map must be regenerated by another process using the metadata.
Given this example, you now have metadata that by definition is a "document", but if you were to produce these coordinates in context of a litigation or investigation you would be left with a long list of X and Y values representing longitudes and latitudes. This is just on example of metadata losing context without the application. In this case, if you pair the coordinates with a map, you can quickly overcome the document obstacle, which begs the question, are the coordinates the document, or is it the map that is the document?
Often times metadata relevant to investigations was never stored as a document (as defined by the legal community). Instead it exists as a data entry warehoused in a database for the computer operating system or application to use as a reference. Computer forensic artifacts are a prime example. If you access a file or folder on your computer, or launch a computer program, you leave behind a trail of digital evidence. Each of these pieces, when paired with other digital artifacts, such as a text message, email or financial transaction, tells a story to a digital investigator. Production of these artifacts as a "document" was never the intent of the computer programmer, and their storage system was not designed for printing to paper.
Data visualization and timelines help solve this problem. Instead of looking at each piece of metadata as a separate document, it combines them into a visual story. Each metadata point is then examined as a whole in the context of the story, creating one succinct report that is more inline with the definition of an actual "document" designed for printing.
So when is a document not really a document? The answer is "it depends". Context of an investigation will dictate how each piece of metadata fits into the puzzle, and production formats of the associated metadata should be discussed early on in your matter in order to avoid the myriad of problems that can arise from the definition of a "document" in the context of litigation.
ESI Analyst helps overcome these problems by offering a suite of data visualization and metadata investigation tools that enable litigators to assemble clear and concise timelines and reports. Arrange a demonstration today to see how these tools can empower your investigations into the future of digital evidence.
© 2018 - 2021 ~ TIDAL CHANGE TECHNOLOGIES, INC. ~ ALL RIGHTS RESERVED