Skip to main content
Dashlane Logo

A Conversation About Privacy: Dashlane’s “Five Laws”

Originally published:|Last updated:|Frederic Rivain

A few months back, we had a lot of internal debates about how we think about privacy at Dashlane. We realized that what privacy means is a very tricky question depending on who you talk to.

Two examples of situations that triggered the conversation:

  • In the U.S., business emails and networks—and the data that flows through them—are owned by the business, and IT admins often have full access. This is pretty widely understood by American workers, who must use personal accounts and devices to keep their employers from having a right to scan or monitor their activities. In France and most European countries, however, if you create a mail folder called “Personal,” then by law the IT admin does not have the right to access it. That cultural (and legal) difference changes the way people think about the privacy they're entitled to.
  • To run the Dashlane product and business, we use some third-party solutions. For instance, we use Sentry to track mobile crashes and Braze to communicate with our customers. These and other tools provide important information used to manage and improve our offering, but it means we need to share some level of information with them. For instance, sharing email addresses with Braze so we can send communications to our customers.

To help clarify everything from “philosophical” concepts to discrete decisions about how we build our product, we decided we needed to formalize our approach to privacy to align the company and help make these important decisions with clarity and consistency. We are calling this the "Dashlane Privacy Stance," and it is an attempt to articulate the principles that govern how we approach customer privacy. Of course, no document can provide absolute certainty on such a complicated topic; the Privacy Stance is more a lens to help evaluate situations and guide decisions than a set of absolute mandates.

We built our Privacy Stance a little like the Three Laws of Robotics from Asimov. It is a set of principles, from the highest order to the more specific. Principles must be considered in order, and principle #2 cannot go against principle #1, etc.

Dashlane (as a company) should never be able to access end-user data (what customers store in their vault and what they do with it), nor should a third party, without clear and explicit end-user consent.

We use the principles of a zero-knowledge architecture to support that stance. If you want to know more about the technical implications of a zero-knowledge architecture, take a look at our Security White Paper.

A Starter, Team, or Business admin using our product can never know what a customer stores in their Personal Space, but can access pertinent business-related data from the Work space.

In their use of our product, it is the responsibility of our customer companies (represented by the Admin) to decide the appropriate level of privacy, based on their company culture and regulatory constraints.

To that effect, we use the same principles of zero-knowledge architecture applied to company and employee data, but we offer Admins the choice to access work data or not.

As a reminder, rule #1 still holds true: Dashlane cannot ever know what any customer stores in their vault. 

As with any other software, it is important for Dashlane to learn from usage activity to be able to improve and adapt our product to the needs of our customers. We track customer usage and activity, as long as it does not breach rules #1 and #2.

This is stated in our Privacy Policy, and I would summarize this as: "Dashlane collects information about how customers interact with our software in order to provide, support, and improve the services. But information about how individuals use Dashlane to interact with other services and websites is always anonymized, and cannot be tied to individual customers."

Any feature or behavior that is triggered or personalized based on end-user data happens locally on the end-user device, not on our servers. This allows us to provide personalized, contextual notices to customers without knowing which customers receive particular notices.

We provide hashed emails and/or device IDs to service providers to optimize our advertising efforts (e.g. ensuring that current customers are not shown Dashlane ads on other sites). Our agreements with these providers prevent them from using the information we provide for any other purpose, including augmenting profiles they maintain. 

First, it allows us to have an ongoing conversation on the topic and reminds us to always aim for solutions that provide a valuable user experience while protecting privacy. 

We set up a Data Privacy Committee, with representatives from multiple Dashlane functions (data, product, engineering, marketing, legal, etc.), to review and evaluate internal practices and new features, along the dimension of privacy.

Let me give you two examples of the impact of that Privacy Stance.

  • We will progressively invest in finding alternatives to third-party trackers, such as Sentry or Braze trackers, and moving to first-party solutions on our client applications.
  • Whenever we design a new feature, we assess it against the Privacy Stance. One example is audit logs for Admins. Those logs are only based on the Business Space in the employee vault. They do not touch personal data. We have been reviewing log by log to evaluate if they fit our Privacy Stance and bring the right value to the Admins while ensuring the privacy of end-users.

Privacy is a complicated topic and this should be an evolving conversation. We're committed to revisiting our Privacy Stance periodically to make sure it's still best serving the needs of our customers.

Read best practices and tips about cybersecurity in "A Practical Guide to Cybersecurity"

Sign up to receive news and updates about Dashlane