LAWTECH GURU BLOG by Jeff Beard

Erasable, Editable, Recallable E-mail?

E-mail is a big problem for businesses and individuals alike. Say something in person without a recording device, and the hard evidence evaporates almost immediately, devolving into the wiggle room arena of "he said, she said".

Not so with most e-mail messages -- which can linger like bad fish left in someone else's kitchen. The sender suspects it's still out there, becoming more pungent with age, but generally can't do much to reach out and toss the spoiled thing away before it's discovered and used against him or her. Thus a number of developers have attempted to re-engineer the e-mail process into something often touted as completely controllable by the sender. Frankly, the false sense of security generated by these attempted solutions scares the dickens out of me. Let me tell you why:

But first, a couple of much-needed disclaimers:

1) This article intentionally begs the question of the propriety of destroying e-mails and/or attachments after they were sent. It could go either way depending on the situation. At one end of the spectrum, a company that has crafted a legal and appropriate document retention policy may also have a legitimate need to ensure their e-mails comply with that policy (although the Sarbanes-Oxley Act has potential impact here). At the other extreme, one who has engaged in inappropriate or illegal acts could abuse these enhanced e-mail services by attempting to destroy key evidence after the fact. As with most technology, good or bad results depend heavily upon how it was ultimately used.

2) Therefore, this article is intended to discuss the technical advantages, disadvantages, and even potential fallacies of "controllable" e-mail systems. It is not meant in any way to denigrate these developers, their products, services or attempts to provide more secure e-mail systems. Everyone is free to reach their own conclusion on this subject.

I came across this post today at Mike Arkfeld's excellent Electronic Discovery and Evidence blog. It describes BigString.com's new e-mail service that purports to "recall, modify or set an expiration date for emails that have already been sent. These emails can be erased, modified or expired even if the recipient has read them."

Having researched and written on the subject of "controllable", "recallable", and "disappearing" e-mail over three years ago for the National Law Journal, this naturally piqued my interest. The underlying idea is nothing new. Back in 2000, several companies experimented with new e-mail services that gave the sender a much higher level of control over dissemination, viewability, and expiration of their e-mails. Some developers encrypted e-mails with keys the sender controlled. In essence, a recipient's e-mail service or program could only decrypt a message if the key hadn't been revoked or otherwise expired by the sender. Other services took a different approach by "play[ing] host to an entire self-destructing mail system. Users must go to their sites to send and receive encrypted mail." At the very end of my NLJ article, I provided links to a few services who took this latter approach as examples.

Once the decryption key became unavailable, the theory was that the e-mail became an unintelligible, encrypted mess of alphanumeric soup. That was supposed to give the sender a huge sense of relief and protection that it had, for all practical purposes, "disappeared".

Except that the e-mail didn't disappear, did it? In some cases, the recipient still had a record that they received an e-mail from Sender X, but the contents were scrambled. Even such a limited e-mail could be used to establish that communication had in fact occurred between two parties who may have otherwise denied it. And as you may note from my NLJ article above, depending upon the method used for control, there was little to stop the recipient from printing, screen-capturing or copying-and-pasting it (while the e-mail is still active) into another format that couldn't be so easily controlled. If printed, one has a hard copy that is completely independent of its digital counterpart. Screen captures allow one to store a picture of the e-mail in a common graphical format, such as a bitmap (.BMP) or JPEG (.JPG), that can't be recalled and can also be printed. The same goes for copying and pasting text into a separate document or e-mail message. And then there's low tech: If the recipient can read the e-mail, they can take a photo with a video or still camera. Given some of the tiny yet high resolution digital cameras that covertly fit into a pocket, one should consider this as another threat which has long been used in corporate espionage.

Unfortunately, I have yet to see one of these consumer or commercial services that didn't have some holes in it -- so be wary. As mentioned, there was some exception that enabled the recipient to retain some or all of the message beyond the control of its sender -- especially if they acted immediately while the e-mail message was still in an "enabled" and thus "readable" state. Naturally, these exceptions required some tech savvy on the part of the recipient or their hired gun. However, a security system that works best off a user's ignorance, while effective most of the time, is still flawed.

Coming back to the present: To be fair to BigString, I asked myself, how could BigString's service be different? Were they using encryption as well, or perhaps taking a different approach by hosting the source e-mail and then tricking/redirecting the recipients' e-mail programs via HTML, scripting, or other dynamic or active web content? So I visited BigString.com's site, and began reading through all their pages. All but one of them extolled the many virtues of the service without explaining how it worked under the hood. Note to marketing department: Seeing that much unsubstantiated hype generally makes one very skeptical. The more I read between the lines, the more I began to think that they must be providing some type of e-mail hosting service. By hosting it they control access to the source e-mail message and attachments. I figured that the recipients probably just received an e-mail containing a unique redirected link back to the original message, or something very similar. If an HTML-formatted e-mail was crafted properly, it would appear to the reader that the e-mail message was indeed sitting in their inbox, when in actuality it was being fetched over the web automatically by their HTML-ready e-mail program. All quite clever indeed.

