Detailing the Security Risks In PDF Standard

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."

Comments

Abomination

[panaceaa]

"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."

Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.

Re:Abomination

[DamonHD]

i18n is the work of the [devil|diablo|Teufel], clearly.

Rgds

Damon

Re:Abomination

[Anonymous Coward]

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.

If it were to display _different content_, as alleged, that would disqualify it from being able to be used for archival of government documents.

Re:Abomination

[QuoteMstr]

It's not that internationalization is the work of the devil, but rather that it should happen at a higher level than an individual PDF. Allowing different content to be displayed in different language environments raises serious questions about document integrity: imagine a international contract PDF that displayed one payment for German users and another for French ones.

PDF-the-document-format is a good thing in that it allows perfect reproduction of a printed document anywhere. PDF-the-generic-container, on the other hand, is both frightening and of dubious utility, but I can see why Adobe might have a business case for trying to drive this approach anyway. This is why we can't have nice things.

Re:Abomination

[Anonymous Coward]

There are many file formats which use content negotiation. PDF used to mean "portable document format" and it's primary selling feature was that a PDF looked the same everywhere. If I don't care about getting the exact same output everywhere, then I can use HTML or DOC.

Re:Abomination

[Xugumad]

> 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 ), 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/ ) 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.

Re:Abomination

[burne]

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. The problem with that has always been that one would have to know on what make and model printer it would run. But, thanks to Adobe, most people will run their PostScript in a 'virtual' printer inside an Adbode-product, and that makes usefull programming in PostScript a real possibility.

I'd say: Happing programming, it isn't that hard.

Re:Abomination

[Anonymous Coward]

Yes, thanks for the link. That's what I thought the whole PDF was for.

Ah, I see, they are intending to embrace and extend into other fields almost nobody currently uses it for.

As for what you are trying to do, what's the advantage over normal HTML?

Re:Abomination

[jgrahn]

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

[Anonymous Coward]

So this higher level is going to have fully automated language translation to guarantee the precise meaning of the contract is the same in every language? I think anyone expecting a computer solution to that with current technology is going to be disappointed. If I send 20 text files, one in English, one in French, one in German etc. believe it or not I can still put different stuff in each.

The real problem I suspect here is that the reporting of what was said is not reflecting the actual problems perceived just listing some of the mechanism which have been/can be exploited. e.g. Saying that javascript can read and edit pdf documents, erm well javascript can read and edit html, graphics files etc. etc. So a computer language can read and maniupate the contents of computer files who would have thought.

Similarly the multi-language/OS stuff maybe a security issue if I taylor different "payloads" meaning my document appears fine where I can't exploit it and appears fine to me as the author but is evil elsewhere. People trust me, so me saying the document opens fine and is benign may help spread something. If the article reported more detail perhaps the issues at stake would be clearer.

Re:Abomination

[John Hasler]

Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you?

Not me, certainly. When I view a document I want to see exactly what everyone else viewing the document sees unless I take explicit action to change it.

Re:Abomination

[Anonymous Coward]

Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.

Generate a different file with the corresponding text in the other language/s.

PDF started jumping the shark once JavaScript was added and video and Flash in a "document" format pushed it over the edge.

Re:Abomination

[WWWWolf]

"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."

Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.

Look, the security problem isn't that the features exist. The security problem is that people are just plain ordinary mortals, and plain ordinary mortals screw things up. Every new option adds another route to failure.

Apple doesn't like to ship too huge manuals. My sister wanted a nice printed GarageBand manual. She sent the PDF manual to my father, who opened it on a computer with an older Windows version of Acrobat Reader that didn't know damn about the language switch thingy. So he ended up getting boundlessly confused when the PDF actually appeared to have zillions of pages in dozens of languages, while the PDF only appeared to have Finnish version when viewed on OS X.

A careless act of "just open the file and press the print button and go have a coffee" could have ended up wasting a lot of paper, because of a nice big fat feature mismatch problem. In Adobe's own damn software. Granted, not an earth-shattering problem, but inexplicable and unexpected behaviour nevertheless. There would have been a lot less puzzled questions if only Apple had shipped separate PDFs for different languages.

Hmm, I wonder how many people have ended up screaming and shouting when someone else printed the wrong language version for them, because they didn't even notice the document has different language versions in them and the computers were set to different locales. I'm sure there's lots of confusion about when a document that's sold as the ultimate solution to print the document the exact same way in every platform on every computer doesn't work as expected.

Re:Abomination

[datapharmer]

Having written a thesis on digital data archival, I can say with certainty that there are a number of different types of pdf including PDF/A which is intended specifically for archiving and does not have all this fancy nonsense in it like embedded videos transparent layers and switching of languages etc. It is well documented and has its own separate ISO number. While adobe does some crappy stuff to things that have a ".pdf" extension at times don't make dramatic conclusions about how something is unfit to be used by someone else unless you know what you are talking about.

Re:Abomination

[Anonymous Coward]

A recording of the presentation will soon appear here and should answer your request for more details.

Re:Abomination

[noidentity]

Perfect for writing a two-faced contract.

Re:Abomination

[Anonymous Coward]

There IS one type of environmental accommodation I would LOVE to see: reflowing of the document to fit the computer viewing window - I HATE viewing PDF docs in the page-centric format most are hard-coded for, which seems to be about 99% of the PDF docs I have viewed. Getting rid of the constant panning/scrolling to view the info would be a huge boon for those of us viewing these docs on a computer - what a concept! Without that I will continue avoiding PDF forms of documentation any chance I get (and with all the other malware programmability potential, it seems I have other reasons for that avoidance...).

