Trust at Scale: Lessons Learned from a Decade of Engineering

Like, hey everyone. Can you hear me? Okay, good. Well, thank you for being the brave one that uh take their lunch slot to listen to me. My name is Freda. Sorry, how do I next? Yes. All right. I'm the CT at Dashlane. Um I've been there for almost 10 years. I'm going to celebrate 10 years on November 2nd. So, it's been quite a journey that I'm going to share with you. For before that, I worked in different industries. I've been in online gambling, in the video game industry, I've been in e-commerce. Um, and one thing sort of across my career has been that I think it's really important for you to trust your product. Whatever the product you're in, whether

it's a game, whether it's e-commerce and so on, trust is really at the heart of everything we do. And that's even more true for a product like Dashlin, which is a secret product. And uh that's been really what's been the focus for my uh all my career to think I can scale trust and that's kind of what I want to share today with with all of you. I don't who knows about Dashlane. Oh yay a few hands. Thank you. Happy to do that. But before we dive in the story a bit about ourselves. We came out as a consumer product a consumer passion manager evolved into enterprise. We still have both B2C and B2B two sides

of the business. We provide passion management. So we restore your your passwords, your pass keys, your secrets, your sensitive information. And on the enterprise side, we have about 25,000 customers that trust us to also provide them with a a broader credential security platform. We do a credential risk detection, we do fishing detection and all type of things related to identity in a in a sense. And kind of the the unique thing about us, I think, is that we try to really be as simple and as convenient as possible. That's kind of our root from the being a consumer product originally. and we try to marry that with the highest security possible. So trying to find the right

balance between uh user simplicity and security has been a sort of our our trait and I think that's something that really matters for adoption and also really matters for for trust. I don't know if some of you work on product where trust is kind of the the currency kind of the adoption factor but you at least all know theoretically that trust is hard to gain and even faster to lose. So that's why it's so important to to think about how you can scale trust with your customers and with your with your product because that's what's going to drive your business and the success of your business. So kind of looking back in the rearview mirror for for the dash story I think

that I want to look at trust across three dimensions. Of course technology is a big piece of it. We're a security product. We're a technical product. So it matters a lot. But that's not the only dimension. like culture, your company culture, your leadership culture matters a lot in the way you do trade-off, the way you you address your your security product. And at the end of the day, the choices you make as an organization, like how do you make sure you do right by your customers always to maintain that that trust. All right, let's get started with the early days of Dash. So that's going to be a lot about storytelling and things that some of the the wins, some of the

bets, some of the mistakes we've done and I hope you can get some of those lessons and take them back into your own context afterwards. So the first holidays like 2010 to 2014 actually I was not at dash at that time but it's quite important to share those lessons because that's the one I inherited when I joined as a CTO in 2015 and they've kind of shaped some form of the DNA of the organization. So they're kind of important. There are times where it was the early days the organization was trying to find product market fit. They were trying to prove that a a small French startup and you can feel that I'm French even though we we live today in

Brooklyn with my my wife and my three daughters but that French startup started very small and how do you make others believe that a French small security product can be trusted at scale and so there are different lessons the first one is actually the founding team kept dash in a long public beta for a very long time it was a free product and it didn't really work out like the growth was very limited and they had to move to a premium model, start having a paid model to to have credibility and start having a way for people to trust them. The fact that yet again a French mall startup free product, can we trust them? Are they going to survive to the

next level? Is it worth investing to that product? That was not enough and so they made it a premium product and the core was still free but then you had to pay for the advanced features. That's where really the the credibility came from. And then the second big uh moment was sort of that 2013 New York Times article from David Pog talking about that product. And so that really of course increased the visibility and made the product more credible in the in the market. And those are two two events getting to getting external validation was what helped us get to the next step and kind of get to the product market feed. So early lessons if you want to be

trusted sometimes you need to be paid to make sure that you can we can trust you. Otherwise you're sort of you know the the slogan you're sort of the product if the product is free. One early lesson as well was around platform constraints. So in the early days of dash in 2010s they had no choice and choose to build native applications. So we had an application on windows one on Mac OS iOS and Android. That's because at the time the browsers were not really mature. I think it was still internet explorer era. And for a product like ours where you need a uh to autofill you need encryption you are deeply embedded into the platform you

