How to Track Printed Documents Using FileOpen Dynamic Watermarks

Posted by Diana Holm

When Adobe announced the PDF file format as an open document standard in 1993, it was meant finally to usher in the era of the “paperless office.” Despite the success of PDF as a platform-independent document format, we are still printing to paper—a lot. According to The Paperless Project, paper usage is increasing in American businesses at a rate of 22% a year, and the average office worker uses a “staggering” 10,000 sheets of copy paper annually.watermark200.png

This poses a unique challenge to publishers, who increasingly depend on the usage data and analytics which digital documents can provide, but not printed documents. For example, if a publisher sells a subscription of valuable research reports to one employee at a company, how do they know that employee isn’t printing out hundreds more copies, depriving the publisher of that additional subscription revenue?

Encrypting those research reports so that only the original subscriber can access them makes it harder for a user to share access to the digital version. FileOpen makes it possible to disable printing entirely, but if you allow the document to be printed and want to solve the rogue printing problem, you’ll need to take advantage of FileOpen’s advanced printing restrictions and watermarking features.

In this post we’ll walk you through how to limit printing of FileOpen-protected documents, and how to impose unique watermarks on each printout with user-identifying data. Using “dynamic” watermarks, you can auto-generate watermarks at the time of encryption and delivery, to include rich data which could be used to track a printout back to the user, time and device on which a document was printed.

How to Control Printing 

In FileOpen RightsManager and RightsServer, you set printing permissions according to the access control policies you define for your different groups, or recipients. So rather than assigning printing restrictions to the actual documents, you can give different recipients different levels of printing privileges to the same document.

Your options for restricting printing are:

  • Enable/disallow any printing
  • Set a notification when a document has been printed
  • Set the maximum # of print copies allowed
  • Specify which pages or page-ranges can be printed
  • Restrict printing to only physical devices (no print-to-file), or only to specific “whitelisted” printers
  • Set a percentage of the document you will allow to be printed
  • Print documents as lower resolution images so they are a degraded version of the original
  • Simply monitor printing activity, without limiting # of prints or prohibiting any print drivers

All of the above printing permissions require that the end-user be online. RightsManager and RightsServer also have offline permission settings, which can be used to allow or disallow offline printing, and to cap the number of prints allowed while the user is offline.

Add-Permission-Policy-Crop.png

FileOpen RightsManager offers a great deal of flexibility over printing, including the ability to render printouts in a lower resolution. 

You don’t have to set printing restrictions in order to use watermarks, but they add an additional layer of control to your valuable documents. Now, let’s move on to adding watermarks.

How to Add Watermarks

Prior to the development of the current FileOpen watermarking mechanism, some implementations of the system added watermark text to a PDF prior to encryption, then encrypted that PDF uniquely for a specific user. We refer to this as Static Watermarking and Dynamic Encryption. That is, the watermark text is static (always remains the same as what was imposed originally), and the encryption is done in real-time, or dynamically.

The current system implements Dynamic watermarks, and can be used either with Dynamic or with Static Encryption. That is, the text of the watermark can change each time the document is opened, and this can be the case whether the same encrypted PDF is opened by multiple users, or a unique encrypted PDF is created for each user.

Within any particular watermark policy, there is a similar distinction between static and dynamic text, both of which can be used simultaneously on the same document:

Static Watermark Text: These contain information you define in advance when you are setting up permissions policies for your recipients. They can contain a copyright message or any text you please. This text is literal, i.e what is specified in the policy is imposed into the watermark.

Dynamic Watermark Text: Dynamic watermark text is generated “on-the-fly” when a user opens or prints a document. This text typically contains information specific to the user, e.g. name or email address. This information is retrieved from the PermissionServer database and sent to the Client as part of the document open or print control event, so can be changed even after document delivery, e.g. for example to notify an end-user that a newer version of the document is available. FileOpen SDK licensees can take advantage of a rich syntax to dynamically place watermarks using data such as the machine ID of the user, IP address, and printer name/port that they used.

For the purposes of this post, we’ll walk through the process of generating watermarks using the WebUI of FileOpen RightsManager and RightsServer.

1. Create a Watermark Layout Template

