FileOpen Document Security Blog

FileOpen Client for Macintosh Build B990 Released

sbingham@fileopen.com (Sanford Bingham) — Tue, 29 Jul 2025 18:51:12 GMT

The latest FileOpen Client for Adobe Acrobat/Reader on Macintosh, Build990, has been released and can be installed from https://plugin.fileopen.com

This build includes a number of changes and bug-fixes, including the following:

An issue with printing, which impacted print jobs where a specific range of pages was selected.
An issue with dynamic watermarking affecting imposition of watermarks containing CJK characters that caused a crash.
An issue with dynamic watermarking in which some UTF-8 characters were incorrectly encoded.
An issue with dynamic watermarking affecting layout/positioning of marks.
An issue with the print dialog when system language is not English.
An issue causing a crash for some documents when making http requests.

FileOpen Client Build 1016 Released

sbingham@fileopen.com (Sanford Bingham) — Tue, 29 Jul 2025 18:39:04 GMT

The latest FileOpen Client for Adobe Acrobat/Reader on Windows, Build1016, has been released and can be installed from the page at https://plugin.fileopen.com

This build contains the following bug-fixes:

An issue with printing, which impacted print jobs where a specific range of pages was selected.
An issue with dynamic watermarking affecting imposition of watermarks containing CJK characters that caused a crash.
An issue with dynamic watermarking in which some UTF-8 characters were incorrectly encoded.

FileOpen Client for Macintosh Build B988 Released

sbingham@fileopen.com (Sanford Bingham) — Wed, 30 Apr 2025 17:46:08 GMT

The latest FileOpen Client for Adobe Acrobat/Reader on Macintosh, Build998, has been released and can be installed from https://plugin.fileopen.com

This build incorporates a new print dialog and augments the data sent to the PermissionServer in the client/server print-control interaction.

It also includes changes to enable operation in Protected Mode, which is currently in preview for Acrobat/Reader.

Installation of the new Client does not require uninstall of the previous version.

FileOpen Client Build B1014 Released

sbingham@fileopen.com (Sanford Bingham) — Wed, 30 Apr 2025 01:35:45 GMT

The latest FileOpen Client for Adobe Acrobat/Reader on Windows, Build1014, has been released and can be installed from the page at https://plugin.fileopen.com

This build addresses issues on Windows 10 and/or versions of Acrobat/Reader prior to Acrobat DC.

Previous versions of the B10xx series would in some configurations present an error message stating that the "FileOpen Client has encountered an error."

This error should not occur with B1014.

The B1014 version also removes the FileOpenManager service that was introduced into the Client in Build883 (2010).

The FileOpen Client now operates entirely within the Acrobat/Reader environment, with no modules loaded except when Acrobat/Reader is running.

FileOpen Client for Windows Build1010 Released

sbingham@fileopen.com (Sanford Bingham) — Tue, 18 Feb 2025 19:48:00 GMT

The latest FileOpen Client for Adobe Acrobat/Reader on Windows, Build1010, has been released and can be installed from the page at https://plugin.fileopen.com

This Client implements a new architecture that leverages functionality provided by Adobe Systems to enable operation inside the Windows AppContainer sandbox. Previous versions required modifications/workarounds in order to fully load on systems running Windows 11 with the 24H2 update.

The Acrobat "PIBroker" system also manages the load/unload of the Broker process, where the previous version relied on the Windows OS, and this should make the B1010 more robust and eliminate errors related to loading of the Broker process.

Disney, Slack and the case of the missing 13,000 PDFs

sbingham@fileopen.com (Sanford Bingham) — Wed, 25 Sep 2024 10:00:00 GMT

The Walt Disney Company has announced that it will stop using Slack for internal communications following a breach in which data was exfiltrated by a hacker group.

The breach happened in July, but is again in the news because Disney has reportedly decided to replace Slack with MS Teams. Given the timeline and facts, there is speculation that Disney’s move is more about cost cutting, and possibly blame shifting, than security.

As a developer of document security solutions for enterprise platforms including Slack, I did some digging into what actually happened, and conclude that this was not a hack – Slack’s security wasn’t broken, but rather it was a breach enabled by a user who was, at best, granted too much access and, at worst, was an active participant.

How the hackers got in

