Since we started with Chiff about four years ago, we’ve always been playing with the thought to make (parts of) the app open source. We are happy to announce that we are taking this step today! In this blog, I’d like to provide you a bit of insight into why we made this decision, what and how will be open sourced and what it means for you as a user.
Trust & transparency
During the last few years, we often got the question: ‘why should I trust you with all my passwords’? We usually answer that we have designed Chiff with security in mind from the start, all communication between the app and the ‘client’ (browser extension or CLI) is end-to-end encrypted and the pairing protocol that we’ve developed to do the key establishment between the two parties has been formally verified for correctness. But how do you, as a user of Chiff, know that the app actually does those things? Unless you are willing to reverse engineer the system, it’s pretty hard to verify. By making our source code public, we allow users to verify that our app actually does the things that we claim it does. A last shackle missing in the chain is having reproducible builds, because although now you can have assurance that the code builds the app, you still can't know for sure that the app from the App Store / Play Store is the app that you build. It's an issue other apps struggle with as well, especially for iOS. For example, Signal has an open issue for this since 2015. Telegram seems to have experimental support for it. Hopefully it's something we can add in the future.
Another question that sometimes pops up is the effect of making software open source on its security. The association that people have with open source and security differs per person. For non-technical people, a first reflex is often to think that open source sounds like security risk, but among security experts the general consensus is that it benefits security. However, it's not a golden bullet, as for example the Heartbleed bug showed. We have added a responsible disclosure policy to our repositories, with instructions how you can report any vulnerabilities confidentially. We'll aim to have these fixed within 7 days.
Although security is important, it is not the only thing we have to care about. We’re also trying to build a business, and making the source code public may also have implications for the ability to monetize our product. After all, anyone can copy it, right? To answer this question, it’s important to distinguish between 'open source' and 'source available'. Open source means: 'make the source code public under a license that allows anyone to use it'. The conditions under which it can be used may differ per license, but that's generally the idea. Source-available means: 'make the source code public, but not under an open source license'.
Building a business around an open source product is hard, because who is going to pay for a product that you can also use for free? The successful counter-examples usually have a business model that offer either paid support, additional paid features (open-core) or a paid SaaS-version next to an open source self-hosted version. But none of these fit particularly well to Chiff: Chiff is pretty easy to use (at least that's what we try to accomplish), so we don't need to provide a lot of support. And since we are bound to the App Store and Play Store for distributing our app, that essentially is the SaaS version.
On the other hand, source-available offers most of the advantages described above: it provides transparency about the product and allows researchers to discover and report potential vulnerabilities easier, but it still allows us to build a business around Chiff.
Before you scream: 'in the title you promised us open source and now we're only getting source-available!??', hold your horses: in the next section we'll give an overview of the different repositories and how they will be licensed.
Repositories & licenses
Although it sounds as simple as clicking ‘Make public’ in Github, there’s a bit more to it. If we want to make the source code public, we’d like do it right. This means properly documenting all the code, remove some private email-addresses from old commits, add a clear README, etc. In the table below, you’ll see an overview of the different repositories, how they are licensed and a timeline for publication.
|iOS||chiff-ios||All rights reserved||✅|
|iOS core||chiff-ios-core||All rights reserved||✅|
|Android||chiff-android||All rights reserved||Q3|
|Android core||chiff-android-core||All rights reserved||Q3|
|Browser||chiff-browser||All rights reserved||Q4|
|Browser core||chiff-browser-core||All rights reserved||Q4|
|PPD editor||ppd-editor||Apache 2.0||Q4|
The main repositories for Chiff will not be publicised under an open source license for reasons mentioned above. The main exception is the CLI, which we will release under the GNU GPLv3 license. Since we expect that the set of people that care about open source software will have a big intersection with the set of people that are interested in the CLI and with the set of people that are willing and capable to contribute to open source software, we think it is worth to release this project under an open source license.
As you can see, the PPD (Password Policy Description) repositories will be released under Apache 2.0 license. Main reason for that is that we would like to allow other password managers to use this concept as well and that we'd like to accept contributions for PPDs. If Chiff does not generate the correct password for a specific website or the login/change password flow does not work well, you can submit a PPD yourself. With the PPD editor we're planning on releasing, it's quite easy to build a PPD in a visual editor and test if it works. It'll even be able to submit a pull request on your behalf to the PPD repository when you're ready and since Chiff reads from this repository directly, merging the PR directly, immediately updates the flow for that particular website.
We're still considering if we're also releasing the back-end repository. The added value for transparency is limited, since all communication between app and client is end-to-end encrypted. In other words, compromising the back-end component would have an impact on availability at most.
We hope this blog provides some insight into our considerations to take this step. Using a password manager is the easiest way to improve your cybersecurity, since it makes two important attack vectors for attackers (weak passwords and phishing) much more difficult. If you're interested, you can download Chiff for free. If you have any questions or remarks, feel free to let us know. And last but not least, if you find any bugs or have feedback on Chiff itself, create an issue @ GitHub :).