The first step is to configure a Layout Template for your watermark (Watermarks > Layout Templates > Add Layout Template). Here you can choose whether to make your watermark a “Stamp”, in which case it will be superimposed on top of the document contents, or a watermark that is imposed beneath the text of the document. You can also define the watermark’s type (header, footer, diagonal up, diagonal down, vertical left up or vertical right down), the font (also the size/fill-color RGB, stroke width, stroke color RGB) and the aligment (left/right/center).

2. Create a Text Template

Next, create a Text Template to define the content of your watermark (Watermarks > Text Template Sets > Add Text Template Set). Here you can choose whether to date and time stamp each printout, include user-identifying information, etc. User-identifying information can include their email address, username, full name, company, IP address, printer ID, and many more data points.

Together, your Watermark Layout Template and your Text Template make up a Watermark Set.

3. Apply a Watermark Set to a Policy

Navigate to Policies > Watermarks. Click on the Policy Set you want to apply your Watermark to. For example, you might have a Policy Set for a site-license subscription, and want to add the watermark to all documents associated with that policy.

Applying watermarks at the Policy level frees you from having to create multiple different versions of the same document, because the watermark floats above the document as a separate object, and can be changed or removed even after delivery. When you assign your watermark to a Policy, you can define a different watermark for digital viewing and print, or only include the watermark on the printed version.

Here is an example of what your watermarks will look like on the resulting document:

 dynamicwatermarks.png

This example shows a printed PDF with both static and dynamic user-generated watermarks, visible in the header and footer of the page.

You can make your watermarks as noticeable or unobtrusive as you like using the design controls in Watermark Layout Template dialog.

The Result: Smart Printed Documents

By leveraging FileOpen’s print controls and watermarking features, you can close the loop on unwanted printing and reproduction of your documents. Including unique user-identifying data in your watermarks will render every printed copy of your document traceable back to the original user—even copies made with a photocopier. Because the watermarks appear below the text, they cannot be “whited out” without visible degredation of the document content. Watermarks not only reinforce your permission policies on the printed page, they provide you with actionable data on how your valuable and confidential documents are being used.

FileOpen’s print control and watermarking features are bundled with our RightsManager, RightsServer and SDK products for encrypting and controlling access to documents. FileOpen watermarks can be used on native PDF files for viewing/printing in Adobe Acrobat and Adobe Reader(end-user plug-in required), and on OPN files for viewing/printing in any web browser with no plug-in required.

Contact Us for a demonstration and consultation of FileOpen's watermarking and security features. 

 

Topics: document control, watermarks, watermarking, printing control

At SPAB 2016, FileOpen CEO Sanford Bingham Asks Standards Publishers: "What Would a Standard for DRM Look Like?"

Posted by Sanford Bingham

Last week I had the honor of speaking to an international group of standards organizations at the Standards Publishing Advisory Board (SPAB) annual meeting, hosted by our partner IHS. Standards Developing Organizations, or “SDOs”, are responsible for disseminating the documents that describe their industry’s or their country’s standards for building, manufacturing, military equipment, and so on (in the U.S., you may have heard of ANSISAE, and ASME standards). Thanks to standards, we have consistency and interoperability in the products and systems we use every day. 

Because of the mission-critical nature of their content, standards publishers are among the most exacting customers a technology company can have, and the choices they make can influence which innovations are successful in the publishing industry at large. Our host, IHS, is one of the largest resellers of standards documents, aggregating the work of hundreds of SDOs and expanding their reach with ecommerce portals and other technical enhancements.SPABlogo.jpg

This may seem like a quiet, boring segment of the publishing industry, but it is anything but. At the heart of standards publishing is a conflict between making essential information widely available to the technicians whose jobs depend on it, and the necessity of earning and protecting revenues for the standards bodies and the publishing companies that serve them.

Opinions run strong among the different SDOs as to how to achieve these dual goals—use DRM technology to prevent unauthorized sharing and uploading to sites with pirated documents? Or pursue copyright enforcement through legal channels, after a breach has been discovered? These questions have led to heated debates among SDOs and standards publishers, but as a community they resemble the U.N., ultimately seeking consensus on important issues (which is, after all, what standards are about). 

