proc

A sovereignty tool for site operators and their users against external power structures.

INTRODUCTION

This NIS2 Recital (95) compliant module integrates OpenPGPjs for executing client-side encryption, ensuring that even Drupal administrators or sysadmins cannot access user data. It supports two modes of usage: stand-alone mode
and field mode. In stand-alone mode, the module provides forms for encryption, decryption and re-encryption (decryption immediately followed by encryption, for updating sets of recipients and/or compliance with key rotation) of files and text. In field mode, the module provides a field type for encryption and decryption of files and text from within any fieldable form, and a field formatter that allows seamless asymmetric decryption and rendering on-the-fly.

REQUIREMENTS

OpenPGP.js v5.0.1

INSTALLATION

Install as usual. OpenPGPjs is shipped within the module.

ROADMAP

Multiple signatures per content with recursive encryption.

Recursive encryption of files by folder selection.

LEARN MORE ABOUT PROTECTED CONTENT

Protected Content, Secure open source day - Haarlem (2019)

Protected Content: end-to-end PGP encryption for Drupal, Drupal Camp - Kyiv (2019)

Protected Content by Asymmetrical Client Side Encryption, Drupal Dev Days - Ghent (2022)

A pretty good content protection (Workshop), Drupal Con - Prague (2022)

Securing Drupal Content with Client-Side Encryption: A Zero Trust Approach (Workshop), Drupal Con - Vienna (2025)

SIMILAR PROJECT

Client-Side File Crypto

WARNINGS

1. Protected Content defines a zero knowledge proof protocol, based on the brain of its users. Unless local cache is set, the passphrases defining private keys are not stored in any medium but the brain of their authors. I.e, a lost passphrase that allows for the decryption of a content no one else is a recipient of equals to a content lost for an impractical amount of time. Use it wisely.
2. Proc uses the cache API of modern browsers for avoiding having to download twice the same cipher text. Therefore, if you are not accessing it in localhost, you might have to have https enabled on your server, otherwise the cache API will probably be disabled. If as <user> you come to have ssh access to your remote server and you access the project at http://<ip>:<port>, a convenient workaround is to bind ports with ssh. Example: ssh -L <port>:<ip>:<port> <user>@<ip>. While this ssh session is opened, you will be able to access the project at http://localhost:<port> and as such cache API will be enabled.