The hacker group, an outfit called NullBulge with unclear origins and motives, gained access by compromising the private laptop of a Disney employee with malware, then scraping all the Slack content accessible to that employee.

The employee had access to 10,000 internal Disney Slack channels, and the contents of those channels include some 13,000 PDFs and an even greater number of other documents. The content appears to have been mostly related to Disney’s theme parks and the administration of websites, but as Disney is built around creating and licensing intellectual property, the potential damage from stolen documents is substantial.

It seems likely that the employee helped the hackers, at least initially. In their announcement of the hack NullBulge doxxed a Disney employee, claiming that “We tried to hold off until we got deeper in, but our inside man got cold feet and kicked us out!”

A recent blogpost by Slack on the topic of security seems to address the Disney announcement, albeit in a very polite way (“Cybersecurity is a shared responsibility”). If Slack wanted to be more blunt they’d be within their rights to say that the breach was not due to a security issue in Slack and wouldn’t have happened if Disney had not:

Let the employee log-in to Slack on a private, non-company-issued, computer,
Failed to scan the computer for malware (a mod for the game BeamNG),
Permitted the user to share credentials,
Missed data in the Audit logs that would have disclosed the breach.

Switching to Teams isn’t going to stop this from happening again, unless/until Disney’s security team addresses these issues. Indeed, Disney now faces an even greater challenge in switching thousands of employees in their creative divisions accustomed to using Slack to an unfamiliar and decidedly less engaging platform. Some of these employees will likely “go rogue” and continue to use Slack, or other messaging apps, on personal devices and/or set up new accounts that aren't administered by Disney IT, further expanding the company’s risk surface.

How it could have been avoided

That said, there are steps Disney should have taken to minimize risk. Slack lists these in the aforementioned blogpost. The main ones are:

Set up Identity and access controls (SSO and 2FA, timed sessions, etc.)
Implement Device Management (EMM, jailbreak detection, browser control, etc.)
Configure data protection, detection, and alerting (EKM/DLP, Audit log APIs, etc.)

The last of these includes implementation of Enterprise Key Management (EKM) and Data Loss Prevention (DLP). These are both solutions designed to prevent the exfiltration of data.

One additional step that Disney could have implemented is to encrypt and protect content uploaded into Slack, in this case specifically the 13,000 PDFs that were stolen in the breach. Had some or all of these PDFs been encrypted using a tool like FileOpen Sharebot for Slack then those PDFs would have been unusable outside of Slack, even if downloaded along with the rest of the stolen data. As far as I know, Sharebot is the only app that addresses this issue at the document level, by encrypting the PDFs and only allowing them to be viewed in the context of a viewer that requires authentication via Slack. This case is an example of the risk that Sharebot is designed to address.

There are a number of lessons here, but the main one is that even the most security-focused SaaS platform must be monitored and properly implemented. Slack has done the work to create a secure platform (if in doubt, have a look at the stringent requirements for FedRAMP Authorization). But security is a process of continual improvement. As Marc Benioff put it :

“Our security is rock-solid. This is really important. Also, there’s no finish line when it comes to security. But companies have to also take the right measures to prevent phishing attacks and to lockdown their employees from social engineering. So, we can do our part, but our customers also have to do their part — that’s extremely important.”

Sanford Bingham is Founder and President of FileOpen Systems Inc., one of the leading developers of Digital Rights Management (DRM) software for documents, especially PDF. The company’s tools enable strong encryption and access control in accordance with the PDF (ISO 32000) specification and have been in use for over 20 years.

More information about FileOpen Sharebot for Slack is available at https://www.fileopen.com/sharebot-for-slack

The Sharebot app has been approved by Slack for distribution and can be installed from the Slack App Directory

Introducing Sharebot: The new FileOpen app for end-to-end document security in Slack

sbingham@fileopen.com (Sanford Bingham) — Thu, 18 Apr 2024 16:12:58 GMT

As a longtime developer of rights management solutions for digital publishing, we often talk to customers who are looking for a way to share internal documents securely within and between organizations. (These inquiries normally peak after a well-publicized document leak that exposes confidential information or intellectual property).