From the Format Wars to the Race to Be Everywhere: 20 Years of DRM 

The SPAB audience included many long-time FileOpen customers, as well as DRM skeptics and smaller SDOs who are just beginning to explore technology to protect their intellectual property. Rather than get into a philosophical debate about DRM, I presented a history of digital publishing and the facts of where we are today:

SPAB20Years.001.png

 

The upshot of this 20 year history is that the publishing landscape has become so complex, it is impossible (or would be foolish) for a publisher to choose one distribution channel or file format to distribute their content. Worldwide, the market share of viewing devices and web browsers is fragmented and in flux, with no clear winner (for example, Windows still dominates the desktop OS market, Android vastly outpaces iOS in smartphone operating systems, and Chrome is inching out the competition among Web browsers).

Even Adobe Reader’s market share of the PDF viewer market is being challenged by a long list of 3rd party viewers, many of them implemented without full adherence to the published PDF specification, which can lead to unpredictable changes in document display and behavior. The fracturing of the PDF landscape is both forcing and enabling publishers to provide content in other formats. For example, the Chrome browser does not support complex or DRM’d PDF files, but does include the Flash runtime (even on Linux). Likewise, nearly all mobile devices now have an HTML5-capable browser, so the explosive growth of those devices also creates an enormous new delivery platform. But on non-mobile devices, the HTML5 environment is less secure than either Flash or PDF, so the new environment also imposes a requirement that delivery software positively identify mobile devices as such.

Playing Whack-a Mole with Copyright Infringers

Meanwhile, piracy of standards documents continues to run rampant. Several SDOs described efforts to scan the web for illegally uploaded copies of their content, then sending DMCA (Digital Millennium Copyright Act) takedown notices to the owners of the host websites. One SDO reported having sent more than 150,000 such requests with a compliance rate of less than 50% (most of the sites are outside of the US so not governed by the DMCA legislation). 

So what is a standards publisher to do, and what role can DRM possibly play? The complexity of the publishing landscape poses a big challenge, but also an opportunity to embrace that complexity and use technology to serve the widest possible viewing audience. We’ve been working with a select group of standards publishers to develop a protected publishing system that is invisibleflexible and future-proof. 

FileOpen DocServer (currently in beta) will enable publishers to deliver content seamlessly to the widest range of devices and viewers, with the degree of security they choose, for the best possible end-user experience. Instead of publishing documents based on predictions of users’ devices and platforms, DocServer is based on a “detect, encrypt, deliver” model that serves documents dynamically based on the end-user environment. 

Ultimately, our goals are aligned with those of the standards publishing industry—to enable a frictionless experience for the users consuming documents, while employing technology quietly in the background to preserve the intellectual property and revenues of SDOs and publishers. I closed my talk with a question for the audience: “What would a standard for DRM look like?” We are looking forward to working with our partners to solicit feedback and help define a standard for DRM—because often real progress is the product not just of competition, but of consensus. 

 

Contact Us for a sneak preview of "The New DRM"--FileOpen DocServer

Topics: FileOpen, drm, pdf, Rights Management, Standards Publishing, SDOs

FileOpen Plug-in Update Available for MAC OS X

Posted by Diana Holm

We have released an updated FileOpen Plug-in for Adobe Acrobat and Reader for MAC OS X, Build 0967.   This new client implements support for the latest Adobe Acrobat/Reader. Specific improvements include:

  • Support for Adobe Acrobat Reader DC (64-bit architecture, with Broker process).
  • Modified and improved installation program.
  • Improved multi-language support.
  • Various bug fixes and other enhancements.

Note: This version supports Adobe Acrobat/Reader versions 8 through DC and 2015, and OS X versions from 10.6 through 10.11 (El Capitan), however B967 is installed only for Adobe 10 and up on OS X 10.9 and up. The installer delivers B958 for the remaining Adobe and OS X versions where B967 cannot be used.

This update replaces the MAC 0958 release from April 2015.

Accessing FileOpen-protected PDFs in a Web browser

Posted by FileOpen DRM News

