Transparency and trust are core values at Dashlane, and we strive to reflect them in everything we do. By being open about our codebase, we aim to strengthen the trust our customers have in our product.
Following on the release of our Mobile and Command Line codebases, we are now making our Web Extension code available. This is an important step we take towards furthering our commitment to our values. Our source code enables you to read our approach to building a password manager, but it’s not a complete solution to build your own Dashlane extension. Think of it as sharing a recipe – we’re providing the process, but leaving out the unique ingredients that make Dashlane proprietary. This allows others to learn from our implementation and pick up an idea of two:
- IT security professionals can review our code and get familiar with how we do things or to meet their compliance needs
- Developers, whether they’re job candidates or just curious, can share thoughts about our code by creating a Github issue - we always love to hear feedback.
- People not familiar with browser extension development, especially in the Manifest V3 context, can get a peek into this unique area of software engineering.
- White-hat hackers can test their skills and leverage the code to find vulnerabilities or security issues. (If you do happen to find something, report it on our HackerOne Bug Bounty program.)
Getting comfortable with sharing
We began our journey toward public source code sharing a few years ago, and while we were all excited about the idea, we wanted to make sure that the code was ready for public scrutiny, especially after the massive effort required to adopt the extension to the MV3 requirements. The process of adopting an open approach pushed us to rethink some of our practices within the Web Platform team and led to even closer collaboration with our Security team. This shift has ultimately prepared us for the exciting announcement we’re making today.
Setting up of a mirorred repo
We have created a new private repository to host the source code that has gone through our internal review process. This repository serves as a secure and controlled environment for maintaining the latest approved versions of our code. Additionally, we leverage GitLab's capability to automatically mirror this internal repository to an external GitHub repository, ensuring that a public-facing version of the code is always up-to-date. This setup enables us to keep the internal code secure while still benefiting from the collaboration and visibility that comes with sharing code.
Setting up a process to review and redact source code
Our primary goal was to ensure that no secrets, test-related code, or internal references leak into the public repository. In collaboration with our Security team, we discussed the tooling and processes required to ship new versions while consistently meeting this goal. By implementing automated checks and redaction procedures, we can ensure that only the appropriate code is shared, maintaining the security and integrity of both our public and private repositories.
We developed an internal tool library within our monorepo to automate the redaction process. This tool includes a public NPM command that prompts the developer to enter a Git tag (e.g., v6.2447.0), checks out the corresponding code source, applies the necessary redaction procedures, and then opens a merge request (MR) against the private repository. This automated process helps us maintain the integrity of our public code while keeping sensitive or internal information secure. It first reads from sources.config.js configuration files located in the monorepo to know which files to keep or to drop during the process. Those files contain include and exclude glob declarations:
It then uses the TypeScript Compiler API to parse all the remaining TypeScript files. For each file the given AST is analyzed, nodes detected as containing droppable information are removed and the AST is then printed back to the file.
There are two different ways to mark AST nodes as "to be redacted": either their content matches a list of tokens and regular expressions hard-coded in the tool; or they are enclosed by a pair of magic comments:
Using those magic comments has the advantage of being resilient to file renaming and refactorings.
What's next
With all of our client code now public, we’re excited to usher in a new era of transparency, collaboration, and innovation. Just like other platforms, we’ll provide regular updates to ensure our public codebase stays aligned with the version in active use by millions of Dashlane users across the world.
Internally, sharing our code encourages our engineering team to raise the bar on code quality – making it cleaner, more readable, and something we can truly be proud of. While all code inevitably carries some level of technical debt or legacy issues, we’re committed to sharing only the best version of ourselves.
In the future, we may explore making our backend codebase available. However, given our zero-knowledge architecture and security principles, most of the critical cryptography work occurs on the client side. For this reason, we chose to start by sharing our client applications, as they hold the key to understanding how our security features are implemented.
Sign up to receive news and updates about Dashlane
