The result we aim for is to embed Internet Explorer within another application, and prevent users from performing anything but browsing the Intranet. Our IE is now secure (no bars, no shortcuts, no rightclick, etc), but we also want users to access PDFs within the browser without compromising our stations.
Using the Customization Wizard, we trimmed Acrobat Reader of many "vulnerabilities", but the options are not complete enough for our needs. Upon deployment, we want the browser viewer to:
- Not show a navigation panel, and disable the option to show it from the Context Menu
- Optimally, disable the right-click context menu in Acrobat Reader.
- Not show any toolbars and prevent users from displaying them.
- Disable many (most) keyboard shortcuts.
So end-users can view PDFs from the intranet, and that is all.
After much research, specifications about the various registry keys and options controlling most components of the viewer is very scarce and I'd appreciate pointers to online documentation about them.
Regards,
Adobe Reader has the ability to be actively embedded inside of another application. I don't mean the plugin model that Reader/IE integration works with. But, by using full OLE support.
What many folks don't realize is that you can attach Reader as a .NET/COM widget (er... component). With that you can identify what navigation items the person has access to. No print? No print widgets. No menus? Don't display them. Basically, you take control of the user interface through your own application and Reader is used as the PDF rendering engine inside of the component widget area. A.k.a. Rasterizer.
So, to draw this out a bit fuller. You have a VB app that draws a window. In that window you have a component widget (like a graphic) but it's a component of the Reader .NET/COM interface. You have buttons scattered around the window to only perform what you need - next page, previous page, zoom in/out, etc. Those trap their respective events and pass them along to the Reader component to do what you need accomplished. No widget? No workaround... unless someone builds a PDF that has them embedded inside as form objects. The only way around that is to completely disable JavaScript and Forms....
All the details surrounding this can be accomplished using the Acrobat SDK.
One word, though - you might be able to get away with this for an internal-only application (desktop, virtual environment or kiosk). However, if this is something you plan on deploying externally, selling or placing on a kiosk outside of your environment (someplace public, or not under your direct private control) - you will need to work with Adobe's legal department for appropriate licensing. In reading throught he Reader ReDeployment Agreement something tells me you are aren't going to get very far.
To be honest, I find it much easier to train my users on what to do/not do, along with a good set of corporate policies if they break the rules and do other than what you describe. Why? If you lock it down and they get around it, it's your rear-end in the sling. You are in control, then control. If you don't lock it down, but tell them not to do something, and they go and do it anyway, they're butts are in the sling.
Also, all you've done is given them a puzzle to solve. How can I get around this? There has to be a way...
That doesn't mean you can't take 'reasonable and customary' measures to ensure your corporate data and records, but I would stay away from the draconian efforts. Nobody wins.
The above opinions are mine and not that of my employer, who officially, does not have opinions.
Thanks
-Doug
Douglas Hanna is a member of the Production Print Technology team at Aon.
www.aonhewitt.com