One year of biweekly releases

Approximately one year ago, we published an article about our intention to follow a biweekly release schedule. Since then, we’ve thought of every second Tuesday as release day. Starting with the letter A on February 21st, 2017 and ending with the letter Z on January 30th, 2018, we went through the whole latin alphabet.

Throughout this self-imposed regimen, we managed to meet each deadline, though on occasion we had to stay at the office later than usual. Any time a release was more difficult than expected, we considered what went wrong and added a counter-measure to our release checklist (in CryptPad, naturally). Each release became easier than the one before, but even so, we found there were some drawbacks to this rigid schedule.

Changing our pace

Having a regular rhythm for our releases trained us to break up complex features into components that could be implemented within a two week period. With that in mind, not all tasks fit neatly within two weeks, and those larger tasks have had a tendency to get pushed to the next release. So, now that we’ve finished one full year of releases, we’ve started to look more closely at those larger features which we’ve inadvertently neglected. The tendency to procrastinate on especially difficult features is just another challenge to approach, but it’s been one which is somewhat more difficult to summarize within a to do list.

As of CryptPad v1.26.0, we’re no longer following the strict biweekly schedule. To be clear, this doesn’t mean we’re slowing down development. We’re still working on CryptPad consistently. We still plan to deliver features to users as soon as they are stable. We still plan to deploy on Tuesdays, since it’s as early in the week as possible without falling on a Monday and deploying on a Friday is a terrible idea.

Should I release on a Friday?

Some releases might happen in a single week. Others might take stretch to three weeks or a full month, but we’ll do our best not to take any longer than that. We try to be as transparent as possible with our plans, and so users should expect each release to also specify the projected date for the following release.

What’s coming next…

In the last year, we tried to find a balance between improving user security through the use of our sandboxing techniques, and implementing the productivity features necessary for people to consider the security improvements an added bonus rather than an impractical ideology. The core of our philosophy is that security and ease of use must be packaged together in order for tools like CryptPad to benefit users.

While CryptPad is considerably more than a proof-of-concept, we don’t consider it anywhere close to being finished. As heavy users of CryptPad ourselves, we are aware of its rough edges. Our community has been very supportive with our continued development, though, so we’re excited to be able to improve the following areas!


We spend a lot of time passing links between each other when collaborating on a project. In order to do so privately, the sender and the receiver must both use an encrypted messenger, or else the message could be intercepted by a malicious third-party. The necessity of having to use a second tool makes it so that CryptPad must always be used as part of the solution, rather than solving a user’s problem outright.

We’d like to approach this problem with two improvements:

  1. integrate our existing encrypted messenger better with the rest of CryptPad’s functionality (as per this issue)
  2. develop a method of sharing entire folder structures from a users drive, so that sharing can scale to support large-scale projects, a feature we call Workgroups

Layered protection

Even if the link for a pad is shared securely, there is the possibility that somebody discovers that link through other (possibly malicious) means. We’re interested in developing CryptPad’s basic two-tier permission system (edit/view) to address such concerns. This could be accomplished in very different ways:

  • add the ability to protect a pad with a password, so that anyone who finds the link must also know a secret value in order to retrieve the pad’s history from the server
  • add the ability to encrypt messages such that only a designated set of users can decrypt them using public-key cryptography

So far CryptPad only features a very limited set of cryptographic techniques. Going forward, we hope to find ways to implement a more granular permission system which does not rely on the server behaving correctly. Some of these features are more in the realm of applied-cryptography research than web application development, so it’s very likely they’ll be implemented later, but we’re excited about them nevertheless.

Increased trustworthiness

Even though CryptPad performs its encryption in your browser, there is always the possibility that a compromised server could send malicious code to the browser which would cause it to reveal its secrets. We’re interested in developing features which would mitigate these kinds of attacks against users, through a combination of modern browser features like sub-resource integrity, and perhaps a registry of verified code signatures signed by us, the developers.