Re:Abomination

[bytesex]

No, the higher level is going to be an archive file with multiple PDFs and a manifest giving you the details of what is for whom. But then, you purposely misunderstand, I suspect.

Re:Abomination

[butlerm]

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

PDF is not anything like PostScript. It shares the same rendering model, that is about it. Postscript _is_ a Forth-like, stack oriented programming language. PDF isn't a programming language at all, but rather a generally vector oriented graphics format with Javascript automation tacked on as an afterthought.

If you take the scripting aspect out of Postscript, you are left with nothing. If you take it out of PDF, 99.9% of the world's PDF documents still display and print without a problem.

Re:Abomination

[TheRaven64]

Not exactly. A subset of PDF is almost identical to a subset of PostScript. A PDF file is a dictionary of objects. These can be in a variety of formats, including binary data which can contain images and so on. One of the formats is drawing commands. These can be written in an extended subset of PostScript, with the flow control primitives removed and a few other commands added. You can convert PostScript to PDF by executing the PostScript program and recording the trace through it (basically, unwind all of the loops, pick one branch in all of the conditionals) - the subset that controls drawing is the same in both.

Re:Abomination

[hedwards]

Indeed, you rarely hear of trouble caused by the core function of providing a document across platforms. All the trouble I hear about is the javascript and the other features tacked on to make it cooler and more exciting.

Unfortunately, those features also make it a lot harder to secure and a lot easier to use for malicious purposes. Word documents had a similar problem. Macro viruses didn't come on to the scene until MS decided that a document should be more than just text and mark up.

Re:Abomination

[netsharc]

I suppose they could put a big page in the front that only appears on older reader version that says "This document contains the documentation to GarageBand in X languages", ... etc etc, but then again, who uses brains in this area.

Or prevent printing if the reader doesn't have "multi-language" capabilities... yay, frustrate the user even more!

Re:Abomination

[butlerm]

The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.

That was its sole intent when it was created, and for several years afterward. Rudimentary javascript support wasn't added until 1996. Audio / video embedding is a much more recent addition (2008 or so). See here.

Re:Abomination

[Xugumad]

There's a few contexts we use PDFs in, with varying advantages:

1. For archival purposes, we produce signed PDFs (and are working on producing PDF/A compliant documents, but the library we're using is being a bit of a pest). These can't then be changed without breaking the cryptographic signature.

2. For coursework submission... HTML could work for essays (although conversion from Word has always been "interesting"), but presentations wouldn't work. We're idly looking at adding .docx to HTML convertors as a step towards turning essays into .epub or .mobi files for Sony/Amazon e-readers, but that's long term stuff.

3. For formal letters (e.g. the same system can produce "You're failing your degree" letters), where layout is important (and easier to get right in PDF, mostly).

Re:Abomination

[Jah-Wren Ryel]

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).

That's ripe for a hack. A smart kid will come up with code he can add to his PDF at submission that will identify the form and change the mark to a higher grade and then, if he's really clever, rewrite the PDF to delete any sign of the grade changing code.

Re:Abomination

[Anonymous Coward]

No I didn't purposely misunderstand anything, your example is where the document contains different values depending on sub-document read. I can't see how that higher level archive containing multiple document changes that. The publisher could still provide multiple versions with differing values. If the issue is about being able to see those multiple versions, then that's an issue for the reader software and not the format itself.

Realistically though it makes no real difference. If the publisher wants to charge the french different to the germans they are quite welcome to, if they want to keep that private between those two parties, then they'd just publish an individual file for each and not provide the others. That isn't a security issue.

Re:Abomination

[bcrowell]

> 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 ), 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/ ) 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.

Re:Abomination

[jklovanc]

One of the big differences between html and PDF is data storage. When using a pdf form someone opens the form inputs the data and that data is saved inside that form; everything is in one place. Html requires three separate pieces; The form to enter the information, the scripts to save the information and the data store (database or file system) to save the data. PDFs are much simpler for handling small quantities of forms.

Re:Abomination

[butlerm]

A subset of PDF is almost identical to a subset of PostScript.

One should say rather that a subset of Postscript, when executed/interpreted produces output that is equivalent to a subset of PDF. PDF isn't based around an interpreter. Javascript/Flash appendages aside, a PDF document won't overflow the stack, does not have infinite loops, won't crash your photo-typesetter or take hours to run, because it is not a scripting language, but rather a vector oriented graphics format.

If Adobe did it over again, it is unlikely that Postscript would have been developed at all. Instead of Postscript printers, we would have had printers that accepted a subset of PDF. It would have solved a lot of problems. At this point Postscript is a historical artifact. PDF/X is its much superior replacement.

Re:Abomination

[TheRaven64]

PDF isn't based around an interpreter

As I said, the top-level structure is a dictionary, but the drawing command set is definitely run in an interpreter. It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript. In the first version of the PDF spec, it was a subset of PostScript, just with the flow control removed. In newer versions, it has gained some things that are not present in PDF.

Re:Abomination

[jklovanc]

Lowest common denominator. So you don't care that some systems are more compliant that others and can display things better than others. That would require the format to only support formatting that available on all computers.

Re:Abomination

[jklovanc]

Try opening a Word 2010 in Office 3.1. It won't work. The fact that the PDF was even able to be opened in older software is astounding. One would have to be clairvoyant to be able to make software compatible with all possible future extensions.

