File Formats Blog

JHOVE 1.4 is now available on SourceForge. The main change is that PDF/A compliance is more accurately identified than before, and is based on the final standard rather than a draft.

Labels: JHOVE, PDF

PDFZone discusses ProtectedPDF, a way of incorporating digital rights management in PDF. According to the article, ProtectedPDF files can be read in Acrobat Reader without any plugins, which presumably means that the files are fully PDF-compliant. Internet access to Vitrium's server is required to open documents. While the article doesn't say so, the only way I can think of doing this is through JavaScript.

The value or abusiveness of DRM depends on how it is used. For short-term use of a document, it can be a sensible way of limiting access. For limiting the distribution of content while supposedly allowing recipients permanent access, it doesn't work so well. If Vitrium ever goes out of business or gets tired of supporting ProtectedPDF, then all the rights-managed documents become inaccessible. "Buying" DRM-protected content, as opposed to renting it, is a dubious proposition. The effectiveness of DRM is limited; if you can get content on your computer, there's always a way to copy it.

Assuming JavaScript is required, users must enable it to view ProtectedPDF documents. (A third-party FAQ confirms this.) This exposes users to JavaScript-based vulnerabilities in Acrobat Reader, as well as possible loss of privacy. The article notes that ProtectedPDF files can report back on who's reading them. People are aware of these risks when using a web browser, less so when using a PDF reader.

As a technical concept, it's very interesting that DRM can be implemented within the PDF specification. How it works out in practice remains to be seen.

Labels: PDF

The third international PDF/A conference will be held in Berlin on June 17-19, 2009. Here's the announcement (PDF, naturally).

Labels: conferences, PDF

In doing a search for blog posts about JHOVE, I came across a very interesting discussion of the conflict between exact format checking and error tolerance. "Postel's law" implies that readers should overlook errors in files whenever feasible. But what should digital repositories do? Should they be completely strict, because we don't know how future readers will work? Or should they overlook some harmless errors rather than reject otherwise perfectly good documents? JHOVE uses a "one strike, you're out" approach, which is often less then ideal. But accepting any document which doesn't break the current Adobe Reader would be reckless. The balance is tricky. Some errors are deadly, some harmless, and validation software should really be able to distinguish degrees of harm.

Labels: JHOVE, PDF, preservation

Adobe has posted the ISO 32000 standard (PDF) as a free download. This document "is a copy of the ISO 32000-1 standard. By agreement with ISO, Adobe Systems is allowed to offer this version of the ISO standard as a free PDF file on it’s [sic] web site. It is not an official ISO document but the technical content is identical including the section numbering and page numbering."

Thanks to Inside PDF for the information.

Labels: PDF

Inside PDF has its first post since January. Jim King discusses ISO 32000 (the ISO standard which corresponds to PDF 1.7), extensions to it, and its relationship to PDF/A.

It's good to see this blog is still going.

Labels: PDF

The Digital Preservation Coalition has issued an interesting report called Preserving the Data Explosion: Using PDF (PDF). This talks about the state of the art with PDF/A, as well as work on some other PDF standards efforts, including PDF/Engineering, PDF/Exchange, PDF/Universal Access, and PDF Healthcare. I wish a little more attention had been paid to the writing, which is messy in places, but there's a lot of useful information there.

Found by way of Digitization Blog.

Labels: PDF

The First International PDF/A Conference will be held in Amsterdam on April 10-11, 2008.

Labels: PDF

PDF 1.7 has been approved as ISO standard 32000.

Rick Jelliffe and Jim King offer their comments.

Labels: PDF

There's a new blog called "Inside PDF," with interesting comments on PDF and general file format issues, by PDF architect Jim King.

It's a little weird when a blog called "File Formats Blog" turns out to be the general-interest blog that points you at the real specialists, but that's the way the world goes.

Labels: PDF

A week ago, I raised the question of risks in PDF documents. That got me wondering about the risks involved in Launch Actions, so I put together a handmade PDF that contained a Launch Action triggered by viewing a page. If this launch happened unimpeded, it could be a serious security risk, as malware could deliver a one-two punch by first delivering an executable and then getting a PDF reader to launch it.

In the testing I've done so far, all versions of Acrobat Reader which I've tried simply ignore the launch action. The JavaScript setting seems to have no effect. A full version of Acrobat for Mac OS X offered to launch the program I selected, but first put up a warning that asked me whether I wanted to proceed.

However, nothing in the PDF spec requires a warning, so it's possible that some readers will blindly launch whatever is asked for. These may not be common enough for malware creators to consider them worth exploiting. If you're interested in experimenting with it, the file is here. It will merely attempt to launch C:\\WINDOWS\\system32\\cmd.exe, so it's harmless even if the launch goes through.

Labels: PDF

Adobe has said that PDF documents attached to spam pose no security risk. Adobe certainly would like this to be true, but any such claim needs to be examined with skepticism.

The PDF spec includes a "Launch" action which can be triggered by clicking on something harmless-looking, or just by moving to a page. Parameters can be provided to the application, giving the launching document a lot of flexibility. A spam mail which contains two attachments, a PDF document and an EXE file which it launches, could be a deadly combination.

In addition, arbitrary media types can be embedded in a PDF file. These will be played (to use Adobe's generic term) only if the PDF reader supports them, but vulnerabilities in standard libraries for any of these media can become vulnerabilities in PDF.

The standard advice is the right advice: Don't open attachments from untrusted sources.

Discussion of some risks in PDF is available here. The claim that disabling JavaScript in the PDF reader prevents launch actions is not correct; launch actions can be used without JavaScript.

Labels: PDF

Adobe reportedly will be submitting PDF for adoption as an ISO standard.

PDF/A and PDF/X, restricted subsets of PDF, are already ISO standards.

Update: Here's a good article on what's happening.

Labels: PDF

Here is a report of two PDF "back door" exploits.

The first exploit causes a specified URI to be launched when a document is opened. It appears that this is done simply by including a URI action (see Chapter 8 of the PDF specification, "URI Actions") in the PDF. It's thus very simple to have a PDF document cause the user's browser to open a URL which could contain malicious content, and the problem appears to be in the format specification, not in an Acrobat bug. The example linked to from the article opens a harmless URL.

"Back door" implies the use of an undocumented feature, so it isn't really a back door exploit, but a demonstration that a feature can be abused.

Labels: PDF

People have generally assumed that anyone can write software to create PDF files. But recently Adobe threatened legal action, pressuring Microsoft to withdraw support for PDF output from the next version of Microsoft Office.

The grounds for legal action aren't clear from any of the articles I've read, but the incident suggests that Adobe is actively asserting control over who may create PDF files and under what conditions. This could affect other creators of PDF output as well.

Labels: PDF

pdfzone.com has an interesting article on PDF compatibility. Not too surprisingly, the main problem is third-party fonts, which may work with some versions of Acrobat and fail with others. More often than not, the fonts were in error from the beginning.

• Part 1: Adobe battles backward-compatibility woes
• Part 2: Some backward-compatibility problems (but not all) have a happy ending

Labels: PDF