Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

Acrobat/Reader 9.3 Now Available

The Adobe Reader Blog has a recent post describing what’s new with these security updates. Amongst other things, there is now a JavaScript Blacklist Framework which “provides customers granular control over the execution of specific JavaScript API calls.”

There is also an 8.2 update to Acrobat/Reader which includes some of these features as well.

Posted by Stefan Cameron on January 14th, 2010
Filed under Acrobat
Both comments and pings are currently closed.

6 Responses to “Acrobat/Reader 9.3 Now Available”

  1. Niall O'Donovan on February 22nd, 2010

    Hi Stefan,

    I had our first form fall over due to the new JavaScript Blacklist Framework and it was very painful!!

    The form makes (alas ‘made’) a https POST to a web service (in essence sending a SMS text message to a number of mobile/cell phones). This was developed specifically for a client, where they needed to deploy multiple SMS messages quickly. The text message string would depend on a number of factors, which the logic in the form handled for the user. All was running smoothly until today.

    I was alarmed at the level of scare mongering that ensued after the API button was clicked and even though I then clicked “trust form” the script failed to work from then on. Because the “trust form” process saved the form, it was then rendered completely useless.

    I appreciate that Adobe had a security gap to plug, but the current implementation of the yellow bar is alarming for users and leaves form developers swinging in the breeze.

    Would appreciate your insight in how to best negotiate this new restriction.



  2. Niall O'Donovan on February 22nd, 2010

    An update…

    I have been researching the web and KB and I have certified the form with our 3rd party certified digital signature.

    I have set the trust levels (imported the certificate into Acrobat), however while the yellow bar does not come up, the script does not work.

    If I could get it to work, then I am still left with the issue of getting individual users to go through the trust process. >:-(

    A series of screenshots is here (for a short time)

    Funnily enough it is a “FormCalc” script that is blacklisted, not “JavaScript”.


  3. Stefan Cameron on March 2nd, 2010

    Niall O’Donovan,

    Very frustrating indeed. Thanks for sharing those screen shots.

    Can you confirm whether or not you have any black-listed JavaScript APIs as per this article?

    Given your screen shots, you likely have some. Which ones are black-listed, in particular?

  4. Niall O'Donovan on March 7th, 2010

    Thanks Stefan,

    I had gone through the article, unfortunately the “manage javascript” link was broken.

    The preferences file appears to deal with:

    – DefaultLaunchAttachmentPerms
    – DefaultLaunchURLPerms
    – SponsoredContentSchemeWhiteList
    – FlashContentSchemeWhiteList
    – DefaultExecMenuItems

    The full script is at the end of the post.

    On Windows 7 there isn’t a cJavaScriptPerms in the FeatureLockDown

    HTTP appears to be on the white list for sponsored content and flash content.

    The script in the affected form is here:

    It is basically a https POST call.

    I am using Acrobat Pro 9 (9.3.1) on Mac OS X 10.6.2 and Acrobat Pro Extended 9 (9.3.1) on Windows 7.

    What I have discovered since is that the form does NOT work on the Mac version of Acrobat (irrespective of whether it is certified or not). However the form DOES WORK on the Windows version of Acrobat (both certified and non-certified forms work!).

    I would be interested to follow this through, so would appreciate if you could provide the article or another link to it.

    On the Mac the featureLockDown file did not appear to deal with a Javascript Blacklist. Irrespective it is unlikely that an external developer could get widespread access to change this within a client’s organisation. In addition I see it as being very difficult to maintain.

    I have started to learn Flex. While my experiences in LC Designer are useful when developing in Flex, it is different and I am starting at the bottom of the ladder. It seems to offer greater flexibility, for example I can now access databases without licensing restrictions.

    In some ways Flex/AIR will suit us better because often we are developing solutions rather than pure forms. However I would have preferred to have a choice rather than being forced down a route.

    The market conditions are very difficult and learning a new development environment when up against project deadlines is far from ideal.

    Thanks for your help on this issue,


    fyi FeatureLockDown from Mac version of Acrobat:

    << /DefaultLaunchAttachmentPerms [ /c <> ] /DefaultLaunchURLPerms [ /c <> ] /DefaultExecMenuItems [ /c <> ] >>

  5. Stefan Cameron on March 11th, 2010

    Niall O’Donovan,

    I did some digging and found the PDF that the Managing JavaScript Execution in the Acrobat Family of Products link (this is the good one) was pointing to. Hopefully that article helps-out somehow.

    Otherwise, it sounds like you might be hitting a bug, which you could log at Adobe with your findings and collateral. It would help us track-down the issue.

    Flex is a very powerful development platform. You should definitely learn all you can about it. I understand it’s no fun, however, having to do it in a hurry because something else is broken. Hopefully there’s a workaround for the JavaScript issue you’re facing on the Mac.

  6. Niall O'Donovan on March 15th, 2010

    Thanks very much Stefan,

    I have the document now and I have tried to implement, but without much change in the behaviour. I have also cross checked the preferences between both versions of Acrobat and all appears to be in order. I have reported a bug and we will see if that throws up anything.

    I will have to put this on the back burner for the time being, as I am full time on Flex at the moment. Thanks again for your help,