It’s very difficult to make a web application secure against those responsible for delivering its source to your browser. We’re actively searching for any kind of technique for securing that makes CryptPad a more robust platform for storing your data privately, even against ourselves.

Password usability

CryptPad’s login system looks quite conventional at first glance, since it has a field for a user-name and password like most other web applications. Unlike those other applications, we never learn your user-name and password. Instead, your browser uses those fields to generate a unique secret value which you use to encrypt your drive, and accomplish a range of other tasks. The downside of this approach is that if a user forgets their username or password, we can’t help them gain access to their documents. If we could, we’d be able to access their documents ourselves.

Fortunately, we’re not the only team building web applications that use cryptography, and so there has been some research into how to improve password-based workflows without revealing secrets data to the server’s host (us). We’ve already received emails from users who’ve inadvertently locked themselves out of their accounts with no way to recover their data, and that’s a situation we’d like to help people avoid, so this is a feature we’re looking forward to offering.

More applications

Lots of users have requested that we add a few more applications to CryptPad, and we’ve been listening! We plan to add support for spreadsheets, and possibly other applications so that people don’t have to fall back to using an unencrypted CryptPad alternative.


One advantage CryptPad has over other conventional collaboration platforms is that a lot of the difficult computation is run in the users’ browsers, rather than on our server. This means that we can support a very large number of clients without a noticeable decrease in performance. Even so, the number of people using and the amount they use it has increased dramatically.

Though excessive popularity is a wonderful problem to have, we’d like to avoid a situation where users have difficulty accessing our service, so improved scalability is something we’d like to work on.


We haven’t yet decided how long we intend for this release cycle to last, and we don’t have a set list of the exact goals we’d like to accomplish. We’re taking a step back to decide where we’d like to go next.

We recognize that CryptPad’s growth over the last year was driven largely by word of mouth between friends and colleagues who care about privacy. By moving towards a more flexible schedule, we hope to make it easier to adapt to the frequent feedback we receive from people using CryptPad to help them accomplish a multitude of goals.

We’re very interested in hearing what you think about this change. Feel free to reach out to us through any of the methods listed on our contact page.

CryptPad's new Secure Cross-Domain Iframe

CryptPad version 1.14 (Codename Ouroboros) has been released and the most exciting new feature is one you cannot even see. As you may remember from the Security Growing Pains post, Content Security Policy is a significant part of CryptPad’s security model, and it is unfortunately incompatible with CKEditor, the Open Source text editor used in CryptPad.

With this release, we have done a significant re-architecture of the CryptPad codebase. Starting with the /pad/ application, the CryptPad UI has begun a process of moving into an iframe which is hosted on a different domain: Moving the visual content to a different domain means that even in the event of a Cross-site scripting security vulnerability, most of your private information such as the pads in your CryptDrive, will not be at risk.

In this version we updated only the /pad/ application to use the cross-domain iframe because it is the only app which requires inline script. This prevented us from using Content Security Policy to block the most significant vector for Cross Site Scripting attacks but now with the cross-domain iframe, such attacks are mitigated.

Going forward, we plan to implement a standardized CryptPad application API so that new applications can be developed, installed and used in CryptPad. Today, the CryptPad API which is exposed to apps such as /pad/ and /code/ is not standardized and there is no clear line between the apps themselves and the CryptPad internals. As we move toward the a standard app API, we will define a standard representation of a CryptPad application with such additional aspects as the app’s color-scheme and icons.

Fundimentally, this unexciting change to CryptPad begins a new phase in development, we plan to move from a set of integrated prepackaged applications to an ecosystem of applications for collaborating on different types of content with the same encryption under the hood.

But Wait, There’s more

The pictures in this blog post are not hosted on the blog, they are in fact Zero Knowledge files uploaded on CryptPad. They can be seen on this blog because it is using the Media Tag which was developed as part of the UCF Project with the support of Systematic, BPIFrance and the City of Paris.