To me this sparks a hubris; I want the computer to do what I want when I want no matter what version of software I use. The fact that someone opens a new version document in an old version of the software and there is an issue is not the problem of the software but a problem of the user. Going by this logic there would only ever be one version of software.

Re:Abomination

[ColdWetDog]

No, the OP's father's problem is that he tried to print an Apple document on a Windows computer. This is NOT to be countenanced and, in point of fact, is just this side of Total Blasphemy. It's a good thing he stopped when he did -he's lucky he didn't open a portal to Hell in the process.

Re:Abomination

[Anonymous Coward]

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).

It's a real shame that nobody has come up with any type of metadata standard that works across operating systems. Computer programming is still so amazingly primitive. We spend so much time trying to solving the same problem over and over and over again.

For example, you want to attach a grade to a file, so you come up with a painfully complicated PDF hack that only works for one type of document and one type of grade. As other people have said, what if you want to attach a grade to a non-PDF file? What if you want to add digital signature from the submitter and the grader? What if you want to attach other type of metadata to the same file? Your scheme breaks down.

You're solving a problem that has already been solved ten thousand times. This is really simple stuff to solve once and for all time, if we would just get over the politics and egos and just agree on the standards.

Re:Abomination

[rjstanford]

In fact, assuming that differences existed, being able to examine a single, signed file and determine that they were placed in there is probably more convenient than having to examine multiple files. Of course, you could distribute those multiple files in a signed archive, but that's basically what the PDF has become at this point.

Re:Abomination

[camperslo]

What a great feature!

Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.

Re:Abomination

[Anonymous Coward]

Thanks! Been looking for these.

Re:Abomination

[butlerm]

It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript.

A syntax identical to a highly restricted subset of PostScript - not so much as a user defined macro - everything pre-defined for you. You can't even come anywhere close to converting the most average, run of the mill Postscript file (such as the output of a typical Postscript printer driver) to PDF without running through a full blown Postscript interpreter first.

That is entirely apart from the fact that most Postscript generators do not generate much in the way of control flow. What nearly every Postscript driver does is generate a bunch of macros that expand to lower level operations of the sort that PDF supports. Very roughly speaking Postscript is to PDF as XSLT is to XML.

Postscript is like M4 on steroids. PDF/X doesn't have macro expansion (let alone control flow), which makes it trivial to process by comparison. All the operators are pre-defined and do exactly the same thing. Postscript files are a user defined menagerie of any operator the programmer finds convenient.

Re:Abomination

[butlerm]

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.

Clearly we need a 'PDF/R' then, much like PDF/A except without mandatory font embedding.

Re:Abomination

[BitterOak]

What a great feature!

Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.

It's hard to know whether this should be modded Funny or Insightful, because it's both. And that is precisely what makes these PDF "features" so disturbing.

Re:Abomination

[Korin43]

I don't see how that's better. If I always open the English documentation anyway, what's wrong with my computer picking it automatically?

Re:Abomination

[metrix007]

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."

Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.

Re:Abomination

[icebraining]

1) Any file can be signed, it's just a matter of hashing and encrypting such hash with a private key. PGP and such have "sign file" buttons.

2) http://meyerweb.com/eric/tools/s5/s5-intro.html

3) Why is text layout important in a letter?

Re:Abomination

[bcrowell]

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."

Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.

It took me a while to figure out what you meant. Foxit didn't used to support javascript at all, and that meant that its added security was more than just security through obscurity. It was actually more secure, because all the exploits for AR were based on javascript, which foxit didn't implement. I hadn't realized that foxit later added javascript support. At this point it looks like foxit is roughly equivalent to AR in terms of security: both have js turned on by default, and both allow you to turn it off. ( http://blog.didierstevens.com/2009/05/06/a-very-brief-history-of-foxit-reader-and-javascript/ ) The only possible difference would be whether Adobe or Foxit is more competent in implementing js securely, and that's going to be relatively hard to know, since both are closed source.

Re:Abomination

[metrix007]

No, Adobe Reader X is far, far more secure than either Foxit or Summatra or any other reader. Adobe Reader X, apart from haing the sandbox, is also the only reader to make use of Windows Integrity Controls so it is running in a low process by default. It is also the only reader to make use of DEP and ASLR, neither of which Foxit or Sumatra have ever tried to do. The javascript issue is not useful for comparison, as you noted others have js support and it can easily be disabled. The measure of security is how they actually deal with stopping attacks, and reader x is the only one that tries.

Re:Abomination

[lahvak]

Ehm, can you please point out where on the page you link to does it say that the sole intent of pdf format was originally to produce printed documents? I don't seem to be able to find that.

Re:Abomination

[wavedeform]

The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.

Right, but world domination is hard to fit on the printed page. :-)

Re:Abomination

[doom]

You might imagine valid uses for flexible documents that adapt to the environment they're read on, but if you don't realize that these documents have these flexible/adaptive features, then there is indeed some potential for nasty surprises.

There are already a lot of weird myths about pdfs (e.g. I've heard they're better for contracts than docs because "pdfs can't be edited"). This is, at the very least, pointing out yet another misconception.

Re:Abomination

[kmoser]

What if the document was written on a computer in New York and opened on a computer in Alabama? They certainly wouldn't read the same.

Re:Abomination

[butlerm]

You can always go read the PDF 1.0 specification, which is what I did, in 1993 or so. Of course no one was promoting the idea that you had to reduce the documents to hard copy. Acrobat Reader would be pretty useless if that was the case.

