What does Engineering Look Like at Dashlane?

We've written this article to give some insight into what it's like to work at Dashlane, with special emphasis on how our Engineering team operates. Before we dig in, it's important to first know that Dashlane was created to find an elegant solution to the complicated problem of password management. Today, Dashlane makes it easy for millions of businesses and individuals to protect their data and stay safe online.

Dashlane has a strong engineering department with over 100 employees, representing a full 30% of Dashlane's workforce. We are distributed across 3 countries: France, Portugal and the US, with more and more team members joining from locations far from our offices. Because of our increasingly hybrid and remote work model, we operate with a "remote-first" mindset in all our communications.

Engineering contributors are distributed across Core Product teams, Platform Squads, Quality Engineering and Productivity Engineering. When we see the need, we also spin up what we call "Mission teams" to deliver specific projects for our business. Core Product teams are entirely dedicated to iterating on our product for our customers, Platform Squad teams are tasked with keeping our iOS, Android, Server and Web platforms healthy, and Quality and Productivity Engineering teams span across to keep us operating with quality and at scale.
As a more tangible example, the re-write of our iOS App was produced by our Apple Platform Squad. Some of our "Core teams" include our Autofill, Authentication and Admin Onboarding areas. As we grow and scale, Dashlane continues to iterate on the way we're organized. You can check out our CTO´s latest post on this evolution here. 

All our platforms try to keep up-to-date with what is happening in their respective technical communities.

For mobile platforms, it means working with the latest languages and frameworks provided by the Apple and Android ecosystems: for example, Swift (& SwiftUI) for Apple, and Kotlin for Android.

On the server-side, all code is written in TypeScript, using Node.js and running on AWS, trying to leverage AWS's benefits and the services where it makes sense (e.g., using serverless when possible, managed DBs, etc.). Server engineers are responsible for the provisioning infrastructure (using Terraform), developing and maintaining our APIs and associated back-end services. They also have full ownership on the operation of those services, including an on-call rotation to monitor the system and fix production incidents if needed during off-hours.

To develop on our website and extension, the stack uses well-established technologies like React and TypeScript. However, Dashlane is unique in that we build and ship a browser extension as a fully-fledged application.

This is quite an unusual ecosystem for Web developers and means that the experience of developing in our environment is different from developing more conventional front-end applications. In particular, releasing the Web extension in production means going through a workflow that is pretty similar to how mobile apps are shipped to end-users (a bit more on that flow later). Moreover, building this product means designing an application while accounting for the constraints of extension architecture, communication between the different components, etc. Dashlane is currently in the process of re-architecting our extension in preparation for Manifest v3, an upcoming requirement for extensions operating on browsers like Chrome and Edge.

You can read more about Dashlane's technology stack on our blog. 

Releasing server-side code

Server engineers operate on a continuous deployment model. We have one main repository for all our API endpoints, where new code is merged and shipped daily. We also maintain other repositories for background tasks, serverless code, etc. Deployments are automatic: when the build is successful on the main branch, code will be released without manual intervention. 

Planning and releasing mobile apps & the Web extension

Our extensions and mobile apps are released as part of weekly or bi-weekly release cycles. Our process focuses on thorough testing and a progressive rollout to production.

To provide visibility for major upcoming feature releases, teams at Dashlane maintain a shared Release Calendar.

Let's say a team is building a new feature which is code complete, and all the needed elements have been merged into our Main branch. As soon as this is done, team members can start on a secondary layer of functional testing, or "dogfooding," to test the feature to ensure there are no conflicts with the existing behavior within our app/extension, or to check on the experience for different user types, such as individual versus business user scenarios. This "dogfooding" period using our "internal" version of the app/extension allows product and engineering teams to get crowdsourced feedback from Marketing, Sales, Support and other stakeholders who are looking out for various elements of the user experience.

Meanwhile, the production version of our app/extension is also regularly created by our platform teams, when builds are assembled into "release candidates" on a weekly or bi-weekly basis, then end-to-end tested and submitted to the stores for review (Google Play Store, Apple App Store, Edge, Chrome, Firefox).

Then we use a staged rollout: once approved, the platform team progressively releases the app/extension over several days, always monitoring to quickly detect any problems and resolve them before they can cause undue disruption to our users.

Our CI workflow carefully orchestrates all of this. We use a release train to coordinate all the releases from the different teams. Concretely it means that all the code merged before the "departure" will go into the next release; otherwise, it will be in the following one. This allows frequent releases (weekly or bi-weekly) with a simplified process.

Publishing on stores

Our mobile apps are available on the App Store and Google Play Store. The extension needs to be built and packaged for different browsers: Chrome, Firefox, and Edge.

As an example, this is the workflow needed to Publish in the Chrome Web Store.

Our platform and automation teams collaborate closely to automate as much of the release process as possible. These activities range from automating browser actions using a headless browser when no API is available, to managing the release submission in Gitlab and rollout notifications in Slack.

