Design Philosophy

Design Philosophy

User Interaction

Users make poor security decisions. But that's not their fault: system and security administrators make poor decisions too and they are much better equipped in this field! Rather than relying on User Education (which is quite often forgotten within half an hour of conclusion), why not try to remove the security decision burden from the user completely?

That's the aim of xdpdf. By intentionally mangling the potentially malicious parts of a PDF file, we can eliminate much of the danger that PDF files represent to the user, and thus our organization. Users no longer have the option of taking unsafe actions with PDF files, and so a large class of targeted attacks are no longer effective.

Design Decisions and Testing

xdpdf was deliberately designed to be as quick and thorough as possible. This means that it makes no attempt to understand the structure or content of the file; rather it simply looks for the specified keywords (whether obfuscated or not), and renders inert those it finds. It is entirely possible it will encounter the keyword strings within document content (either plain text or encoded images etc), especially for the shorter keywords such as '/AA' and '/JS'. This is the main reason for keeping a copy of the original PDF - during testing, 21 PDFs from 7950 tested (around 5.4gb worth) rendered incorrectly once they had been modified by xdpdf. The burden would be on the end user to notify the mail administrator, and the mail administrator to use the log and original file to make a decision on the safety of the PDF, before passing it on to the end user. Note that around a third of the testing PDFs were modified by xdpdf, and the vast majority displayed correctly following this.