Media Tag allows files on CryptPad to be included in any website (such as this blog). All you have to do to include a file from CryptPad is simply include the Media Tag loader and then add a Media Tag to your document, just like the following:

<!-- At the top of your HTML file -->
<script src=""></script>

<!-- Where you'd like the image to be located -->
<media-tag src="" data-crypto-key="cryptpad:VE4raHL5VFReAXxioTaFZwt6q2jpxX+bdFHAFeoivZQ="></media-tag>

With this you can embed files from your CryptDrive into any website you want.

CryptPad's New Direction

If you are hosting CryptPad, please make sure you are up to date. CryptPad 1.13.0 (Naiad) fixed a major security issue.

CryptPad was born on Halloween 2014, at that time it was a skunkworks project inside of XWiki SAS. The UI was hidious green and white and the only feature was the CKEditor based pad. We have come a long way.

Old CryptPad Main Page

As was mentioned in Building Mututally Beneficial Relationships, CryptPad cannot ever be great without people developing the software as their daily job. We have been able to develop this project with the generous support of BPI France and the OpenPaaS::NG but that support only finances a small team and it will not continue indefinitely.

Starting with this release, we are adopting a new look and a reinforced dedication to making a quality product for people whose time is valuable. We’re starting this by upgrading the logo and the informational pages.

New CryptPad Main Page

Our lovable fist logo was created one night by grabbing a screen shot of an ascii generator. It was a time when I was racing to get something working to prove that CryptPad was an idea worth pursuing. Now times have changed. CryptPad is finally something that I’m starting to feel proud of, and the logo represented the last reminents of a time when everything was a rush and quality was an afterthought.

We also have introduced a lot of new features such as:

  • New front page which allows creating a pad in 1 click
  • Clickable links in pads when viewed in read-only mode
  • File-picker for embedding media in a pad in Markdown mode
  • You can now have your preference between tabs and spaces, when editing in the code editor

Registered users can uploading and view PDF Files

But more than features, we have focused on making CryptPad easier to use. It’s now easier to paste text into the pad without breaking the formatting and we have additional tool-tips to help explain different features of CryptPad.

Going forward from today we plan to make CryptPad easier to use, more secure and more extensible. We are rewriting the pad logic in order to run in a cross-domain iframe which will make use of the browser’s Same Origin Policy as a sandbox to block most of the code from accessing the decryption keys.

This will open the door to 3rd party applications developed for CryptPad which can be protected by the same cryptography as CryptPad and which have limited access to the CryptPad system.

CryptPad Analytics & Privacy - What we can't know, what we must know, what we want to know

CryptPad is a Zero Knowledge cloud application, this means we have designed it such that we do not have any access to the content which is hosted on our server. However, there are other things which we do collect and it is important that privacy-minded users understand what we are collecting and why. There are four types of information:

  • What we can’t know: This is data that CryptPad app encrypts so we will never have access to it
  • What we must see but don’t collect: This is information which we don’t bother to store but because of how the technology works, we necessarily have access to it.
  • What we must know: This is metadata which we cannot help but see because of the way the technology works
  • What we want to know: This is information which we really want to know in order to make CryptPad better every day

We want to know everything about people, we want to know how people use CryptPad, why people use CryptPad and how we can make their experience easier. However, we don’t want to know anything at all about you.

This poses a challenge because we want to collect as much aggregate information as we can in order to make a great web service, but we don’t want to collect data that can be linked in order to tell a story about you.

What we can’t know

There are a few things which the Zero Knowledge design of CryptPad does not allow us to know at all. These include (obviously) your password and the content of your pads, but less obviously, the titles of your pads, the names of the contributors and your username (you can even have the same username as someone else on the system, we won’t know). The types of your pads are also unknown to us though we could make educated guesses by looking at the encrypted data.

It is our promise to you that we will never collect this information.

What we could know but don’t bother to collect

