July 11, 2013
by Wade Peterson, Director of Practice Support, Bowman and Brooke LLP
This article illustrates a sample ENF (encapsulated native file), describes some of the elements within it, and describes the operation of a very basic utility to view ENF files (viewENF). The purpose of this article is to continue the discussion of the ENF standard, which was proposed in the previous article “Are Native File Productions ENF (Enough)”.
The ENF standard is a new, proposed standard for the production of native files; using an encapsulation concept to self-contain a single native file (or multiple files for a family of email and attachments), along with metadata, and security features into a single deliverable file. Native files are delivered on a one-to-one basis as ENFs. The contained native file is forensically the same as the original native file, stored in encrypted form, within the ENF. Security and metadata features augment the native file, to render it viewable by the viewENF program, overlaying endorsements and redactions, as well as other “vendor enhancements” as needed. Security features are built-in to allow (or prevent) export, printing, and viewing of certain features.
This article will also point out some areas of concern that will need to be addressed for full adoption of ENF as an industry standard.
- Latent content
- Original native file corruption and encryption
- Hidden content
- Native compound documents
While there is much work needed to define a complete standard for ENF files, we can begin to illustrate some of the basic elements to guide other’s thinking about additional features to include in the standard. Illustrated below is one sample ENF file content.
Full ***** false false true false Optional Optional 12345 true Watermark Arial Bold Grey Right -45 100 100 top layer 0 Center 0 Center All Pages CONFIDENTIAL BottomLeft false 0.25 Arial 10 ENF-000001 BottomRight false 0.25 Arial 10 ENF-000001 Can Native File Productions be ENF (Enough).docx C:\Users\wpeterso\Downloads\ENF\Docs\ 2012-01-24T00:00:00 2013-06-29T10:36:39.3824887-05:00 69658 docx 3619cf376e04036cc35958a948018125 Wade Peterson subject keywordscategory status comments This is a test attorney comment. REDACTION 1 1 69 392 205 381 REDACTION 2 1 276 589 305 578 UEsDBBQABgAIAAAA…
As we can see, the above is an XML file containing multiple elements. The basic elements are described below.
Attibutes
This element describes the system attributes of the ENF file. Contained within this element are the encrypted passwords for (a) accessing the actual native file; and (b) one or more passwords to access various features within the viewENF utility.
Vendors
The ENF standard is open-ended, in that the specification allows for additional features to be included by vendors to support enhancements to ENF files. Vendors would need to be assigned an industry identification tag to differentiate their features from other vendor features.
Two enhancements are illustrated here. Specifications are shown in this sample ENF to add the ability to watermark the native file, and the ability to apply endorsements to the native file.
Neither the endorsement nor the watermark are “burned into” the native file (unlike a TIFF or PDF file), they are instead overlaid on top of the rendering of the native file in the ENF viewer. Security rights in the Attributes element may specify whether or not these features are burned into any renderings saved or printed from the viewer. Exporting the original native file itself, would not of course include burning in watermarks or endorsements, but exporting is limited by security rights.
Other vendor enhancements might include the ability to annotate ENF files, apply issue codes, add attorney and deposition notes, etc.
Native Files
nThis element is the heart of the ENF, and may be repeated one or more times (e.g., in the case of an ENF encapsulating an email and its family of attachments). The element contains three sub-elements in our sample.\r\n
- MetaData – these include the extracted metadata fields of the native file, commonly done with ESI processing tools such as LAW PreDiscovery, IPRO, NUIX, etc. In this sample, I have included three sub-elements for (a) file properties; (b) document properties; and (c) extended properties for an “Attorney Comments” field added during a document review. In this example, the document properties are the standard Microsoft Word document properties.
- Redactions – this element may be repeated one or more times and is included here rather than in the Vendors element since it is such a common occurrence in production files and most people would consider it part of the standard, rather than a vendor enhancement. The redaction shown here includes the minimum requirements for placing a redaction over the native file view. Other attributes may include the font, color, positioning, and min/max point size of the redaction tag text.Redaction coordinates will be highly dependent on the viewer code. Translation of various document review platform redaction coordinate architectures will be needed to come to an agreement on a standard for ENF redaction coordinate conversions. The placement of redactions over a native file view will also be critical. Since most native file viewers use a browser window to render the representation of the native file, the redaction overlays will need to “float” yet remain statically over the intended redaction position. As the browser or viewer application window is resized, the redaction overlays must be re-sized in perfect synchronization. As the user scrolls the native view, the redactions, again, must move perfectly in sync. Techniques for layering the HTML will need to be developed as I consider this to be a critical component of widespread acceptance of redactions within the ENF standard. Other techniques for incorporating redactions in a viewer will need to be investigated.
- EncodedFile – since a binary file (in its native form) cannot be contained within an XML file as is, the binary file must first be encoded to a “base64” string before inclusion. That base64 string can then be encrypted using a variety of standard encryption mechanisms. The viewer would first unencrypt the base64 string, and then convert it from base64 to binary to display it with the viewer.
While the above example is just an early sampling of an ENF, it does provide enough background for further discussion, debate, and refinement.
Areas of Concern
I mentioned above a few areas for concern when dealing with native files. While some people will debate the merits of producing native files over other forms of production, these concerns must be dealt with. They must be dealt with even outside the scope of an ENF specification.
Original native files do contain flaws. Litigation support professionals and the ESI processing tools they work with have long struggled with how to deal with these flaws. Through diligent processing, years of technical expertise, and thorough QC processing steps, many of the flaws of native files are fixed, or adjusted before being placed in front of the eyes of the reviewers.
I will illustrate just one example of a native file flaw, as there are countless numbers of them. But, when and if the production standard becomes native files; decisions will need to be made on how to deal with them.
As an end user, I often will take a preexisting document and begin drafting a new one. It’s always better to start with something, than with nothing I always say. Let’s take a Microsoft PowerPoint file for example. I find a previous one I’ve used that has the color schemes, slide layouts, fonts, etc. that are pleasing to me, and I begin by making a copy of it, open it, and then delete all the previous slide information to begin my authoring. I add totally new content, new slides, add a few graphs and images to enhance from the one before, I check my work, do my final edits, and then dutifully email it off to my manager for final approval. We are then hit with a law suit, and the ensuing discovery includes my email and my new PowerPoint.
But – is this really a new PowerPoint? I have encountered situations where a PowerPoint not only contains the new content, but also the old content since internal to PowerPoint files, Microsoft uses a slide access table much like a file allocation table (FAT) used to manage disk storage space. The old slides, while I may have thought I deleted them, still may exist somewhere in the basement of my new PowerPoint file. A good ESI processing tool will find every piece of evidence it can from a native file – including the boxes in the basement.
If a metadata cleaner had not been used on that new PowerPoint file, the basement would essentially still be a cluttered mess. Now the question becomes – do we produce that native file (including the boxes in the basement) or do we metadata clean it before production? If the former, we risk exposure of non-pertinent (and perhaps even confidential information). If the latter, we risk spoliation of the original native file, as kept in the ordinary course of business.
Historical production of native files in a “rendered version” (such as TIFF or PDF) conceals those boxes in the basement, and no one knows you’re a hoarder in real life…
Again, this is meant to illustrate only one example of dealing with native file productions. I am sure there are many more and some far worse than this. And, while this doesn’t relate directly to an ENF standard, consideration of these issues should be undertaken.
viewENF
Now that we have a sample ENF, what do we do with it? No viewing tool today knows how to deal with it. As a proof of concept, we developed a very basic viewing tool, which we call “viewENF” (view enough is intentional). The tool essentially reads the ENF XML stream; converts the base64 string to the original native file; displays the metadata information; and renders the native file using the popular viewer Quick View Plus (from Avantstar). QVP can be incorporated into an application via a command line mechanism to control certain elements of QVP or embedded as a web browser control. The native file is displayed in a browser window inside the viewENF application.
Screen shot of the viewENF application:
Obviously, this is just a proof of concept utility to illustrate viewing an ENF file. A more robust viewer will need to be developed to incorporate all the elements in our sample, as well as others that become part of the specification. As I mentioned previously, overlaying the redactions on top of the QVP view, and keeping them in sync as the window is resized and scrolled, will be complex code.
Summary
I have attempted to illustrate an ENF file and some of the basic elements it requires. This is not an exhaustive list by any means. It is meant to give clearer meaning and a visual representation of what the theory of ENF is all about. My hope is this will spur additional conversations, debate, and a refinement of the ENF specification and ultimately be adopted by litigation support professionals and courts as a new standard for production of native files.
Author
Wade Peterson is the Director of Practice Support at Bowman and Brooke LLP, a national product defense firm. Wade’s career spans 40 years in legal technology including development, IT management, and Litigation Support. As Director of Practice Support, he manages the firms litigation support services including eDiscovery; forensics; graphics; custom case and document databases, reviews and productions. His responsibilities include: organizational structure and staff; establish software systems, procedures, standards and processes; oversee production operations; marketing to internal clients; prepare quotes and budgets; and researching and adopting new technology. Wade is an active member of EDRM, ACEDS, OLP, ILTA, and ALA.