Re:Abomination

[lahvak]

I cannot find pdf 1.0 specification online, but I did find pdf 1.2 from 1996, and it describes the purpose of the format as "to enable users to easily and reliably exchange and view electronic documents independent of the environment in which they were created." It says nothing about hardcopy, and it specifically talks about "electronic documents", without further specifying what these are. It also says that "PDF also includes objects, such as annotations and hypertext links, that are not part of the page itself but are useful for interactive viewing." According to the document, the version 1.1 "adds more types of annotations", which, if I read it correctly, implies that annotations were indeed part of the original 1.0 specification. Version 1.1 also "generalizes link and bookmark destination to 'actions', which include links to other pdf files and foreign files". Again, this seems to imply that version 1.0 had links and bookmarks, which imply interactive viewing. Pdf format was designed from the start for interactive viewing, and most features that were added later (forms, javascript, which was first added as a way to validate forms, embedded files, multimedia content and 3D content) were just logical continuation of this idea. The fact that adobe messed up and did not think about security when implementing those additions is a different problem.

Re:Abomination

[31eq]

I've seen presentations run from a PDF before. It would be a pity to lose these possibilities.

I don't see anything in the linked page to say you'll lose that possibility. All you need is a projector-sized page and internal hyperlinks. (You don't need hyperlinks, but they can be used for navigation.) You will lose embedded animations.

Re:Abomination

[Anonymous Coward]

Seems like Adobe's PDF is the new Flash!

Re:Abomination

[Anonymous Coward]

You know the joke would be on those who didn't come in clown costumes unless you guys are fortunate to have more non-MS Windows users than MS Windows users.

Re:Abomination

[byrtolet]

The fact that the PDF was even able to be opened in older software is astounding.

I'm sorry, but my first experience with the PDF file format was exactly the opposite. I was trying to open a PDF document with adobe acrobat v. 3 or 4, and the only thing I've got was "Cannot open the file, use newer version of the program" - or something similar

Re:Abomination

[Anonymous Coward]

Why is text layout important in a letter?

You're joking, right?

Re:Abomination

[petermgreen]

There is a place for adapting to the user (though IMO there should always be overrides). But there is also a place for a standard "electronic paper" that reliablly displays the same way everywhere. Many people assume PDF is like electronic paper but as the article shows it isn't in key ways.

Consider what happens if someone reads a document, decides they agree then takes it to another system to print and sign. There is no gaurantee that what they read matches what they printed and signed.

Re:Abomination

[Anonymous Coward]

not that it's doing a great job at the moment, and not that other container file formats don't exist, but why can't the PDF be both...?

Re:Abomination

[lsatenstein]

Gee, web browsers do this all the time. Why the surprise?

Re:Abomination

[Anonymous Coward]

It'd be simple enough to embed the scripts in the HTML file and to append the form data to that same file as comments or some such thing. In fact, if you have an HTML viewer which restricts access from that file to that single file, you'd have a pretty safe solution.

Re:Abomination

[butlerm]

I misspoke when I said "printed documents". I should have said something like "print-ready page oriented documents". Form support was bolted on three years later, and the sort of forms that PDF was good at were "print ready page oriented documents", like IRS tax forms, for example.

It is not a mistake that audio, video, and Flash support didn't come to PDF for twelve years after that. That is not what the creators had in mind, or at least not what they expended any actual effort implementing. What they spent all their effort implementing was support for page oriented documents that could be printed out verbatim at typographical quality if necessary.

The biggest difference, by far between PDF and something like HTML is that PDF is fixed size page oriented, and HTML is not. An HTML "page" really isn't a page at all. Not unless it is short enough to be printed out on one, and most aren't. Worse, the printing support of most web browsers is so bad that you might have guessed that Adobe bribed them to keep it that way.

Re:Abomination

[lahvak]

I agree with you on the difference between pdf and html. Thus the need for a format that is page oriented, allows us to deliver document in a typographical quality, but allows interactive content. Pdf tries to do that.

Javascript came to pdf in 2000, the same year as prepress support. Does it mean that pdf document were never meant to be seriously printed in high quality, since it took 7 years to introduce prepress support?

Re:Abomination

[Korin43]

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.

Notice that if this was automatic, it would be well-known already. What it sounds like is that you can write a document in several languages (or for different PDF readers if you want) and have the reader's computer decide the correct one to show.

So, there might be multiple versions, but the author would be aware of all of them.

Re:Abomination

[butlerm]

No, for two reasons. (1) For most common applications PDF was high quality (2) PDF was based on a technology designed for typesetting from the very beginning. Adding the tweaks necessary for pre-press is a minor change.

Javascript support and interactivity was not, evidenced in part by the fact that dynamic PDF documents are incredibly rare. The whole tool chain used to produce most PDFs has no support whatsoever for automating them.

For the record, I think embedding audio and video clips is a worthwhile extension. General purpose scripting and Flash, not so much. Entirely different market, different tool chain, different security considerations, etc. "Interactive document" is an oxymoron.

Re:Abomination

[Anonymous Coward]

What a great feature!

Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.

And the Mac users will have to get their parents to sign a permission slip.

Re:Abomination

[Anonymous Coward]

So this higher level is going to have fully automated language translation to guarantee the precise meaning of the contract is the same in every language?

More likely, in such cases you'd have just one copy in a language that all the parties can read. The problem is when you have a single file that non-obviously contains multiple versions.

Re:Abomination

[Xugumad]

1. Yeah, suppose we could. What's the advantage?

2. That's really cool, and prints a lot better than I would have expected, but... this is for coursework submission. That means training 9,000 students to produce HTML presentations. I don't see that going well for us...

3. Appearance of professionalism, and not being quietly killed in our sleep by the corporate identity peeps. We'll get rid of paper letters before we get rid of the demand that letter layouts aren't done to an extremely strict set of requirements.

Re:Abomination

[Xugumad]

Yeah, I went away and read the 1.2 spec. Hadn't realised how much stuff they added later to PDF. I suspect a lot of the problems are that it's been substantially over-expanded since original design.

Re:Abomination

[Xugumad]

> 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.

It's actually simpler and safer than you'd imagine. The plan would be to have the server pre-check the PDF, and outright refuse to put the field in if there's anything troubling (e.g. scripts). The grade field will be a normal text form field, and the whole PDF will have to be re-uploaded to the server to extract the value.

> But what if they say, "I need features x, y, and z that aren't in Foxit

Interestingly, we've been looking at moving users to Foxit because it has features we're looking for, and Reader 9 doesn't. Need to check Reader X...

The bigger problem involves trying to train everyone to use Foxit. We've got a lot of staff who are very, very nervous about technology...

Re:Abomination

[Anonymous Coward]

I would think the ideal secure solution would be to sandbox the entire operating system as to avoid the system being compromised.

Adobe Reader

[dna_(c)(tm)(r)]

Still looks more like it requires Adobe Reader to be a problem. I've seen other things from Adobe, they're about pretty things, not security.

Re:Adobe Reader

[Alex Belits]

People use Adobe Reader?

All right

[Anonymous Coward]

"previously hardly known"

And that's where I stopped reading. Yet another publicity-seeking person recycling previously known vulnerabilities and trying to tell us they were "hardly" known.

Re:All right

[AaronW]

I happen to know Julia Wolf personally and I know she's not seeking publicity. In talks I've had with her in the past, she has described how open PDF is to attack and how bad Adobe's reader is at security. She designs and writes these attacks as part of her job in order to detect and block them. She's one of the white hats. I'm sure that the issues she's discussed were probably discussed previously with Adobe and a handful of other security researchers, hence "previously hardly known". The article is poorly written IMO.

Trying to say that she's a publicity-seeking person would be highly inaccurate. She does give talks at various security conferences around the world since that is her expertise and she knows what she's talking about.

The problem is that Adobe made PDF so flexible with so many features that it's impossible to block all the various exploits, not to mention that Adobe themselves don't have a very good track record with security, i.e. look at Flash. The fact that PDF can incorporate Javascript, Flash, multimedia and even execute arbitrary external programs makes it a nightmare to secure.

Re:All right

[TheHorse13]

"The problem is that Adobe made PDF so flexible with so many features that it's impossible to block all the various exploits, not to mention that Adobe themselves don't have a very good track record with security" You mean like that pesky Winders operating system?

Re:All right

[Anonymous Coward]

From the very getgo, Adobe and Macromedia made it painfully clear that they were not going to address public concern for security. Buffer overflows were one of the first lapses that went unchecked for years while design & implementation surrounded this lack of security, seemingly to perfection while the landing platforms were designed to come into the back doors of everyone's PCs.

Re:All right

[Anonymous Coward]

I also know Julia and have to agree that I've never known her to be attention seeking. She definitely knows what she is talking about.

I feel that Adobe should have made two formats. One for Documents that are static, and another to do the bells and whistles of manipulation and forms. Have the files digitally signed, readers to interpret these and ask like any web browser working with signatures.

Ban manuals distributed in pdf.

[jack2000]

What happened to good old HTML manuals eh?

Re:Ban manuals distributed in pdf.

[Anonymous Coward]

It would be good to have HTML standard for manuals - and have a standard to embed images and fonts and whatever in ONE SINGLE file (the same .html), then it will replace PDF to some degree.

Re:Ban manuals distributed in pdf.

[realityimpaired]

You actually can do that with javascript, but it makes for a very large and clunky file.

Re:Ban manuals distributed in pdf.

[jack2000]

It's a bad idea anyway. If you wanted to go that route you can use chm(Microsoft's proprietary compiled html help manuals)
You really shouldn't. Better to keep images in separate files. Noting stops you from having a simple web1.0 style webpage with hyperlinks to different parts of the same web page, or you can even break it into separate different files. You just need to link to it from the start menu or something. Name the main file help.html