In the enterprise scenario, document security is binary and based on complete trust of users - you either have access or you don’t, and if you do, there’s not much stopping you from sharing it externally. Even “Data Loss Prevention” products can’t stop a legitimate user from either accidentally or intentionally sharing a confidential document, and provide at best a whack-a-mole solution. That’s because enterprise security stops at the firewall, and can’t reach beyond to control access to escaped documents.

Enter FileOpen Sharebot for Slack - our new app that provides end-to-end document control in Slack, the most popular platform for collaborating within and between organizations. By integrating with Slack and Slack Connect, FileOpen Sharebot offers a user-friendly and effective solution for enterprise document control.

How FileOpen Sharebot adds a critical security layer to Slack

Slack provides the essential components of communication, identity management, and file delivery in a single familiar context – and FileOpen Sharebot adds an additional layer of file-level security and an enhanced document viewing experience. The result is a plug-and-play secure document sharing solution that empowers anyone in Slack to limit access to the users and channels they designate, even across different workspaces.

FileOpen Sharebot also improves the end-user experience by seamlessly authenticating via Slack identity, with no additional password or authentication requirement. Integration with federated identity and single sign-on (SSO) is also supported. This means that when you share a document protected with Sharebot, your recipient won’t encounter any additional authentication hurdles - if they’re signed into Slack and you’ve given them permission, they can view the document instantly.

Protected documents may not be shared to other channels, downloaded, or extracted, adding a critical layer of security for documents that contain confidential or private information. With Sharebot, every Slack instance can become a secure portal, a locked-down virtual deal room, a regulation-compliant workspace, or all of these at once.

FileOpen Sharebot: Limit document sharing to a specific channel

How Sharebot Keeps Your PDFs Safe

FileOpen Sharebot extends Slack’s secure environment to PDF files themselves with our robust and market-tested approach developed over decades as a certified Adobe security partner for PDF.

Sharebot's end-to-end PDF document security includes:

Access Control: Protect PDF files uploaded to Slack by limiting access to specific members of a Channel, Conversation, or Workspace. Revoke access rights at any time, even after you’ve shared the document.

Track Usage: Sharebot notifies the file owner each time the file is accessed, and maintains a complete record of all actions related to that file.

Watermark: Each time a document is opened, the user’s name and other information are imposed onto each page.

Upgraded Viewer: The FileOpen Sharebot document viewer extends the functionality of the native Slack PDF viewer, adding tools to annotate, link, measure, edit, and print (if permitted).

Real-World Applications of Sharebot

Sharebot is for any team that handles sensitive or proprietary documents, especially those that need to be shared securely with outside stakeholders. The app is robust enough to be used in regulated industries, but flexible for situations where users are collaborating across different IT environments. Here are a few examples of ideal use cases for Sharebot:

Legal Document Security: For sales teams handling sensitive client contracts and proposals, ensuring access is restricted to authorized channel members.

Financial Report Distribution: Financial institutions benefit from secure, controlled sharing of critical financial data with stakeholders.

Healthcare Data Confidentiality: Healthcare professionals can share patient records and medical information, confident in their data's privacy.

HR Document Management: HR departments can securely distribute sensitive employee documents, ensuring access is limited to intended recipients.

Education and Research Security: Academic institutions and research bodies can protect their scholarly materials and student information, adhering to privacy standards.

Prioritizing your document security with FileOpen Sharebot

In an age where information is currency, protecting your PDFs is not just a good idea; it's a necessity. Sharebot seamlessly combines the convenience of sharing via Slack with enterprise-grade security measures, ensuring that your documents remain confidential and accessible only to those you trust.

Whether you're sharing sensitive contracts, a financial expert distributing critical reports, a healthcare provider safeguarding patient data, or an educator sharing research findings, Sharebot is here to protect your business and reduce your exposure to noncompliance and leaks.

Sign up here and get started today! We’ll keep the app free of charge for now. By signing up today, you’ll lock in a discounted price for our paid tiers.

How to prevent content in PDFs from being “scraped” by AI

sbingham@fileopen.com (Sanford Bingham) — Fri, 01 Mar 2024 02:20:04 GMT

In December 2023, the New York Times filed suit against OpenAI, claiming that ChatGPT was built from “uncompensated use” of the Times’ “intellectual property.” The filing showcased hundreds of examples in which answers from the chatbot were nearly identical to articles published by the Times. More disturbingly, multiple answers that were attributed to the Times hadn’t ever been published, and some even contained false information.