need synchronization those browsers were not mature enough despite the fact that actually most of your authentication life happens in the browser so they chose to go with the native apps they spent a lot of time investing that in that it worked for a while until they didn't and so one of the big sort of nightmare of the early days of Dashland was what we call the iOS data loss disaster so that was in 2014 around the upgrade of iOS At the time iOS when you uh when you uh you didn't have enough space on your phone to do the OS upgrade would remove all your apps, install the OS OS and then reinstall the apps. And of course

we were a local application with encryption happening locally in the device. So the the the vaults of our customers at that time were quite clean. No no data anymore. No way to recover. As you can imagine that was a big nightmare for us as a security product and that's breaking the trust very significantly. So how do you recover from that? Well, you you apologize a lot. You give a ten for life for free to those customers that lost everything and you hope that you rebuild the trust. But one other lesson from that moment was also the fact that the update mechanism of your product, especially if you're a native app, is really critical. Like it's part of your threat model, it's

part of your security boundaries. If an update can sort of lock your customers out, can break the data, that shouldn't happen. So you need to build your update mechanism in a way that is as reliable as authentication or it's a that type of event is as massive as an external bridge in a sense from a trust perspective. So think about your update update model if you have those type of applications. Another a bet we made early on at Dashland was to actually acquire a small startup called Pasmatic in 2014 and they the we used that technology to build feature called password changer. It was a very cool tool. It allowed you in a single click to change the password

automatically on multiple websites. And it was really a great W effect. We use it a lot in marketing. It differentiated us from competitors. It was really the, you know, like the the shiny feature that you want to have when you're trying to to build awareness and visibility for your product. The other side of the story is that it never really worked perfectly. Unfortunately, it was really too hard to scale it to the level that we wanted. It was really too complicated to make sure that it worked perfectly reliably all the time. That's because of course websites change all the time. The technology in the web environment changes all the time. There are captures. Uh so it's really really hard

to scale reliably. Eventually after many years of sort of riding that marketing narrative with that feature, we decided to uh to sunset it. It was a bit painful because that was our our cool marketing shiny feature. But I think it was the right choice and it's part of the early lesson to know when to to say stop and when to retire those features even though they've been the one that have helped you write the the story for a long time. To close that first chapter, one very important foundation of trust was our choice of having a zero knowledge architecture. So what I mean by zero knowledge architecture is the fact that at no point in time do we want to have

access to your data. Your customer data is your own. You have the keys. We don't have the keys. And so the whole architecture on dash has been built around that that concept. So we do encryption and decryption of your vault locally on your device. We never see any data in clear. We never see your master password your main key. So that has been very critical to the whole foundation of dashing. The the flip side of that is for an engineering team it's very complicated because every feature you need to build you need to think about how okay how do I make sure that I can never see the data and so it's a lot of additional uh

um complexity in terms of technical design in terms of security and cryptography think about if you want to share credential between two parties how do you make sure that you never see that data flow even though you are like the the intermediary in that that exchange but at the end of the day it's critical for trust because it reduces the exposures for the customers obviously It reduces the exposure also for dash in terms of liability because it makes it makes us like a sort of secure by design. Another painful thing for the engine team is also troubleshooting because if you don't see the data it becomes very hard for you to troubleshoot and try to

debug what's happen. But that's a trade-off we made from the early days of Dashlane. Uh even though it was costly and sometimes uh it took us more time to build features but it was really important as a foundation of trust if you will. So those are the the early lessons from the Dian story the some of the nightmares that they they had and I inherited all of that when I joined in 2015 with a mandate of saying okay now we've achieved product market fit at that point they just raised a series B they wanted to scale and I I joined to help them scale scale scale the business so scale through million more customers scale from B2C to B2B scale through

multiple platforms and as you can imagine scaling is also coming with a lot of complexity actually when I arrived web the team was already pretty doing well like they had achieved that product market fit they had shipped fast they had to ship boldly they had innovated quite a lot so there was no burning fire I didn't have to rebuild everything so I took the time to uh to learn and really get on boarded with the right amount of time at first I really met with everybody in the organization like to 30 minutes to to understand okay how are things how is your work life how is your personal life I had like a my little method with three