Re:Ban manuals distributed in pdf.

[Anonymous Coward]

Multiple files, folders, and images - for a manual? No, it has to be a single file with the option to 'explode it' for those like you, who prefer every single items as single files.

Re:Ban manuals distributed in pdf.

[AaronW]

HTML manuals suck for a number of things. They don't print very well and are limited to a certain set of fonts. While there's SVG, it's not widely used at this time in the web browser because some browsers only recently started to support it (i.e. I.E.).

Re:Ban manuals distributed in pdf.

[jack2000]

HTML manuals print PERFECTLY. Fonts shouldn't be a concern for manuals. If you are using funky fonts in your help files you are doing it wrong. If you need special notation you can use utf or latex.

Re:Ban manuals distributed in pdf.

[spottedkangaroo]

You can indeed embed the images. if memory serves.

Re:Ban manuals distributed in pdf.

[Anonymous Coward]

HTML is a display format, not a printing format. It will print, but often poorly formatted - the reason for using PDF over txt/html is that they want it to look pretty/have a fixed display format relative to images, etc. HTML is nice for linkability, but a printed out HTML manual is utter crap to flip through.

Re:Ban manuals distributed in pdf.

[munch117]

It would be good to have HTML standard for manuals - and have a standard to embed images and fonts and whatever in ONE SINGLE file (the same .html), then it will replace PDF to some degree.