It may be years before courts rule on the legality of data-collection methods used by OpenAI (and, by extension, most or all commercial Large Language Models (LLMs)). In the meantime, publishers are expressing concern about how and when their content is ingested into LLMs, and urgently seeking technical solutions to prevent their intellectual property from being used to train LLMs and regurgitated in unpredictable ways by AI tools.

Why publishers of high value PDFs are concerned

Some digital documents are already sold under contracts that expressly forbid indexing, summarization, and use in training LLMs. In nearly all cases these documents are distributed as PDF files, because PDFs are digital containers for information that can be controlled at the document level.

For example, restrictions on use in AI are now included in the sale agreements for PDFs of technical standards, for several reasons:

The text of standards documents is precise and any condensation or rephrasing might change the meaning of important parts, which for certain types of standards (aeronautics, fuels, heavy machinery, etc.) could lead to catastrophic outcomes.
Even the most sophisticated LLMs regularly introduce errors, aka “hallucinations”, into their output and there is currently no reliable way to distinguish between the good answers derived from the original text and those made up by the model. Some systems attempt to address this concern by including references to the source text, but links only mitigate risk of inaccuracy if the user properly compares the answer with the citation.
Data ingested into a LLM by one user may become part of the training set for that LLM and thus be made available to other users, in violation of copyright. Most commercial LLM offerings now include some kind of segmentation to prevent unsanctioned use, but the effectiveness of these controls remains untested.

How AI LLMs extract content from PDFs for training

The mechanism by which LLMs ingest PDF content is, at a high level, no different from that used by search engines: it involves extraction of text from the PDF and then processing to organize and structure the text to enable indexing or, for LLMs, “tokenization.”

There are significant technical differences between how the extracted text is processed/tokenized, but insofar as both approaches are built from the initial PDF text extraction they expose the same risks and complications, including:

Some PDFs have no text to extract, because they are images of pages. In this case the text must be generated using Optical Character Recognition (OCR), which is generally accurate but almost never produces perfect results.
PDFs are typically unstructured data and some elements – especially tables, charts and special formatting – are difficult to parse, even for the most sophisticated tools.
PDFs often contain complex punctuation and other typographical constructs that may change the meaning of text if not properly understood, especially if the text is in an unusual language.

The text of encrypted PDFs, however, cannot be extracted. So a PDF that has been encrypted – either with a password or via a Security Handler like FileOpen – cannot be either indexed or ingested into an LLM.

Encrypting PDFs is the most effective defense against scraping

So how does this work?

The contents of an encrypted PDF can only be read by an application capable of decryption that has access to the required key. There are two ways of accomplishing this, and which approach you take has everything to do with the size of your intended viewing audience, and whether you know who they are in advance.

Password Method (Standard Security)

One way to encrypt a PDF is by using the built-in “Password” or “Standard” Security Handler, which nearly all PDF applications support. This is the method that stops you from opening the PDF until you input a password.

Password Security isn’t useful except to keep information to yourself or to share it with people that you trust. It is necessary to trust anyone who has the password, because there’s no way to prevent that person from sharing both the PDF and the password.

Password Security also doesn’t scale well, both because adding passwords is typically a manual process and because it is necessary to distribute both the PDF and the password (which ought to be different for each PDF). Password security just wasn’t designed for publishing or other broad distribution.

Security Handler Method (FileOpen Rights Management)

The PDF format has support for other “Security Handlers,” like FileOpen, that can encrypt the contents of the file either in advance or in real time on demand, and selectively enable decryption in specific applications, for specific individuals or groups, etc.

When viewing PDFs encrypted with FileOpen, the authentication process is normally invisible to legitimate, authorized end-users, but locks out unauthorized users and bots.

Encrypted PDFs can also be delivered without requiring authentication. That is, a website can contain links that anyone can click to view the PDF in a browser, but the PDF content is still protected against extraction by AI crawlers and users are prevented from downloading/sharing the files.

Content owners shouldn’t wait to deploy encryption against AI scraping

As the various lawsuits against AI operators demonstrate, Copyright is not self-enforcing. Protecting intellectual property requires either technical measures, like encryption, to prevent unauthorized use or legal action to remedy past abuses.