questions like how happy are you from one to five what do you like to work most on and what would you like to change and that really gave me like sort of the the visibility into okay what was working well what didn't work so well and we wanted to improve I spent time like of course uh uh going through sprint planning sprint previews the architecture and so on to understand how we had to to scale and so the lesson for me was actually they had gone fast but also a bit more in too much into survival mode trying to get to the next level of the startup journey and they didn't really have the best practices to

really able to be able to scale without creating too game. So that's what we focused on. That maybe seem funny in almost 2026, but we migrated to Git at the time to make sure that we have the real versioning control in place and uh we're able to collaborate the right way. We set up the first continuous integration at Dashland to make sure we could collaborate together. We started in test automation. We started putting mandatory systematic code review process in place which didn't exist at Dash at the time which was weird for a secret product but so all those practices were really meant for us to be able to to scale the right way. But actually like the technical scaling

is where the most challenges we found the most challenges. The first one is I mentioned we had a lot of different platforms. We had Windows all the versions of Windows, Mac OS, iOS, Android, all the browser extension including Internet Explorer. That became a real burden for the the organization. We were pretty small and each platform had their own technical stack, their own maintenance overhead, their own security risk and exposure and context. And so it was really way more way too costly for us to be able to support all of that. So in 2019, we actually took a very hard decision to say, "Okay, we're going to sunset the desktop native apps. We're going to stop supporting Windows and Mac

OS as native applications." From a customer standpoint, it kind of made sense because most of your authentication life already happened in the in the browser. But as you can imagine, when you have that applica those application being used by already millions of customers, it's it's tough to manage as a as a transition. I still think it was the right choice and maybe we could have taken that choice a bit earlier on but not that much earlier because the sort of the browser maturity needed to be there but it helped us like reduce the exposure from a secret standpoint reduce the cost of for the organization I wanted to mention also autofill engine because that's core to the product the

way we we detect login forums and field and autofill this is really to the value of dash and same thing that's been a painful uh thing to maintain because it was originally in C++ in the native apps a lot of complicated communication between the uh the native app and the browser and we had to rewrite it multiple times and eventually write it in JavaScript so it's it could run standalone in the browsers but when you have a small organization and you need to rewrite your the core of your product multiple times it's very costly very complicated so you still have to do it but uh those are the type of projects which are hard to uh to embed into the

road map because we have so many platform we also like sort of guest on those ecosystems and we have to live with those ecosystems I mean some Some of you may be familiar with what that means, but for instance, Firefox has a crazy submission rule when you want to to submit an extension. Uh, Chrome a few years back decided to migrate the architecture of the extension from manifest v2 to manifest v3 and that was a nightmare for people like us that have very deeply uh uh integrated extension into the the the browser ecosystem. There was a lot of conversation at the WC level with those things but uh so you have to try and lobby and make things

better. Um I mentioned the iOS force upgrade which was a nightmare for us but so we have to live with that we have to sort of accept that those happened. It means also you need to build the relationship with those ecosystem to make sure you can also influence and uh and shape the future of those those platforms but that's that's something that's really important in an engineering team and that's kind of putting friction on the path to scale and if I look back at that time there are also two big mistakes that we made at the time. The first one is we had a lot of technical debt from the early days. Uh so that's something we had to

be careful about and we didn't pay fast enough. There was a lot of technical debt from the rapid experimentation from the early days. And the second thing is that sometimes we overengineered too much for security. We wanted security to be too perfect and for instance our sharing feature was a very cool sharing feature in the first versions. It was kind of a mini blockchain mini ledger wouldn't be for blockchain. But we didn't need that complexity. So we rewrote it at some point made it way simpler. And I would argue it's still a bit too complicated. Okay, I need to accelerate because I'm not going fast enough. Important point about encryption, especially for security product, you

always need to be ahead of the game. You need to be it's a game of cat and mouse with the with the hackers out there. So CPUs, GPUs, the power is going faster and faster. So you need to be ahead of the game. So one only decision we took was to migrate from PVKDF2 to Argon 2. At the time argon 2 was not even like a standard, was not even needs to prove and anything else. But we took that bet. We made the migration and one thing that was very important for us is that we didn't want to lock people out. So that was a long migration. As you can see, it took us about three years to to migrate