You mean like MHTML? Based on MIME, standardised. Unfortunately Firefox doesn't support it out of the box, perhaps because it's a Microsoft invention (AFAIK).

Re:Ban manuals distributed in pdf.

[panaceaa]

HTML manuals can do all the things accused of PDFs, and you won't even know about half of them! Your browser automatically sends your operating system and locale preferences on every request. The hosting site doesn't even need Javascript to access them. But if you did have Javascript enabled, your HTML documentation could also read and write to Flash and HTML5 offline storage databases, often without your consent or direct knowledge! The horrors!

Re:Ban manuals distributed in pdf.

[jack2000]

Which is why browsers should(some do already) implement sensible restriction policies on per zone and site level. Like preventing local pages from accessing the internet unless you specifically allow them.
Further all the hard to remove cookie shenanigans could be fixed, but wait Flash? That's ADOBE's fault again! DOH.
HTML5 offline storage should be cleared from the same privacy clearing settings that cookies are cleared from etc.. etc..

Re:Ban manuals distributed in pdf.

[Anonymous Coward]

Whoa I just had a fantastic new idea that I guess nobody ever thought of! we could embed the files in an archive container so its just one file to transfer but when you look inside for the content you find everything in sections..

Re:Ban manuals distributed in pdf.

[Anonymous Coward]

And since I prefer to view my manuals online, PDF is horrible since it is a print format. I am sick and tired of having only PDF manuals to find important information, having to constantly pan and zoom to get info that I could see in HTML much more easily (IF the HTML is not in some wonky format that has the same issues needing to be zoomed/panned to see the doc completely).

I hardly every print manuals/pages. Why do we have to be stuck with that archaic worst-case scenario?

RO

Re:Ban manuals distributed in pdf.

[AaronW]

I never have a problem finding information in PDFs, nor do I always have to pan and zoom. I'm always dealing with datasheets for various chips and whatnot. These are ALWAYS in PDF format without exception from every vendor I've seen. They usually contain scalable vector drawings where they can't really do that in HTML because a certain company's web browser didn't support SVG until very recently. These PDFs also usually have have the table of contents as well to help navigation.

In my case I usually use Okular to read them.

Also, I don't have to be online to read them. Often these are saved locally. At times it can also be nice to print them out so I don't have to have it open on my screen to reference while working on code.

Agreed. This is an Adobe Reader problem

[Vandil X]

At the end of the article, it is revealed that the exploits are Adobe Reader problems that are going to be addressed starting with Adobe Reader 10. So people that do not use Adobe's Reader client to view PDFs are not at as much risk, depending on how their non-Adobe PDF-reader solution is configured.

Of course, we all know the vast majority of the world (especially corporate users) uses Windows, and thus, Adobe Reader, so the security problems mentioned in the article are a valid cause for general concern... But not a concern for the PDF format in general.

Re:Agreed. This is an Adobe Reader problem

[rudy_wayne]

At the end of the article, it is revealed that the exploits are Adobe Reader problems that are going to be addressed starting with Adobe Reader 10.

From TFA: "Adobe plans to remedy the situation in version 10 of its Reader product by introducing a sandbox". In other words, they aren't going to actually fix any of the problems, they're just going to try to hide them behind a wall.

Re:Agreed. This is an Adobe Reader problem

[metrix007]

version 10 has been out for a while now.....

Re:Agreed. This is an Adobe Reader problem

[lahvak]

Actually, there are many more powerful alternative pdf readers on windows than on linux. On linux, if you want anything besides just a document rendered to print (such as annotations, animations, forms, 3D content, ...), you have to use adobe reader. I don't know what the situation is on osx, but state of linux pdf readers is abysmal. Linux is perfect environment for producing pdfs, but linux viewers are really quite primitive.

Re:Agreed. This is an Adobe Reader problem

[Threni]

Linux viewers are fine. You can view PDFs with them. I don't see the problem. I also don't get what's going on with all the security problems. Surely most people who use PDF viewers use them because they've got a PDF file from somewhere they want to view. Furthermore, the PDF file has a mixture of text and images. There's no need for a viewer of those sorts of files to need javascript support or anything else which can introduce security problems, is there? They just need a 'surface' of some sort to render text and graphics into. There's a problem providing this functionality? Really?

Re:Agreed. This is an Adobe Reader problem

[lahvak]

That's a very popular excuse for the sorry state of linux pdf viewers. If all you need is just display text and images in the right font and on the correct place on the page, you are right, linux pdf viewers are fine. AFAIK there is nothing available for windows that can beat let's say zathura for that purpose. But contrary to the popular belief, pdf is much more than just static text and images on a page. Just because you have never needed certain features does not mean that these features are useless and should not be implemented. There is nothing inherently insecure about pdf forms, layers, annotations and 3D content, and javascript can also be implemented securely. Unfortunately, the only viewer that implements them and is available on linux seems to have been developed with no regard for security. There are basically only three choices when it comes to viewing pdfs on linux: adobe reader, which has all the features but is insecure ans has a sucky user interface, one of many poppler based viewers, that differ from each other only in their user interface and something called "desktop integration", and xpdf. Ironically, there are number of ways how to create functionally rich pdf files on linux using only free software, but to actually view these files, one has to use a nonfree close source viewer.

