Though Adobe has passed PDF off into the public domain there are still active pockets of PDF development going on around the world.
Google's CHROME seems to have some active PDF development activity though the focus seems to be on making Chrome use non-Adobe plug-ins for PDF rendering.
There is also "PDF Quick View" when you do a Google search that turns up a PDF (probably in gmail and other Google products as well - but I don't use those...). Its covered in this blog. This seems to work well over all - its generally a lot nicer than fooling around with the Adobe plug-in to see something.
The sad part of all this, though, is that Google is too stupid to understand the full picture of PDF, the one that includes print. (See this from Lone Wolf.) They only care about PDFs that fit into their model. A little digging will demonstrate that they don't fully support PDF rendering yet. I suppose they are working on it and one day will. But as we have seen they don't get color or many other things that many of us in the printing world know, love, and, most importantly NEED from PDF files.
Google is the king of ad placement - though I don't know if Adobe's exit from "PDF Ads" is good or bad in that regard.
More PDF activity is going on relative to SilverLight, PDF editors, and other tools.
There is also the ubiquitous http://www.planetpdf.com/ - though the forums and things there have not had much for years.
My fear is that without any sort of leadership PDF will become fully bastardized over the next couple of years. By that I mean that no one will step in to fill the leadership vacuum left by Adobe's exit from that position.
Each company with its own ax to grind will pick up the parts they care about and ignore the rest. Companies like Google will tear PDF apart faster than the rest because of their ubiquity.
Friday, October 15, 2010
Thursday, October 7, 2010
PDF - Technology to Live Without?
I found an interesting post here. Basically from an enterprise perspective PDF is a no-no - at least on the web - and it comes in at #3 on the list. I have seen this in the real world - many corporate types cannot receive PDFs in emails because they are blocked by the corporate fire wall. My belief is that IT types don't like PDF for a couple of reasons.
First, though it is relatively secure there are some clumsy problems like Javascript that make it seem like a risk.
There are various hack-schemes associated with PDF, javascript hacking chief among them from what I can see. This basically involves some mechanism to run or get you to run a nefarious javascript that has either been embedded in the PDF or is somehow linked to it via web browsing.
Adobe offers fixes for the elements that involve using the PDF to display a dialog that tricks the user into running a malicious app from the PDF as documented here. This is all linked together via the Zeus BotNet.
Second, the machinery of PDF is opaque to IT types. This is kind of an interesting point. I tracked down a Black Hat document on PDF threats (itself a PDF!) Eric Filiol, the author, is the Head Scientist Officer of the Virology and Cryptology Laboratory at the French Army Signals Academy.
Basically this document outlines some of the attacks I describe above as well as covers some PDF basics.
What is of interest to me is that its relatively shallow in the nature of what it covers. PDFs are relatively complex files and there are quite a few malicious holes in them. But this analysis stops short of doing much more than a superficial inspection.
They do cover the various Forms actions you can associate with elements of a PDF and they also cover some about registry settings and what they can allow or not allow in terms of security.
I suspect the reasons for this are that to process the guts of a PDF you need some relatively sophisticated technology. The paper describes the PDFStructAzer which is a tool they wrote to monkey with PDF files for hacking purposes.
I sent this guy an email offering to discuss PDF with him - but so far I have not received a response.
Third, and probably most importantly, is that the Adobe Acrobat and Flash worlds are relatively closed. What I mean by this is that on the IT side of the world there is a lot of activity and interaction between the developers and the corporate folks. Back and forth on the Microsoft side over formats, developer kits, and so on. IT folks don't like closed because it makes their jobs harder to do.
Silverlight, for example, is kind of a Flash/PDF replacement for web use. This went through a long beta period with lots of user input from developers.
Try that with an Adobe product.
From the AFP perspective there is much to learn here. AFP is much less complex security-wise than PDF so I doubt you will have nearly the issues coming from that side of things.
First, though it is relatively secure there are some clumsy problems like Javascript that make it seem like a risk.
There are various hack-schemes associated with PDF, javascript hacking chief among them from what I can see. This basically involves some mechanism to run or get you to run a nefarious javascript that has either been embedded in the PDF or is somehow linked to it via web browsing.
Adobe offers fixes for the elements that involve using the PDF to display a dialog that tricks the user into running a malicious app from the PDF as documented here. This is all linked together via the Zeus BotNet.
Second, the machinery of PDF is opaque to IT types. This is kind of an interesting point. I tracked down a Black Hat document on PDF threats (itself a PDF!) Eric Filiol, the author, is the Head Scientist Officer of the Virology and Cryptology Laboratory at the French Army Signals Academy.
Basically this document outlines some of the attacks I describe above as well as covers some PDF basics.
What is of interest to me is that its relatively shallow in the nature of what it covers. PDFs are relatively complex files and there are quite a few malicious holes in them. But this analysis stops short of doing much more than a superficial inspection.
They do cover the various Forms actions you can associate with elements of a PDF and they also cover some about registry settings and what they can allow or not allow in terms of security.
I suspect the reasons for this are that to process the guts of a PDF you need some relatively sophisticated technology. The paper describes the PDFStructAzer which is a tool they wrote to monkey with PDF files for hacking purposes.
I sent this guy an email offering to discuss PDF with him - but so far I have not received a response.
Third, and probably most importantly, is that the Adobe Acrobat and Flash worlds are relatively closed. What I mean by this is that on the IT side of the world there is a lot of activity and interaction between the developers and the corporate folks. Back and forth on the Microsoft side over formats, developer kits, and so on. IT folks don't like closed because it makes their jobs harder to do.
Silverlight, for example, is kind of a Flash/PDF replacement for web use. This went through a long beta period with lots of user input from developers.
Try that with an Adobe product.
From the AFP perspective there is much to learn here. AFP is much less complex security-wise than PDF so I doubt you will have nearly the issues coming from that side of things.
Subscribe to:
Posts (Atom)