The Web browser you are reading this article on is a small wonder of engineering.  Its origins can be traced back almost a quarter of a century, and is now one of 100+ available browsers serving over 360 million internet users.  With those statistics one can only imagine the rate of change when it comes to browser development.  Most of the time browser development improves user experience; making it faster, safer or more secure to surf the Web.  However, sometimes those advancements cause users to change their workflow or expectations on how a browser should behave.  In this post we are going to take a look at recent developments that affect users opening FileOpen-protected PDFs in a Web browser and how FileOpen is adapting to this change.

Browser_Icons.png

Say goodbye to NPAPI and ActiveX plug-ins

The presentation of PDF files in Adobe Reader within browsers has always been a somewhat odd and complex system. It works by Adobe installing a plug-in to the browser, generically the “Acrobat Helper”, which registers for the MIME type PDF and when the user clicks a link to a file of that type the helper launches or invokes the installed Adobe Acrobat/Reader program giving it the coordinates of the browser window. Acrobat/Reader then opens the PDF in an external window overlaying the window of the browser, such that the PDF appears to be displayed by the browser. When the file is encrypted using FileOpen the same thing happens with an added step of the FileOpen plug-in performing authentication and key retrieval prior to Acrobat/Reader displaying the file.

The above architecture was introduced somewhere around 1999 and has remained relatively unchanged except for some minor developments over the years. Recently, Chrome and Firefox have both deprecated NPAPI plug-ins, i.e. the mechanism by which the Adobe Helper operates, and both have integrated a native PDF viewer into the browser. It is still possible to configure Chrome to use the Adobe Acrobat/Reader as a PDF handler outside of the browser, but this advanced configuration will also be deprecated before the end of the year. Further, the new Microsoft Edge browser does not support any plug-ins, so Adobe cannot inject a mechanism to invoke Acrobat/Reader for PDFs opened in that environment (though Windows 10 also ships with IE 11, which does support Adobe integration). The bottom line is that Adobe or any other PDF Viewer that operates as a Plug-in is being excluded from the latest browser releases, and therefore FileOpen is being excluded as well. 

No, the Web isn’t going in reverse and losing features.  Instead, browsers are now supporting PDF files natively in the browser; they are just not quite there yet.  In nearly all cases this support does not include handling of complex PDF structures like forms, multimedia, or Security Handlers. So the user experience with PDF has become unpredictable, and demands system configuration, in ways that affect not only our solution, but every solution including Adobe’s own DRM. While FileOpen offers support for a number of other viewers (Foxit, Nuance, Nitro, Bluebeam, Tracker, etc.), neither we nor any other vendor can open encrypted files in the native Google Chrome, Apple Preview, Microsoft Edge or Mozilla PDF.js viewers.  We expect that this situation will only get worse over time, so alternative approaches should be considered.

Anticipating this, some years ago, we developed a set of technologies to convert PDF in real-time to renditions in Flash (.opn) or HTML5 (designed for clientless mobile delivery).  FileOpen customers are provided with a set of tools to do browser fingerprinting and detection which in combination with their defined policies, determines which format is most appropriate to the requesting user and device. Alternatively, we have added support for “encapsulation”, in which the encrypted PDF is placed into an unencrypted cover page that will display in any viewer and can be used to give the user some explanation of what needs to be configured and/or a link to the same content in one of the Web-friendly formats.

 PDF-and-HTML5-dedlivery.png

Contact us if you are interested in learning more about this functionality, or request a free trial.

 

Topics: Secure Document Viewer, pdf, Browser

Revoke or expire document access with FileOpen DRM

Posted by FileOpen DRM News

Today we are very much digital citizens with the world’s information at our fingertips; we are always on, operating in real-time.  The amount of data we produce is staggering.  Every time we share, copy to the cloud, re-name, edit and redistribute a file, we are scattering data. Often times this choice is made out of convenience rather than security or future data management work-load.  To put this into context, I logged into my personal Google Drive this morning.  I found sensitive and proprietary information in documents shared with me from former co-workers, bankers, lawyers and agencies that was no longer of great importance to me, but could cause significant damage if stolen, given to a competitor or otherwise abused.  While my example may not make big headlines, there is ample cause for concern.  As of this morning, there are 39,100 PDF files indexed by Google that have “not for public release” in the title.