Thank jebus that Apple invented Preview

[arcite]

Go figure, Preview works like butter in Mac OS X, yet the latest version of Adobe Reader is sluggish and jaggy while rendering the SAME PDF. You know, if it were not for Steve Jobs speaking out on Flash, Adobe wouldn't be doing anything to improve the performance/security of their software.

Re:Thank jebus that Apple invented Preview

[Larryish]

Evince on Linux is the same way.

Adobe's own offering is slow and eats up memory.

Evince loads large PDF files in less than 3 seconds and uses a comparatively small amount of memory. Scrolling is smooth, as well.

Re:Thank jebus that Apple invented Preview

[Chaos Incarnate]

Preview has a nasty habit of not displaying the PDF correctly, though. I'd rather slow-and-correct than fast-but-graphic-elements-get-randomly-shifted-on-the-page-or-dropped-entirely.

Re:Thank jebus that Apple invented Preview

[Mr. Slippery]

Evince loads large PDF files in less than 3 seconds and uses a comparatively small amount of memory. Scrolling is smooth, as well.

Even evince is starting to suffer from bloat. I've recently gone back to using xpdf on my desktop box, and put ePDFView on my netbook.

Re:Thank jebus that Apple invented Preview

[Larryish]

Is ePDFview in the Debian repos?

Re:Thank jebus that Apple invented Preview

[jimicus]

Indeed. You know what the easiest way to fuck with OS X is?

Treat it like Windows and install all the extras you'd want on Windows - even where equivalent functionality is already built in on OS X.

A couple of years ago I saw a MacBook Air that my US colleagues had purchased and done exactly that with. Even removing Adobe Reader sped it up no end.

Re:Thank jebus that Apple invented Preview

[tsa]

Foxit works better on Windows than Adobe Reader.

Re:Thank jebus that Apple invented Preview

[ColdWetDog]

Preview has a nasty habit of not displaying the PDF correctly, though. I'd rather slow-and-correct than fast-but-graphic-elements-get-randomly-shifted-on-the-page-or-dropped-entirely.

The couple of times I've had issues with Preview not displaying a PDF file, I have noticed that even in the full (OS X) version of Acrobat, the file is pretty wonky. I'm not sure that Adobe even knows what Adobe is doing.

Re:Thank jebus that Apple invented Preview

[John Hasler]

> Is ePDFview in the Debian repos?

Yes.

Re:Thank jebus that Apple invented Preview

[Chaos Incarnate]

I can't say that I've noticed that - it's always been fine in Acrobat. Then again, in those cases I've gone back to Acrobat on Windows, rather than installing Adobe Reader on my OS X machine, which might explain it...

Re:Thank jebus that Apple invented Preview

[RocketRabbit]

I have never seen this with a well-formed PDF. In fact, Preview is the reference PDF renderer for several graphic artists I know precisely because Acrobat seems to produce funny output with a significant minority of files.

Re:Thank jebus that Apple invented Preview

[Chaos Incarnate]

Well, I can't guarantee that the PDFs I've had problems with are well-formed. But since they're from outside sources, not much I can do about them besides use a renderer that works (Acrobat) instead of one that doesn't (Preview). :)

Re:this is about samsung

[MichaelSmith]

Samsung cell phone (SCH-W830) spontaneously combusted in my home ... might use Samsung products, which are selling like hot cakes

No kidding!

For a security researcher

[Anonymous Coward]

She's hot! http://www.idg.se/2.1085/1.339673/adobe-reader-ar-en-oerhord-risk

PDF as a standard vs a Standard for Documents

[DrTime]

Many years ago there was a standard in development called Open Document Architecture (ODA - ISO 8613) which defined a compound document standard which never became mainstream. Adobe's PDF was a proprietary product which became a mainstream standard encompassing content and presentation. The features described for a PDF are things some users will find a benefit. Good. What is upsetting is that these features are opaque. I don't know if everything dreamed of for ODA is in PDF, but PDF has solved many exchange problems with documents.

SGML (ISO 8879) offered a transparent document architecture which has been fragmented into HTML, XML, and its derivatives. A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency. We often confuse products, tools, standards,and technology and use the wrong product's technology as a tool. For example, I been given Microsoft Word DOCX files which would not work properly in Open Office and which could have been delivered as a PDF form or a simple DOC file.

There is nothing wrong with making the PDF file so powerful and providing simple tools (the reader) for people to open them. To me, the argument is over transparency. I may want to know what is inside a document that is being hidden from me. That is a matter of trust. The issue being addressed is trust and can we trust the PDF.

Re:PDF as a standard vs a Standard for Documents

[butlerm]

A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency

SGML is two full levels of abstraction higher than PDF. PDF isn't really intended to be a user editable document format at all. PDF is a page description language with a few extra features glued on. It was never intended to be editable, let alone provide any sort of document structure (aside from a table of contents), but rather to provide an accurate representation of printed pages.

SGML and HTML cannot do that without pixel perfect rules for layout, stylesheets, and font embedding. It is not likely to ever be a viable replacement for what PDF is good for, even with some sort of super container format. It is not like one can go anywhere on the web and download pixel perfect specification for the ultimate HTML / CSS layout engine. HTML layout is half specification and half folklore. Obviously extremely useful, just much more complex than PDF is.

Entirely different levels of abstraction make PDF rendering trivial compared to writing a good HTML/CSS layout engine. The layout has already been done by higher level tools, down to the level of exact page coordinates. Different kind of format good for different kind of things.