There are also some things which we don’t really want to know but we cannot avoid seeing it anyway. This includes most importantly the IP addresses of people who edited a specific pad. Technically we know your IP address because it’s how you communicate with our server, but most of the actual operations are done using commands sent down a WebSocket. Once the WebSocket is established, we assign you a random ID and this is how you are referenced, what appears in our server logs looks like this:

3 - - [06/Jul/2017:20:47:45 +0200] "GET /pad/ HTTP/1.1"
304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/59.0.3071.109 Safari/537.36" "-"

Notice there is no pad ID in there, the pad ID is not in the URL so it doesn’t go in the server logs by default.

Compare this with EtherPad:

  IP Address                                             Pad ID - - [06/Jul/2017:11:54:37 -0700] "GET /p/UNWnpczTkq HTTP/1.1"
200 8920 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X
10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109

You cannot verify that we’re not collecting this so best assume that we are.

What we must know

There are some things which we need to know in order for CryptPad to function properly, we need to know which pads are in your drive in order to impose storage limits on logged-in users and to expire pads which nobody cares about. However, we don’t know much about who you are. Since we don’t know your username, to us you are identified by a public signing key, something like this:


We know that YIBzjPr3beuGgfHNglGfo3xq-dquxsj4Bst-ze7mL9A has 392 MB of data in their CryptDrive including a pad of some type which has the ID fe382219b10c0396de63d2bab7942390 and an uploaded which we know as ff2fdf9bb99ecc89d29d780780de10efdac14ed15e93b235. One of these pads that they have is actually their drive itself, but we don’t strictly know which one (again, we can take guesses based on the size of the patches). You can find out what your signing key is by looking at in your settings page.

We also know when each pad was last accessed so that we can know to delete pads which are not in anybody’s CryptDrive and have not been opened in a long time.

Why we can’t avoid collecting IP addresses

Being able to know how many different people are using CryptPad is very important to us. One rather rude person decided to try to crash our server by creating 647,533 pads. They didn’t put much thought into their attack because what they were doing was not actually creating pads, but it illustrates the problem that if we don’t know how many different people are using the server, we don’t have any idea whether we are popular or under attack. Worse, we don’t know what features have widespread support vs. which ones are only popular with a few prolific users.

One obvious thought is to simply run the IP addresses through a hash function the way we traditionally hash passwords. However this sadly cannot work because there are only 4.2 billion IPv4 addresses and constructing a rainbow table to get back the original IP addresses would take only about 1 day of computer time. So in the end we simply log the IP addresses and don’t worry about it.

What a pad looks like to us

A pad is stored as a file which represents a sequence of encrypted patches. These patches change the content of the pad from nothing to whatever it becomes in the end. A typical message looks something like this:


It starts with a zero and then your temporary random ID, then it contains the word MSG and the ID of the pad which it is sent to, this format is exactly the same as what is sent on the wire. Finally it contains the encrypted patch which tells us essentially nothing except it gives us a rough idea of just how big the change was.

Occasionally the client will send a checkpoint, this is a special patch which removes all of the content and then puts it all back again. To us, a checkpoint looks the same as anything else, it is a big ball of encrypted data, except in this case it is flagged as a checkpoint so the server knows it can send only part of the history of the pad instead of all of it. However, they do give us a good idea of how big the pad actually is at that time.

What we collect because we want to know

What we really want to understand is your experience with CryptPad and how we can make that experience better. So therefore we collect quite a number of data-points about where people click and what their browser supports. For example we collect the dimensions of your browser. Not because we want to know who you are but because we want to know that types of browsers we need to support.

4 - - [06/Jul/2017:21:26:15 +0200]
"HEAD /common/feedback.html?DIMENSIONS:752x1440=1499369175085 HTTP/1.1" 200 0
"" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Safari/537.36" "-"