While all of these documents may not truly be a security concern, they are just a result of one Google search,  and do indicate the magnitude of each document owner’s data sprawl; which, as a whole adds up to a serious vulnerability.   A vulnerability that can lead to lower business productivity, loss of competitive advantage, irrecoverable data loss or compliance violations; which, after all, is a fundamental responsibility of a document owner

So what can be done to address this? 

FileOpen document security and rights management solutions provide military-grade document encryption along with granular access and usage controls, enabling the document owner to share documents without giving up control. Today we will talk a little bit about core functionality within FileOpen software that allows document owners to expire file access based on predetermined usage, timeframe or date.  Additionally we will show you how to revoke document access, Mission Impossible style.   

How to revoke document access with FileOpen DRM

If the document owner determines business conditions warrant a change in who can access a FileOpen-protected document; the owner can instantly revoke a specific user’s access or access to a specific document by all users.   All changes take effect instantly.

Let’s look at an example. You send out a proprietary research to a number of people then later discover a critical error. In the meantime, that document has been edited, renamed, and saved locally to hundreds of devices. As the document owner, you can revoke access instantly with a simple tick of a checkbox. Now none of the recipients will be able to open any copy of that protected document. You can then send out an updated copy without the embarrassing error.

Here’s another example. You protect sensitive legal information in a document and send it to business partners and select staff. After a falling out, you are no longer business partners with one particular company. You can revoke access for the users in that particular company alone. All other users can still access the document without interruption.

How to Expire Documents with FileOpen DRM

In addition to instant revocation, FileOpen software can be configured to expire document access on a predetermined date, after a given timeframe or after a certain count of opens or prints.    To demonstrate, let’s look at another example.  You are preparing my company’s quarterly financials and need to distribute early drafts to a small group of staffers and outside legal counsel.  All access to this draft is to cease on October 5st, the day before earnings are made public.  You start by creating a Group within the FileOpen PermissionServer; a collection of authorized users, your protected files, and the policies that govern the usage of those files.  Within the Group you specify the permissions that will govern the usage of the documents. For this situation, you will set an absolute expiration date of October 5, 2015. 

After preparing the permissions for the Group, you add all authorized Users into the same Group through a quick pull down menu. As a side note, this step could be automated depending on your use case or workflow requirements; FileOpen integrates with existing ADS/ SSO system, eCommerce systems, enterprise file-sync-and-share or learning management tool; making it easy for administrators to centrally manage users and permissions. 

The next step is to protect the draft documents and add them to the Group.  You simply drop the source files into a watched directory on your local machine and FileOpen software does the rest. 

 

An encrypted version of your source document is created and placed into a corresponding Encrypted folder on your machine.   The only thing left to do is to distribute the document to the authorized Users.

On October 5th all access to the protected drafts is cut off, no matter where authorized users have stored the document.  The only way this draft can be opened after the expiration date is if/when the document owner re-enables the document from within the PermissionServer by modifying the expiration date.

Would you like to learn more?  Request a quick demo or get a free 14-day trial to test expiration and revocation for yourself.

 

How to Protect PDFs without Passwords

Posted by FileOpen DRM News

How many times per day do you have to remember your username and password to access an application or Web page? According to a recent TeleSign study, consumers have an average of 23 online accounts, and more avid Internet users have a much higher number.  In my own experience, as of noon today, I’ve already logged into 9 different applications - all of which have required username and password authentication. To make matters worse, I had to reset a password to a website I hadn’t used in a while.  That said, we at FileOpen know just how frustrating it is to manage what seems is a never ending list of credentials in your head.  So today’s post will cover how you can protect your high-value documents without some of the inherent pain points and security issues associated with username and password authentication. 

blog-call-out

The problem with passwords

Passwords are the most common way users confirm their identities.  However, passwords are also considered a weak form of authentication.  The truth is that there’s nothing wrong with passwords; the problem is the user. Users experience what is known as password fatigue; they select passwords that are too simple, too predictable, they re-use the same passwords across systems, they fail to change their passwords on a regular basis, and much to our disbelief, users log credentials in notebooks usually kept alongside their machine.  As you can see, the Personal Internet Address & Password Log Book retails for $6.49 and is currently a #1 Best Seller on Amazon. 

