Schneier on Security

Pat Cahalan • November 14, 2005 1:27 PM

Remember that PDF isn’t quite the Portable Document Format it used to be. In fact, it’s hardly “portable” at all, anymore. NSF won’t even accept submitted documents created in Acrobat if the version is not 5.0, due to compatibility problems.

People make PDFs in all sorts of ways, via specific versions of Adobe Acrobat Distiller (a commercial Windows product), using open source tools like ps2pdf (which calls another open source tool, ghostscript, which dumps to some version of PDF which may or may not be N compatible for whichever N version of Acrobat.

This leads to all sorts of bizarre problems, like documents that won’t print, or will print only a particular portion of the document, or will print, but only on a Windows machine using a particular PDL version of a driver for a specific printer (e.g., it will print with binary PS, or it won’t print with binary PS, or it prints differently to a PCL or KPDL or some other bizarre printer definition language than it does to PS).

For Windows-only people, using only the current commercial version of acrobat, this isn’t a bad solution (make all your docs PDFs before distributing them). For everyone else, it’s just as much of a headache as “make all your docs {fill in the blank application} documents before you distribute them”.

If you really want a portable document format, make ’em .jpgs.

Pat Cahalan • November 17, 2005 11:54 AM

Document revision and control and authoring seems like an old problem, but having been a technical participant to a disclosure summons let me tell you that the current practices in the real world do not in any way make sense for any corporation that wants to CIA (substitute Y for I and you’ll know what I mean here).

There are several individual problems with the current “processes” (sarcasm tongs here) for document creation and control, namely that there really aren’t any.

The problem of metadata in Office (the topic of this thread) is only one aspect of the problem. (The version control in Office actually makes this particular problem worse, not better, which I’ll get to later.)

Anyone who used Word Perfect back in the 5.n days knows that Office isn’t the only word processor that leaves cruft in a document. WP was just nicer in that you could toggle “reveal codes” and remove the markups that weren’t supposed to be in there.

Here’s what you really want, as a business. You want the ability to compile data, format data into a document, and render that document to an output device. You want those three bits of functionality to be modular, so that different people can compile data using different methods, different people can format the data into a document using different methods, and the resulting document can be rendered to various output formats using different methods. You also want the ability to tag each chunk of data with identifying markers for version control (author of data/date created/date edited, etc., whatever), AND with particular metadata (this data is related to “foo”). This last bit of functionality is totally lacking in today’s document formats, and for legal purposes its astounding that nobody has done this correctly.

If I’m sued regarding “foo”, I should be able to locate all digital documents I have stored relating to “foo” regardless of whether those documents are individual emails, word processing documents, spreadsheets, accounting reports, whatever, with a simple search on my data store(s). Related to this, if I’m legally required to retain documents for a certain period of time (7 years, for example), but I want to dispose or archive those documents at the end of this period, there currently is no way for me to do so.

Here’s where the metadata stored in Office becomes a problem -> if someone who doesn’t realize what they’re doing incorrectly edits an existing document (leaving the data relating to “foo” in a document pertaining to “bar”), there is no easy way to remove the “foo” data, or even know that it is there. This can lead to inadvertant data disclosure, which can be anything from embarassing to illegal.

Imagine your doctor’s office receptionist accidentally leaving the entire text of the letter informing someone that they have a disease in as “version1”, and making a form letter as “version2”. Anyone getting a copy of a letter saying, “Mr. Jones, you have a minor case of arthritis requiring over the counter pain medication” could reveal version1, and find out that Ms. Edwards has an embarassing social disease.

Having a “publish” button that pops up with a GUI such as, “There is data in this document relating to ‘foo’ and ‘bar’, do you want to (a) leave it in, (b) delete all data relating to ‘foo’, (c) delete all data referring to ‘bar’, ” or something of that nature would probably be a great help.

Optimally, there would be a standard for those three bits of functionality (ie, all document preparation programs would have raw data stored in one way, with the formatting tags stored in another way, and the rendering information stored in a third). This would actually BE a real PDF (“portable document format “)-> if you wanted to open a document in some application that was different from the authoring application, you could choose to open just the raw data, the raw data with the formatting interpreted into the new application, etc.

Office is horrible in that the formatting commands are munged together with the rendering commands, which is why selecting a different printer can screw up your document. This is absurd. But one can’t really take MS to task for this, because there isn’t a standard for them to violate 🙂