Then, buried in the press releases, I finally found the one page (a New York Times reprint) that provided a limited description of how it works, which confirmed these musings. And once again, the old "print", "save as image", and "copy/paste" concerns were mentioned:

"BigString e-mail recipients can save the messages, but only as image files, and they cannot cut-and-paste from them. Mr. Myman said the company would release an optional feature next month that blocks the receiver's ability to print the messages.

As with any Web-based e-mail service, it is possible, albeit unlikely, that a hacker might tap into BigString servers and gain access to e-mail messages.

'Sure, you could crack the mother lode by getting at this one location," Mr. Clinton said. "But at least that's a location that's working on security.' "

1) Preserve the e-mail long past its edit, recall, or expiration date,
2) Forward the saved image to others, beyond the control of the original sender,
3) Print the saved image to hard copy to preserve it completely outside the digital realm,
4) OCR the image to convert the image back into text,
5) Which then allows it to be copied and pasted into another document or format,
6) Which also allows it to be printed, and
7) Which also means that one need not even try to hack into BigString's servers.

Another observation, and admittedly this is based on some conjecture on my part to which I welcome additional clarification to be fair:

Per the NYT article, the e-mail is stored in HTML format. I have encountered web sites which have prohibited right-clicking, saving, printing, and the like. Generally this was done by inserting additional coding in the HTML page that prevented these actions by average web visitors -- who viewed the content in web browsers that properly executed these limitations. However, with a minimal amount of additional effort (say less than 30 minutes), it is sometimes possible to download this "protected" content into an HTML or text editor, and then either edit out the prohibiting code or instead copy and paste the desired content into another document window. Again, I'm not making the call on the propriety of doing so -- my point being that it is often, in fact, doable by someone knowledgeable, and is doable beyond the direct control of the author. Again, I have not seen BigString's HTML-formatted e-mail, and this is indeed guesswork on my part. Thus I welcome clarification from BigString since I did not see any whitepapers or other truly technical information on their site.

However, experience has taught me that reliance upon a false sense of security is a very dangerous thing, leading to dangerous assumptions, such as: The Titanic was unsinkable, or that a system is completely secure. No security system is foolproof, only "fool resistant" at best. Another point worth offering is that security is not a product nor a service. It is a process, and it is equally important to know where the strengths and weaknesses lie in that process. Notice that nowhere here have I stated to use or not to use any of these services. That was not my intent or point at all, but rather education and informed consent. With any type of digital rights management (DRM) system, it behooves the users to understand exactly what it can and can't do, and plan accordingly. Ask all the right questions and don't relent until you have sufficient answers. Quantify the upside gains and downside risks. And then just maybe, you'll have an intelligent means to conclude whether using such a system is feasible, justified, and even advisable. The rest is up to you.

3.18.04 Update: As I reflected on this post for a few days, I realized that I hadn't stated a key point:

While these e-mail services are not perfect, the 80/20 or the "good enough"' rule is applicable. Without these services, all e-mail one sends out could potentially come back to bite him/her and/or the organization. While these services would not prohibit all attempts by recipients to preserve e-mails, in the due course they could be fairly effective due to the relative technical ignorance of most recipients. If a company could reduce its e-mail risk by say, 80%, that could very well justify its adoption -- with a savvy decision maker recognizing that it's a practical tool with a few warts, not a panacea.

My main point here is that people could become overly reliant upon these services to the point where its users get too comfortable. Thus they could make some monumental mistakes that they wouldn't have done absent their reliance on this technology. Without this technology in place, a person may think twice about sending a particular e-mail if they know they can't unring the bell. If the person thinks that all e-mails are recallable or can be excised through automated expiration, they may become less likely to think about the consequences before clicking "Send".

For example, a key officer sends an inappropriate or incriminating e-mail to a cohort thinking that it will automatically disappear after X days to cover his/her tracks. Another would be senior management adopting the services thinking that it will completely eliminate their exposure in electronic discovery with respect to e-mails. As with any change in technology, management and user training should encompass not only the technlogical aspects but the real-life ramifications associated with it. I've said it before and I'll say it again: Security is a process, not a product, and when people are involved in that process, they often become the weakest link.