Amazon-Best-Seller-Password-Log

In addition to password fatigue, users fall victim to cybercriminal’s phishing and spoofing scams.  And finally, what is to keep a user from lending their credentials to someone else?

 

FileOpen Approach: Securing documents, without passwords

FileOpen document security software offers businesses a variety of authentication modes designed to alleviate the pain and insecurity of traditional username and password authentication. 

The first out-of-the-box mode of authentication is device or machine authentication.  With this mode, users authenticate once by opening a FileOpen Registration PDF on their desktop, laptop or iOS device with the FileOpen Client.  Once opened, the FileOpen Client sends a list of machine identifiers, unique to that user’s device, to the governing PermissionServer which then logs the information within the user’s profile as a registered device.  After opening that registration PDF, all subsequent access requests by that user are permissioned by validating the user’s machine identifiers with the governing PermissionServer.  This means the whole identification process is invisible to the user and is exactly the same as opening a non-protected PDF file.  All permissions are obtained from the document owner’s PermissionServer in real-time, and are specific to that user’s device. Permissions are not portable in any way that the user can control; permissions are locked to the original device. 

FileOpen_Registration_PDF

The FileOpen software may also employ additional means of authentication.   FileOpen integrates with existing ADS/ SSO systems, eCommerce systems, enterprise file-sync-and-share or learning management tools. These options make it easy for administrators to centrally manage users and permissions, without requiring users to manage yet another password.  In addition, custom configurations can be deployed to support cookie-based authentication, domain authentication, and user log-in authentication. 

 

While businesses truly dread the challenges and problems posed by passwords, it still remains a core authentication and security technology. And, as mentioned above, we don’t believe passwords are the root of the problem, we believe it’s the human element.  With that being said, FileOpen does support username password authentication and includes features to ensure security.  These features include:

  • Device limits: Owners may designate the maximum allowable count of devices that user may access a protected document from.  The smaller the number the more secure the system.
  • Revocation:  Allows owners to instantly disable access by document, user or user’s device.
  • Tracking:  Logs all access and usage by document or user ─ even failed access attempts.  This information includes device / machine identifiers, user login, host name, IP address as well as date and time.
  • Viewing Requirements:  Allows document owners to limit document access to specific operating systems.
  • Usage Controls:  Prevent or restrict copy/paste, printing, editing, saving and screenshots.

 

Want to learn more?  Start a free 14-day trial to see how you can start protecting your PDFs, without passwords. 

FileOpen Viewer for iOS (v2.4.0)

Posted by FileOpen DRM News

 

We are pleased to release the latest version of the FileOpen Viewer for iPad®/iPhone®.  The app updates like any other app you are accustomed to.  If you don’t have automatic updates enabled you will need to manually press "update" from the AppStore.  
 

ios-1

What's New in Version 2.4.0

  •          Updated to support wider range of PDF files
  •          Improved decryption speed
  •          Added support for location services and device identification
  •          Small bug fixes and enhancements

This update replaces version 2.3.4 posted to iTunes in Jannuary 2015.

Client-side vs. Web-based document security

Posted by FileOpen DRM News

The more things change, the more they stay the same

In the early 1990’s client server architectures were ubiquitous. Businesses managed their own servers, software, and productivity tools for their workforce.  In the 2000’s, the growing adoption of the Web introduced new opportunities and serious new threats to the IT landscape. Businesses responded by installing more infrastructure; typically more hardware in the data center. The idea was to establish a perimeter around the business to keep hackers out and intellectual property (IP) in. Fast forward to 2010, the world had completely changed: Web access was ubiquitous. Social media, collaboration tools, file sync-and-share, and mobility (BYOD) were unstoppable forces.  However, the more things changed the more the need to protect sensitive, regulated or corporate IP stayed the same.

client_side_file_encryption

Today businesses have embraced this new era, accepting easy-to-use, always-available productivity tools delivered to everyone in their workforce, anywhere in the world, on all their devices, in real time.  By doing so, these companies not only realize a broad array of capabilities but a distinct cost savings of no longer maintaining servers and software in-house.  However, the downside is that centralized, perimeter-based security solutions no longer make sense.  