You can see an exhaustive list of things that we collect by checking out the feedback functionality in the CryptPad source code but as of the time of this writing, we are collecting feedback about the following things (usually we just collect the fact that an event occurred, not more).

  • Clicking “upgrade account”
  • Clicking “support cryptpad”
  • Presentation: clicking on “print slides”
  • Registering and logging in
  • Opening your recent pads as an anonymous user
  • Clicking any CKEditor button such as “bold” or “italic”
  • Displaying the drive as icons or as a list
  • Creating and using templates
  • Showing and hiding the userlist or CKEditor menu bar
  • Whether your browser is missing certain important features like Proxy, isArray or localStorage
  • Which type of pad you are using
  • The dimensions of your browser window
  • When you have changed your display name
  • Whether you have migrated your CryptDrive from the legacy format

If you are worried about what we might do with this data, you can disable feedback collection in your settings page. But keep in mind that if you disable it we cannot help but know, because your IP address will be in the tiny minority of addresses which access the site but don’t send feedback messages.

What we can learn from the data

1. People mostly use CryptPad to make a plain old pad

But the code/markdown pad and the CryptDrive are catching up. Unique IPs per pad type

2. Activity has been on a very slow rise but with a few spikes

This chart shows unique IPs per day hitting CryptPad. You can things are relatively flat over time except for a big day in June and then some increased activity in July after the UI improvements were rolled out. Unique IPs per day

3. Browser window dimensions are all over the map

This chart shows bubbles which are bigger depending on how many different IPs report the same browser window dimensions. Tragically it seems that there is no way to predict what aspect ratio a device using CryptPad is going to have. Browser window dimensions

4. Lots of pads are made and then abandoned

The first chart shows in blue the number of pads created each day and the number of pads which become “abandoned” (have not been touched in 2 weeks). This says that perhaps pads are considered ephimeral and not to be used for the long term. Created vs. abandoned pads

Here we can see the evolution of pads which have been accessed within the last day the last week and the last month. There is slow but steady growth in the pads active in the past month. Number of active pads

5. People use CryptPad for a while, then leave

We measured 15,000 IP addresses which came to CryptPad just to look at one pad and then left, but of the 13,000 who stayed longer than that we analyzed the time when they first arrived and the time when they made their last visit. About 630 IP addressses have been continually using CryptPad for all 45 days. Number of IPs continuing to access CryptPad We want to make CryptPad a useful tool for helping people get organized and make their projects succeed. So whenever people decide that CryptPad is not the right answer for them, we care about what went wrong and how we can make it better.

How we analyze this data

We do all of our analysis ourselves, and we don’t share any of this data with Google or other data companies. We’re thankful to Kibana/ElasticSearch and LogStash for making it possible to do in depth analysis on our own computers without resorting to a cloud service.

CryptPad Jackalope - File Upload, PDF and Pictures

Yesterday we released CryptPad v1.9.0 Jackalope, we have some exciting new features which we’ve been working on for a long time. As part of the UCF project we have implemented a Zero Knowledge media-tag in CryptPad for displaying and downloading encrypted files stored in CryptPad. Starting now, you can upload files by clicking the upload button or dragging them into your CryptDrive. You can also view pictures and PDF files in CryptPad and you can drag-and-drop pictures directly into presentations. In the next release we will hopefully be adding drag-and-drop pictures into the pad.

CryptDrive Upload


We also made a significant but less visible improvement to the CryptDrive. When you make a new pad in CryptPad, it has a title, which anyone in the pad can change, and it has a filename which it how the pad is shown in your CryptDrive. Because anyone at any time can change the title of a pad, the only way to know the titles of all the pads in your drive is to load each and every one of them which would take a long time. But the filename is your unique way to refer to a pad, it lives only in your CryptDrive and it is the same no matter what title someone gives to the pad.

Now the CryptDrive UI shows only one name for a pad, this name is just the title of the pad at the last time you’d accessed it unless you assign it your own filename.

Slide Preview

When you’re using the CryptPad slide app to make a quick presentation, now you can see your presentation in the righthand pane while you type. Since presentations are written in Markdown, this means you get a live action preview of what your presentation slides are going to look like.

Slide Preview and Drag & Drop

Try it now

Head over to and give CryptPad a try !