PDF is hacker-friendly way of making leaks

[shoppa]

I'm not so sure what anyone is in such a huff about. PDF is very hacker-friendly, and the confusion that the general public has in their belief that a PDF is just a "printer ready" format (as opposed to a general purpose vector-graphics, text, and programming environment) ALWAYS works to the hacker's benefit and never to "big brother's" benefit.

Perfect example: when the TSA's army of contractors "redacted" a document for public release, they simply drew (in PDF) black rectangles above the redacted text. Yet the original text was still there and intact.

Some here seem to view content that's below the surface (not visible with standard settings on standard Adobe tools) as a problem. Yet it is the perfect route to security leaks, a treasure-trove to anyone who knows how to look below the surface. And we hackers are the ones who know how to do that.

Re:PDF is hacker-friendly way of making leaks

[Thundersnatch]

The ability to press Ctl-A, Ctl-C, switch to a text editor, and press Ctl-V does not qualify you as a "hacker".

Re:PDF is hacker-friendly way of making leaks

[Anonymous Coward]

At this moment, he is clearly informative.

Re:PDF is hacker-friendly way of making leaks

[shoppa]

The knowledge that there is something actually informational there below the surface of glitz, is hacking in a way.

At one point I was sure that hacking - knowing what was going on below the surface - was by definition the ability to wire a flip-flop together and later to code in machine code and then Fortran. And using this to, say, put something up on the Rose Bowl scoreboard.

Today I am willing to enlarge that to typing Unix shell commands, and extracting hidden text from PDF's. Yes, both are relaxing the previous standards for "depth".

We have to watch out, because pretty soon just knowing of the ctrl-A, ctrl-C, Ctrl-V sequence is going to be tantamount to knowing how to build a blue box. Maybe just like we distinguish "hacking" from "phreaking", maybe we should distinguish mining PDF's or MS-Word .DOC's for hidden information from hacking? Hmm... PdFreaking? PreaDFing?

Re:PDF is hacker-friendly way of making leaks

[Anonymous Coward]

Repent.. for the time is near!

Re:PDF is hacker-friendly way of making leaks

[Gothmolly]

A real hacker doesn't call himself a hacker, you tool.

Re:PDF is hacker-friendly way of making leaks

[jklovanc]

This is in the same vein as someone running "rm -rf" on a hard rive full of sensitive information and then selling it. Anyone with a little tech experience knows that the data is still there. Ignorance of how a system works is not a problem wit the system; it is a problem with the user.

Re:PDF is hacker-friendly way of making leaks

[ian_from_brisbane]

A real hacker doesn't call himself a hacker, you tool.

Does he call himself gothmolly?

Re:PDF is hacker-friendly way of making leaks

[yuhong]

Perfect example: when the TSA's army of contractors "redacted" a document for public release, they simply drew (in PDF) black rectangles above the redacted text. Yet the original text was still there and intact.

Yep, the difference between vector and bitmapped graphics.

Re:PDF is hacker-friendly way of making leaks

[Anonymous Coward]

Hacking is the joy of learning. Nothing more nothing less. It may involve computers it might not. To someone new to computers who enjoys learning the mouse it is hacking. Simple stuff is hacking.

Re:PDF is hacker-friendly way of making leaks

[RocketRabbit]

Neither does the ability to program qualify a person as a hacker. A hacker is somebody who thinks outside the box, with playfulness and creativity.

Re:PDF is hacker-friendly way of making leaks

[david_thornley]

Similarly, many non-hackers have the knowledge to open a file in a text editor. There can be some interesting stuff there, quite apparent.

Let's abandon this outdated standard

[Anonymous Coward]

And start using something more modern and much more secure: XPS.

Re:this is about samsung

[Anonymous Coward]

You'd have better luck assembling an Angry mob if you swapped Samsung for Apple when making up that story. Samsung just doesn't get the emotions as high as Apple does.

PDF/A, PDF/X

[drolli]

There are two standards which are made for archiving/printing, where all the funny things are disabled and all the necessary thing are mandatory on board. How about not using the PDF standard when creating legal documents or other 100% perfect reproductions but PDF/A or PDF/X.

Everybody knows that PDF, as all formats which contain active (and nearly arbitrary) content are insecure.

Re:PDF/A, PDF/X

[Anonymous Coward]

Do you know of any good PDF/A (and PDF/X) only readers?

It is not so much the documents i produce I am worried about... it is what I get from the others.

Re:PDF/A, PDF/X

[drolli]

Good question. I always think acroread displaying a document as pdf/a should be enough.

PDF == EXE

[Anonymous Coward]

And woe unto those who do not treat it as such in their security model.

If you consider the social aspect of it, its even worse...many users will not run random programs sent even from well spoofed messages, but a "document" is as close to a thoughtless decision as you can find.

It all depends on the Reader

[Nom du Keyboard]

It takes a PDF Reader to implement all of these tricky features. Hey, had I designed the PDF standard I might have put in all of these cute features as well once upon a time. Now we need either a Reader Lite that only renders the text, or an option to Disable All Cuteness.

Or a truly effective sandbox environment since this has proven itself very harmful.

Or a new Safe PDF format that eschews all of the cuteness. Take you pick.

link to mp4 video of talk

[gibsganich]

to see the video from the congress, watch this: http://mirror.fem-net.de/CCC/27C3/mp4-h264-HQ/27c3-4221-en-omg_wtf_pdf.mp4