all the platform because we we we had been burned by that iOS upgrade type of event and we wanted to make it make it the right way. Okay, I'm going to play a little outbreak here because I think it's fun. So I let you watch it and then I'll comment on it.

>> Thanks. Can we go back? I I have money. I can pay you.

>> Is that where we're going? That place looks amazing. >> Yeah.

I don't know. Oh no. Miss B. Why are you dolphin? WANT TO BE AN ELEPHANT? Go back.

So, it it was a cool ad. It was a Super Bowl ad. So, I let you imagine the price of the Super Bowl ad. It was a massive mistake. We did that in February 2020, a few weeks after COVID hit, everything stopped. Uh, so it was fun. Like, we had a big spike of visibility and awareness for a few weeks, months, and then it was nothing. So my advice never do a super I it's not worth it. Um that big mistake was still came with a lesson for us because we are still a very much of a consumer product trying to to bring awareness to to consumers which is very very expensive and we are a small

startup. Of course we had raised quite a lot of money but still that the error is not there and so at that point we decided to okay we need to pivot to more B2B where we can differentiate and where there's more of a potential error. We still have a large B2C uh business and we're happy that to have that that population but really the money is in the B2B so be honest. Okay, fine final part of the story. The the so at that point we are in B2B. We are growing fast and growing well. And so the last few years of the the story are really about okay, we're still kind of between the hammer and the envelope.

On the one side, you have the big tech, Apple, Google, you have the SSO providers, the octa of the worlds that the other competitors are of course expanding as well and growing their business. And we're still a relatively small player. So we're kind of in between. What do we do? Do we kind of uh try to double down on getting the business out there and trying to keep the lights on or do we need to to invest into innovation because we need to differentiate if you want to be there in the long run. So you have that kind of innovators dilemma that plays out which has been a lot of the tension we've had in the organization in the past few

years. I actually think that we did the right thing because we try to turn more towards innovation and that's why I guess we're still here. But um I'm going to share a few of those those innovations. So the first one is uh confidential computing and How many of you are familiar with confidential computing? But like I said, our core principle is zero knowledge. We never want to have access to your data. But if you start integrating your product in a B2B ecosystem with third party providers, then how do you do it? How do you manage the that zero knowledge concept when data flows are going outside of your product? The example is our first version of integrating Dash and with SSO

requested required our customers to host in their infrastructure a small backend component to be able to store their keys. That was secure that was zero knowledge but it was very painful and created a lot of friction for our customer. We didn't know how to do that. And so with configuration computing and the hardware secure enclave in the cloud we're able to move that component and that storing of keys into the cloud in a secure way but in a way more convenient fashion for our customers. And we've been using that more and more in our product in a way to really extend our zero knowledge print beyond the device and to the cloud. By the way, if you're

and I know there are a lot of students as well here, but if you're in a company that's in health tech, in edtech in that processes a lot of sensitive data for your customers, I strongly encourage you to look at configuration computing. It's still pretty complicated to be honest. you need to make it right and do it right because it's not a a very standard technology but it's really a a way for you to have a the famous encryption in use like of course encryption in transit of the data encryption at rest on your servers but the encryption use is a difficult part and that's what something continuous computing allows you to do so take a look at at this it's it's a

really cool technology a big moment we had in 2022 was the the pasky moment so when the pho alliance along with Google apple Microsoft and whole industries came with pass keys. That was kind of a turning point for us like okay what happens if the platform become the password of the future? What if there are no passwords? What happens with password managers? It could have been an existential threat for us. The we decided to do go the other way around and kind of embrace that that change. We're already part of the F alliance but we decided to join the board to try and not only be passive and try to look what what was happening but be shaping the

standards shaping the future as well. And we're the one of the first passive managers to support past across all platforms. We have our own master password solution today. So if you're a consumer, you can create a you can create a dash account without even having master password. Uh we've really embraced it and we've been shaping some of the standard. One of the standard that came out recently is it's called credential exchange which allows you to import and export credential from one provider to the other which you could argue should have existed for a long time but is just coming out today and we're happy about this. So uh uh just sharing the lesson here that sometimes you have those like