Implementing systems to prevent theft of content is simple, inexpensive, and effective. Eventually the legal system will determine whether the alternative - going to court in an attempt to redress past actions and to enjoin future ones - also works.

The images in this post were generated by Google Gemini.

Announcing FileOpen BrowserUX: Share PDFs Securely with No Plug-in Required

sbingham@fileopen.com (Sanford Bingham) — Sat, 13 Feb 2021 04:52:39 GMT

We are excited to announce production availability of our system to display FileOpen-encrypted PDF in any modern browser, on any platform, without installation of any software!

FileOpen BrowserUX works for any PDF encrypted with the FileOpen software, now or in the past, and delivers the files as native PDFs (not converted to images or any other format). All of the core functionality and security of FileOpen PDFs displayed in Adobe Acrobat/Reader can now be delivered without installation of the FileOpen Client.

What does this mean for you and your users?
Now you can deliver PDF documents securely, with the same rich feature set of access controls, to your intended users regardless of their particular environment. Your users won’t have to install any plug-ins or client software to access protected files, reducing friction and tech support issues.

How FileOpen BrowserUX works
All components of the system are built from the W3C and ISO standards that define the Web and PDF. So the user experience is the same in any modern browser (Chrome, Safari, Firefox, Edge. etc.) on any supported platform (Windows, Mac, iOS, Linux, Android and Chromium.)

As has always been true of FileOpen products, the PDFs displayed in the browser are ISO 32000-compliant, full-featured PDFs so retain all PDF navigation features (bookmarks, thumbnails, etc.) and preserve accessibility. The files are the very same encrypted PDFs that might otherwise be opened on the desktop via Adobe Acrobat/Reader (and other viewers that support the FileOpen Client). Because of this commitment to standards, FileOpen BrowserUX is fully backward compatible to even the very first FileOpen-encrypted PDF -- any PDF that can be opened in Acrobat/Reader can now also be opened in the browser.

Permission to decrypt and use PDFs in the browser is managed by the same PermissionServer logic used to control access in Acrobat/Reader. So user identity and credentials can be the ones in use today, and the same permission controls and watermarks can be imposed. Because it runs in the browser, the system enables integration with single-sign on systems like SAML and with other web components or portals. And since no server-side format conversion is needed, the system can scale up to handle even the largest implementations.

How is this different from other DRM products that work in the browser?
Many of the PDF viewers that have been developed in the past decade, especially the ones embedded into browsers, do not fully support the PDF security model. These applications are not extensible and there is simply no way to open a PDF encrypted with a Security Hander. Moreover, each of these viewers presents its own error message when failing to open an encrypted PDF, and almost none of these messages actually explain to the user what has happened and why.

But the fact that the PDF viewers embedded into modern browsers are not capable of decrypting FileOpen PDFs does not mean that FileOpen PDFs cannot be displayed in those browsers. This is because the processing environment of modern browsers has become sophisticated enough that a PDF viewer can be delivered to that browser in real-time, basically like a webpage, and that PDF viewer can be enabled to open encrypted PDF.
The primary enabling mechanism for this new functionality is a technology called Web Assembly, which permits a server to deliver a complete application into a browser.

Applications delivered this way are more secure than ordinary web pages, because the Web Assembly layer permits the application to be encoded, or compiled, into executable code. Desktop applications are typically compiled. And while it is not entirely true that Web Assembly applications are equivalent to desktop applications, for example because Web Assembly applications run in a sandbox so can’t read from or write to the native OS, they are a major upgrade to the functionality and security of browsers.

In this new world it is no longer necessary to install an application on the desktop, or even a browser add-on, in order to view an encrypted PDF. FileOpen BrowserUX offers the capability to deliver the PDF viewer along with the PDF, in real time.

How to get started with FileOpen BrowserUX
Licensees using FileOpen RightsManager and the FileOpen Viewer platform can begin delivering PDF into the browser immediately. FileOpen RightsServer licensees can choose between setting up a private instance of the delivery module or using one hosted by FileOpen. FileOpen Toolkit/SDK licensees also have the choice of delivering files into the browser from their own infrastructure or using a FileOpen hosted platform. In most cases the new capability can be added with little or no modification to the existing PermissionServer.

