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.
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.
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.
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:
- integrate our existing encrypted messenger better with the rest of CryptPad’s functionality (as per this issue)
- 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
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.
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.
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.
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 CryptPad.fr 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.