a big moment coming from the industry that can feel like very threatening for you as an organization and you can either retreat and u our CP at the time decided to leave dash too bad for him. I think it was the wrong the wrong decision but we decided to go all in and uh go with the with the journey and become sort of a pass manager if you will. And one last lesson of those past few years is also innovation can can come from everywhere and you need the space and the time for the team to be able to invest into your innovation. So I'm sharing here one which came from the dash hackathon. We run hackathon every

year. One of the big challenges for a product like ours in an organization is that of course the IT team or the security team is going to deploy dash across the organization but then you have employees that will use the the past manager and other that won't. So how do you make sure that every employee is protected whether they are using the product or not? And so that that that team that run the hackathon and wanted to change that paradigm. How can we make sure that the the passive employee can be protected as well. And because we are in the browser, we've been deployed in the browser, we can actually do cool stuff. We can detect credential risks in

the browser. So if you have an employee typing a weak password or a compromised password manually in the browser, we can see that we can detect that and we can alert the employee that is doing something wrong and you can alert the security team that that employee did something wrong and create that that virtual cycle. Same thing like you've all heard about AI fishing attacks like since charge GPT came out I don't know if you know the numbers but uh it's like 40 4,000% increase of fishing attacks something like 50% success rate when fishing attacks used to be more of a pray and pray attacking so uh we're in the browser we can detect if a website

is a fishing website so we have a model we we do that and that came also from an innovation from part of the team gave them space and they were able to uh to figure out different ways of approaching the same problem so I encourage you all of you in organization to to make the space for this to happen and to uh to to to create those pockets of innovation as part of your organizations. Okay, that's it. Kind of stepping back on that journey. Trust is not only about cryptography, it's not only about architecture, it's really about culture, it's about leadership, it's about the decisions you make as an organization. How do you stay true to your core

principle and your values? Uh in our case, your knowledge was a big foundation and we've tried to be really true to that even when the trade-offs are tough and when you see some of your competitors taking shortcuts. You don't want to take those shortcuts because you know that they will matter in the long run. And my last lesson is also like usability and security are sort of two sides of the necessary coin. You need to both together. I'd rather like improve the security a little because I have good UX and good uh convenience for the many rather than try to be perfect and have too much friction along the way. So try to think about those things in your

own journey in your own own product and your own context. And I hope it can give you like a um a way to move forward in terms of of security. By the way, we try to also be uh I'm going to do a bit of promotion for the CISA here, but they have a cool secure by design pledge, which is I think important for all of us in the security space to commit to security by design. So, unfortunately, they're in shutdown right now, but you can still look them up and uh I encourage you to also sign security by design. It's a good one. Thank you. [applause] questions.

>> I am a security and privacy individual or individual contributor at a startup not start anywhere. Um I think there's always a challenge between balancing products and kind of like what you advocated on building trust with your customers. How do you balance that and what are some quantitative ways uh that you use to make those decisions you know hardiness? Yeah, that's that's why we have an ongo I mean ongoing conversation all the time about balancing that like how how does security needs to be a selling point to some extent but it's also a friction point in the organization to move fast and to uh to get new features out but you need to find that balance by having

an open and honest conversation inside the organization and that's why I was mentioning it it's a lot also about leadership is your leadership or is the organization as a leadership standpoint like mature enough and aware enough of the importance of course you don't want to die. So you need to still move fast, but you also want to make sure you have a business in the long run. One thing that we do for instance is what we have what we call the risk committee. We have a long-standing risk committee for many many years. And that risk committee, there's a CEO. There's of course myself, our general general counsel. Now, our CISO is in there. She's over there. You

can talk to her if you want after the the talk. Uh there's also our chief marketing officer because of course marketing always want to know more about your your customers. But when you don't see the data, you don't know much about your customers. And that makes sure that the organization always has that conversation and sometimes say okay we're doing tradeoff and we're going to a bit faster here but we'll catch up eventually or not. And we we have our own little risk index that we measure measure internally and the goal for us is every year we try to reduce that risk index by 10 points. That's our kind of arbitrary measure but that's a forcing

function for to say that okay we need to make sure that we don't take too much risk.

Sorry, I'll be outside and we also have a a table that