So, the question becomes: do you trust security measures provided by third party Web-based service providers, or do you apply client-side security to persistently protect your IP? 

Client-side vs. Web-based document encryption

With Web-based encryption, documents are encrypted by the sender, at the server, so that only the receiving party can decrypt them. This approach is designed to keep files safe during transfer, but both ends are often left vulnerable.  For example, in October 2014, Dropbox was a victim of a sender side breach.  Dropbox users had their usernames and passwords released on Reddit, giving millions of Internet users access to the contents of their accounts. Because the content stored in the cloud was not encrypted, any user with credentials could access that content.

client-side-file-encryption

Had those same documents been encrypted prior to being uploaded to Dropbox, the damage would have been significantly reduced. With client-side encryption your documents are always protected; only authorized users can access the content no matter how the document is obtained or where it is stored.  The same goes for your third-party service providers, with client-side encryption your Web App providers have “zero knowledge” of your content; meaning they can’t access or disclose your company’s private information.  Client-side encryption is the only option that offers that kind of security.

In addition to security, client-side tools have definite business benefits.  With client-side encryption tools your workforce is equipped to apply document encryption on the machine they use to author high-value documents.  It is always available; empowering your workforce to easily apply document security measures without opening a browser, remembering credentials, or additional steps.   Furthermore, having the encryption App local to the machine increases the likelihood of it becoming part of the user’s daily routine; a constant IP protection reminder, if you will. 

FileOpen Solutions

At FileOpen, we have been building document security solutions for our customers since the early 90’s.  We were the first Adobe Technology Partner to build a third party plug-in to control access and usage of PDF documents.  The solution consists of three basic components; document encryption tools, a permissioning server to govern access and usage, and a versatile set of clients and viewers.  Customers have the option to host their own permissioning server, RightsServer, or leverage a hosted version, RightsManager.  Both solutions offer true client-side document encryption tools. Put simply, we don’t ask you to upload your source documents to our server for encryption. 

FileOpen offers several configurations for client-side encryption to meet varying business needs.  At the most basic level, users simply drop their unprotected documents into a monitored directory on their machine.  That action initiates the encryption process and within seconds an encrypted version of the same document is placed into a directory of the user’s preference.  The file can then be distributed by any means available.  If appropriate there is an option to mirror the output folder to many popular file-sync-and-share sites through oAuth or other APIs.  In addition to our basic directory monitor interface, FileOpen software can be configured to programmatically encrypt all documents created on a given machine or server, as they are created or on-the-fly, as the documents are being requested. 

 

Want to learn more? Contact us if for a quick demonstration or start a free 14-day trial.

 

 

Topics: document encryption, security, DRM advice, DRM mistakes

FileOpen Client 0963 for Adobe Acrobat/Reader (WIN)

Posted by FileOpen DRM News

We have released an updated FileOpen Plug-in for Adobe Acrobat and Reader for Windows, Build 0963.   This new client implements support for the latest Adobe Acrobat/Reader and includes minor bug fixes and enhancements.  This update replaces the Windows 0962 release from July 6, 2015. 

FileOpen Client 0963 is backward-compatible to Adobe Reader/Acrobat 9.  We recommend that you encourage users to upgrade to the 0963 client.

Topics: FileOpen plug-in, Client Release

FileOpen Client 0962 for Adobe Acrobat/Reader (WIN)

Posted by FileOpen DRM News

We have released an updated FileOpen Plug-in for Adobe Acrobat and Reader for Windows, Build 0962.   This new client implements support for the latest Adobe Acrobat/Reader. Specific improvements include:

  • Support for SHA-2 password hashing.
  • Updates to the FileOpen Broker.
  • Additions to application whitelist affected by screenshot prevention measures.
  • Support for print command, shrink to fit. 
  • Various bug fixes and enhancements.

This update replaces the Windows 0958 release from April 2015.

FileOpen Client 0962 is backward-compatible to Adobe Reader/Acrobat 9.  We recommend that you encourage users to upgrade to the 0962 client.

Topics: FileOpen plug-in, Client Release