Why Libraries Are Taking a Page from Publishers and Using DRM to Lend Digital Books

sbingham@fileopen.com (Sanford Bingham) — Thu, 24 Sep 2020 20:30:08 GMT

Like many public-facing institutions, and perhaps more than most, the world’s libraries have been deeply impacted by COVID-19. Most have shut their doors to patrons and only some have developed protocols to safely manage the loan and return of physical books.

Not surprisingly, demand for eBooks has soared during the pandemic, with researchers, students and other patrons stuck at home.

While publishers have made efforts to increase the supply of eBooks to libraries and/or to temporarily loosen the licensing restrictions governing eBook lending (which are controversial, to say the least), libraries have been unable to keep up with demand for eBook lending. This will only get worse with time -- publishers are raising the cost and limiting the number of copies of eBooks licensed to libraries, because they perceive library distribution of eBooks to have a negative impact on their sales and profits. No matter how the pandemic unfolds, it is clear that libraries will need to solve the problem of eBook lending in order to stay relevant and serve their stakeholders. Implementing effective rights management will be key to keeping costs down and preventing legal challenges from publishers.

The Solution: Controlled Digital Lending (+ DRM)

Even before the lockdowns, libraries had been evaluating approaches to distributing digital versions of books created from printed copies in their collections. The most complete formulation of this concept, known as Controlled Digital Lending (CDL), is presented as a legal argument stating that current copyright law permits a library to digitize a book and then to lend the digital copy as if it were the physical book. That is, the library must never loan more copies of the digital book than it has copies of the paper book. The validity of this legal theory has not been tested (it will be discussed in the upcoming trial of Hachette Book Group v. Internet Archive, but the CDL concept itself is not on trial and any judgement arising from the case is likely to be clouded by the fact that the Internet Archive is not a library and was not, in fact, doing CDL). But there is no doubt that if CDL is legal, that legality depends entirely upon the ability of the library to control the digital copies. As a practical matter, CDL is an implementation of DRM.

Specifically, a CDL operation requires at least two types of restriction: the system must control the number of users who may access the content at the same time (concurrent usage limitation) and it must control the duration of every user’s access (expiration). The second control must also be imposed in a strict fashion, i.e. it is not sufficient that the user not be allowed to re-open the document after expiration but rather the document must be forcibly closed at the end of the loan period. A CDL system must be able to ensure that there is only a single copy open at any given time.

In practice a CDL system also needs to ensure that users are properly identified - as patrons of the library, or members of the appropriate academic community, or perhaps students enrolled in a particular course – and where possible this identity should be obtained from the user’s prior login to the library portal, via SAML or another single-sign-on (SSO) system. The usability, and also accessibility, of the system must also be maximized as library staff are not normally tasked with end-user technical support.

In short, the reference design of a basic workable CDL system, e.g. one to handle Course Reserve materials, requires the ability to deliver a fully DRM’d document into any browser, without requiring any installation or configuration, and to exert absolute control over concurrency and expiration. A full CDL system, operating at scale, also requires the ability to perform real-time encryption of documents stored in an unencrypted repository, managing unique user/document identity across the distributed collection.

University Libraries Are Leading the Way

The good news for libraries is that DRM technology has evolved over the past 20 years to address these same scenarios in commercial publishing and corporate document management. Rights management controls that would have necessitated heavy-handed usage limitations and special software installations a decade ago, are now possible with minimal user friction in standard web browser environments. Several large university libraries and technology vendors are currently piloting CDL systems using readily available DRM solutions, including FileOpen’s, to meet the urgent need of enrolled students to access course materials remotely.

CDL represents an opportunity for libraries to fulfill and even expand upon their missions to be essential drivers of equitable and lifelong learning in their communities. CDL enables instant access to materials even when the library building is closed and provides access to disabled patrons or those without the ability to travel to the library, among other benefits. None of us can predict when or even whether lending of physical books will again be possible as it was before, but it is difficult to imagine a future in which digital distribution does not play an increasing role or to imagine a digital distribution system more efficient and empowering for libraries than CDL.

Stay tuned for more announcements regarding FileOpen’s support for CDL and libraries, and contact us for a demonstration of a live CDL system we’re working on with a major university.