Once your app is submitted, you have to wait until it gets approved, which usually happens within a couple of days. However, there can be instances where your app will not pass the review because some rules have changed and you need to make your app compatible with them. Examples we've faced in the past are obfuscation rules, permissions scope, etc.

It is common to hear that engineering teams should only build what is core to the offered product or service. A modern resolution to the "buy vs. build" dilemma is integrating third-party solutions for everything that is not core to the business, such as  payments, marketing and monitoring.

At Dashlane, we have a bit more nuanced approach to this subject. Of course, we don't always want to be reinventing the wheel. For example, we use established third-party solutions to answer specific needs when handling payments and running marketing campaigns. However, there are some capabilities that we believe we build best because of our talent and strategic competitiveness.

Sometimes, it means reimplementing some logic ourselves rather than using a package, given that external dependencies are a well-known source of vulnerabilities. It also means being extra-careful when it comes to administrating our core infrastructure. For example, we generally favor self-hosted solutions for our CI/CD, logging, and monitoring infrastructure.

There is no clear-cut rule, but we put a lot of thought and discussion within our teams to make sure that we keep our attack surface as small as possible. We also act per our Dashlane Privacy Stance, which gives us a set of principles to guide our choices when deciding how to build a new service.

When working for a Password Manager, security is fundamental. People using our software trust us to keep their data safe. Any flaw in our product could destroy this trust, which, once lost, is challenging to regain. This is why we must build our system to be secure by design, so even Dashlane employees cannot break it, from our core features all the way to production releases.

Rather than preventing access to sensitive information to only a few employees, as many companies would do, we make it impossible for us to have any access to it. Our servers should never see the data our users enter within Dashlane, even temporarily. We call this Zero-Knowledge, which is possible thanks to the Master Password known only by the user. This Master Password will encrypt data locally before it is sent to the server. Our server never sees the Master Password, neither a hash nor any derivation of it. When we ask the user to enter the Master Password, its validity is verified on the device itself by trying to decrypt a piece of information encrypted with it. Because we have no access to it, it also means we cannot provide a "forget my password" option that would send you a one-time password (OTP).

While it might seem straightforward conceptually, Zero-Knowledge does in fact present unique challenges in the software development process. For example, in most companies, the server validates the data synchronized between devices. At Dashlane, this is not possible for us because the server cannot read the data. When building a software client, you can usually be confident about the data format you receive. In our case, because the data is encrypted, there is no such validation. So all our clients must be ready to accept any non-conforming data and even handle bugs created by one specific client that was fixed years ago. The same applies to migrating the data from one format to another: the server cannot help; everything has to be done client-side. When developing a new feature, we must also constantly consider this security by design.

For added transparency, we provide a White Paper on our website which outlines the security considerations taken when designing our actual features.

As we rely heavily on cryptography to encrypt users' data, you might assume we expect engineering candidates to have a security background. But actually, we do not require our software engineers to have extensive security knowledge prior to joining. That said, engineers have many opportunities to improve and expand their knowledge of security best practices while at Dashlane.

Our product's cryptography is isolated within our code base and, while we ensure it stays in proper working order, most engineers won't work on this part of the code on a regular basis. Still, in some cases, we have more complex scenarios that require security knowledge. This is where software engineers will go deeper into cryptography concepts and will have a chance to learn a lot, working in collaboration with our security team.

We use standard cryptography algorithms such as asymmetric RSA and symmetric AES. We are constantly improving it by investigating more advanced techniques, such as Argon2 or elliptic curve cryptography, and thinking about the future, such as being protected against quantum attacks.

Dashlane is installed and running on a host platform, whether on Android, iOS, or a browser extension system. As such, we need to rely on that system's cryptography and work around its limitations.

Most of our clients that let you access Dashlane data are bundled within a binary. Concretely, this means that all the code that runs has been signed and cannot be altered by a third party, which provides excellent security.
Even our extension that we ask our users to install on their computer has been packaged, signed, and validated by the browser store validation process. You can read more about the particulars in our Deep Dive into Web Extension Security.

To expand on the work of our internal security teams, Dashlane also enlists the help of white hat hackers to identify possible vulnerabilities. Thanks to this program, ethical security hackers get rewarded for finding areas of improvement, and Dashlane users benefit from an application that provides consistent security improvements.

Dashlane is proud to build software that helps people stay safe online, and presents our engineers with unique and interesting development challenges. You can be part of this journey! Dashlane is always looking for engineering talent to join our growing international team. You can see our latest job listings on our website at https://www.dashlane.com/about/careers

We also know there are many security fans out there that like to stress test how sturdy products like ours are. Ready to dive in? Challenge us and sign up to our bug bounty program to highlight what we could be addressing next.

This article was co-written by Emmanuelle Franquelin and Stan Kocken.

Emmanuelle Franquelin

Read more