Detailing the Security Risks In PDF Standard 136
crabel writes with this quote from the H Online:
"At the 27th Chaos Communication Congress in Berlin security researcher Julia Wolf pointed out numerous, previously hardly known security problems in connection with Adobe's PDF standard. For instance, a PDF can reportedly contain a database scanner that becomes active and scans a network when the document is printed on a network printer. Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers — or even depending on a computer's language settings."
Re:Abomination (Score:5, Interesting)
PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form).
PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs.
A real programming language cannot "react to the environment" unless it has the needed I/O facilities. It seems to me that PostScript (as implemented by ghostscript) has been locked down more and more in this area.
PDF in Adobe's hands on the other hand has acquired more and more dynamic features *not* found in Postscript.
Re:Abomination (Score:4, Interesting)
> Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.
It sounds like what you want is PDF/A ( http://en.wikipedia.org/wiki/PDF/A [wikipedia.org] ), which restricts the PDF to a simple non-scripted document. The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format. DjVu ( http://djvu.org/ [djvu.org] ) I believe would also be a good fit.
For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to). I've seen presentations run from a PDF before. It would be a pity to lose these possibilities.
Everything in your post makes sense, but now let's get back to the security issues.
If the security issue is that unsophisticated users get their computers owned because they click on a PDF link, then PDF/A isn't a solution. It isn't a solution for at least three reasons: (1) PDF/A is not an appropriate format for general use on the web, because it requires embedding all fonts. This makes the PDF much bigger, and that means the user's experience is slower. People already get bent out of shape about how long it takes for a PDF to load. They don't want a solution that makes it worse. (2) Advocating that people distribute their documents in PDF/A doesn't help, because bad guys will not follow that advice. (3) Telling users to restrict themselves to software that only accepts PDF/A will not work, because virtually no PDF's they encounter on the web are in PDF/A.
In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."
The cases where I don't know of any good, general solution are cases like the one you're describing, where you want to put students' grades on their papers. The problem here is that you need a feature that goes beyond simply printing and viewing a document. Presumably you've thought about the security issues, and you have a PDF application that has the particular feature you want without exposing you to security issues. The trouble here is that the message now becomes much too complex for the average web user. It's easy to tell them "Use Foxit," and then their problem is solved. But what if they say, "I need features x, y, and z that aren't in Foxit, and I need JavaScript enabled, but I don't want to spend several hours researching how to do this without a security risk?" The only answer I have for such a person is, "Don't do that, because Adobe is clueless about security."
One particularly ugly issue is that if you're in the print advertising or publishing business, you really can't get away with not testing your PDFs in Adobe Reader, but AR is poorly engineered and a security risk. The best you can do is to disable JavaScript.