WEBVTT 00:00:01.470 --> 00:00:06.210 It's Rust in Production, a podcast about companies who use Rust to shape the 00:00:06.210 --> 00:00:07.150 future of infrastructure. 00:00:07.490 --> 00:00:12.750 I'm Matthias Endler from corrode, and today we talk to Andrew Burkhardt from 00:00:12.750 --> 00:00:16.010 1Password about securing logins with Rust. 00:00:19.150 --> 00:00:23.810 Andrew, thanks so much for being a guest today. Can you say a few words about 00:00:23.810 --> 00:00:25.450 yourself and about 1Password? 00:00:26.410 --> 00:00:29.370 Yeah, definitely. Thank you for having me. So I'm Andrew Burkhardt. 00:00:29.490 --> 00:00:34.170 I'm a senior Rust developer at 1Password. I work on the product foundations 00:00:34.170 --> 00:00:37.030 team, or in the org, I should say, on the frameworks team. 00:00:37.090 --> 00:00:41.590 So we specifically focus mostly on async Rust frameworks. 00:00:41.910 --> 00:00:47.330 I've been here about three years now and working on data synchronization mostly, 00:00:47.550 --> 00:00:50.350 which has been pretty interesting as we grow. 00:00:50.650 --> 00:00:54.430 We spread kind of to other products that have come in. You know, 00:00:54.510 --> 00:00:57.950 the password manager has kind of historically been our core business, 00:00:57.950 --> 00:01:00.890 and that's what people have known us for for almost 20 years now. 00:01:01.250 --> 00:01:04.730 But, you know, over the last few years, especially, we've grown a lot and acquired 00:01:04.730 --> 00:01:10.270 a few companies and so forth and really spread ourselves across the security space, 00:01:10.490 --> 00:01:13.650 you know, with various things from the password manager to, you know, 00:01:13.730 --> 00:01:18.290 developer tools and a lot of like enterprise password management features. 00:01:18.290 --> 00:01:21.810 And we have things like connect servers and so forth that, you know, 00:01:22.090 --> 00:01:24.870 skim bridges that help with identity management, all these things. 00:01:25.050 --> 00:01:29.050 And then into the companies that we acquired, like Passage, which helps with 00:01:29.050 --> 00:01:33.870 Passkeys, Collide, which does on-device health checking, Metrolika, 00:01:34.050 --> 00:01:36.270 which handles provisioning and some things like that. 00:01:37.420 --> 00:01:40.460 So, yeah, so across all those various areas, you know, sync has been a really, 00:01:40.620 --> 00:01:45.780 really interesting use case to kind of combine all the various information we have in different ways. 00:01:46.440 --> 00:01:52.520 And by sync, you mean actually combining all of the information from devices 00:01:52.520 --> 00:01:55.440 or user profiles or what does that mean exactly? 00:01:56.100 --> 00:02:00.660 Yeah, so the sort of summary, I guess, would probably be, you know, 00:02:00.800 --> 00:02:06.020 federating or, you know, getting the data to be the same from clients to the 00:02:06.020 --> 00:02:10.260 Rust core to the server and all the way back around to any clients that are relevant. 00:02:11.180 --> 00:02:14.680 So that may be something as simple as, you know, you and I are on the same one 00:02:14.680 --> 00:02:18.680 password account in the password manager and I add an item that you now need. 00:02:18.680 --> 00:02:23.520 So we sync that data across, but it can also be other things like, 00:02:23.620 --> 00:02:25.060 you know, if you're in the enterprise space, 00:02:25.300 --> 00:02:28.880 just making sure that the data from one place talks to another and so forth, 00:02:28.940 --> 00:02:33.940 so that if there is relevant context from one area, that is available, area, things like that. 00:02:34.520 --> 00:02:38.660 Yeah i can totally relate to that because one of the worst 00:02:38.660 --> 00:02:41.800 developer experiences is if data that 00:02:41.800 --> 00:02:44.920 you expect to be there isn't there or is in 00:02:44.920 --> 00:02:51.080 a sort of limbo and i think sync needs to be really reliable and that's the 00:02:51.080 --> 00:02:55.420 core of the product if that is not reliable then well everything else is just 00:02:55.420 --> 00:03:00.760 nice user experience but it's not really like i would say user interface but 00:03:00.760 --> 00:03:02.040 not a great user experience. 00:03:02.040 --> 00:03:04.880 Yeah definitely and that's you know it's created 00:03:04.880 --> 00:03:07.620 a lot of you know patterns i guess you 00:03:07.620 --> 00:03:10.400 would say that we hold pretty strongly to like you know sync 00:03:10.400 --> 00:03:13.280 here conversations about this this morning actually sync here is 00:03:13.280 --> 00:03:16.320 always sort of a background task so anything 00:03:16.320 --> 00:03:19.080 that you're doing sync should essentially be a side effect 00:03:19.080 --> 00:03:23.880 of it and it should happen asynchronously in the background and you know that 00:03:23.880 --> 00:03:28.880 way you kind of always assume that the data you have is current because sync 00:03:28.880 --> 00:03:32.420 has been happening in the background and therefore you have the expectation 00:03:32.420 --> 00:03:36.400 that that data has already been brought locally to your device, 00:03:36.540 --> 00:03:40.220 which gives the feature developers a little bit of freedom because you don't 00:03:40.220 --> 00:03:42.240 have to go request things and wait for it and do this. 00:03:42.360 --> 00:03:45.300 I mean, there are cases where that has to happen, but in general, 00:03:45.700 --> 00:03:49.840 the vast majority of the data has already been brought locally and cached and so forth. 00:03:49.920 --> 00:03:53.500 So I can just act on that cache as though, you know, I'm the only one using 00:03:53.500 --> 00:03:57.180 this data or something, which is convenient in a lot of cases. 00:03:58.020 --> 00:04:02.440 It's sort of funny that you need async in order for something to be synced, 00:04:02.520 --> 00:04:06.880 but it does make sense if you think about it because, well, it happens in the background and, 00:04:08.120 --> 00:04:13.220 A lot of things need to happen for it to look synchronous, but it's not easy. 00:04:14.220 --> 00:04:19.180 Yeah, yeah, definitely. And you get into the nitty gritty details of like synchronous 00:04:19.180 --> 00:04:25.720 versus synchronized and so forth. And we definitely overload the word sync probably way too much. 00:04:26.120 --> 00:04:31.680 So take us back a couple of years ago when you started. You said you're at 1Password 00:04:31.680 --> 00:04:33.040 for three years now, I guess. 00:04:33.760 --> 00:04:38.220 What was your background back then? Where do you come from? And then what was 00:04:38.220 --> 00:04:41.400 the state of Rust at 1Password when you started? 00:04:41.920 --> 00:04:48.580 Yeah, so I had done mostly, my prior job had been a lot of Kotlin and Spring 00:04:48.580 --> 00:04:54.260 Boot, which, you know, is kind of like, it's a framework for Kotlin doing server side stuff. 00:04:54.880 --> 00:04:58.400 And I was doing a lot of that, like backend web programming. 00:04:58.660 --> 00:05:03.540 I also worked on the front end a little bit with TypeScript and the Vue framework for UI. 00:05:03.800 --> 00:05:07.320 But I wasn't really like a front end developer. I did, you know, 00:05:07.320 --> 00:05:10.040 it's referred to, I think, as like the BFF pattern where like, 00:05:10.140 --> 00:05:13.080 you have one server that manages a lot of different things. 00:05:13.220 --> 00:05:16.060 And then you have all these front ends that manage pieces of that, 00:05:16.160 --> 00:05:19.260 right? Like, for example, I worked on an app that did a lot of settings, 00:05:19.500 --> 00:05:20.640 like behind the scenes settings. 00:05:20.880 --> 00:05:24.780 And then we had a lot of other apps where actual end users would interact with 00:05:24.780 --> 00:05:27.300 it. And the one main server powered it all. 00:05:27.480 --> 00:05:31.880 But instead of muddying that server with, you know, all these either, 00:05:32.160 --> 00:05:34.020 you know, like you could use something like GraphQL, I suppose. 00:05:34.180 --> 00:05:37.600 But like instead of muddying it with all these APIs that supported vastly different 00:05:37.600 --> 00:05:42.560 use cases, we created these BFF servers where each front end has its own back 00:05:42.560 --> 00:05:46.520 end that then translates to the real sort of underlying back end. 00:05:46.680 --> 00:05:48.460 So I'd always done kind of that mid layer. 00:05:49.180 --> 00:05:53.640 Of development. And that was actually very helpful because it turns out, 00:05:54.000 --> 00:05:57.840 you know, getting into the state of Rust and 1Password is that's kind of how Rust is used here. 00:05:58.040 --> 00:06:03.140 So each of our apps, you know, obviously we have quite a few between iOS and 00:06:03.140 --> 00:06:06.800 Android and Mac and Windows and Linux and web and extension and all these different places. 00:06:07.160 --> 00:06:09.180 All of them are native clients. 00:06:09.580 --> 00:06:12.900 So they operate, you know, the iOS app is in Swift and so forth. 00:06:12.960 --> 00:06:16.860 And then they are bundled with kind of like an embedded backend, 00:06:17.160 --> 00:06:19.460 which is a Rust, we call it the core. 00:06:19.700 --> 00:06:23.840 So the Rust core is inside of all of these and that is doing as much of the 00:06:23.840 --> 00:06:28.620 business logic as we can to leave those native clients to just be display layer, 00:06:28.780 --> 00:06:30.020 essentially a presentation layer. 00:06:30.260 --> 00:06:33.300 And then that communicates to the actual cloud server and so forth. 00:06:33.620 --> 00:06:37.140 And so Rust got picked up here. I don't actually know when it was, 00:06:37.260 --> 00:06:42.420 but my understanding is it was originally picked up for the Windows app that was being built. 00:06:42.960 --> 00:06:48.180 And And over time, when we got from 1Password 7 to 1Password 8, 00:06:48.340 --> 00:06:51.980 I think it was, again, it was slightly before me, but I think that was when 00:06:51.980 --> 00:06:55.080 it was like, okay, we need more cross-platform functionality because we're building 00:06:55.080 --> 00:06:59.880 so many features that were not originally just password management concerns. 00:06:59.880 --> 00:07:03.140 We're building all these different things, and they need to work on all these 00:07:03.140 --> 00:07:05.720 platforms, and we're implementing them over and over and over again. 00:07:05.720 --> 00:07:10.840 And so when they decided they wanted to create sort of the singular core that 00:07:10.840 --> 00:07:14.120 was going to power all the apps, they had already started to use Rust on Windows 00:07:14.120 --> 00:07:17.240 and it had worked really well. And so a lot of it just got ported over. 00:07:17.480 --> 00:07:21.740 And so when I got here, we were just in this kind of big growth phase back in 00:07:21.740 --> 00:07:28.100 2022 and a ton of new people coming in. And so Rust was sort of proliferating 00:07:28.100 --> 00:07:31.220 very quickly as the core was building, you know, all these developer features 00:07:31.220 --> 00:07:32.420 and these different things. 00:07:32.820 --> 00:07:38.640 And it was right about then we did a reorg of the development teams and created 00:07:38.640 --> 00:07:40.960 the team that I'm now on, which is the frameworks team, 00:07:41.140 --> 00:07:45.180 along with a few other teams that do, for example, like security specific development 00:07:45.180 --> 00:07:50.520 or platform specific development, like handling the nuances of Windows or Android or whatever it might be. 00:07:51.320 --> 00:07:57.040 And all of us kind of came together to design patterns and rules and so forth 00:07:57.040 --> 00:08:00.660 around Rust development to try to sort of wrangle all these different things that were happening. 00:08:00.880 --> 00:08:04.760 And that's kind of got us into the patterns that we have today, 00:08:04.980 --> 00:08:10.500 which have been really nice to keep this giant core as maintainable as possible. 00:08:11.400 --> 00:08:15.980 Nice. I want to get back to the patterns in a second. But before we do that, 00:08:16.380 --> 00:08:21.040 what did you use before Rust? Was it very platform dependent? 00:08:21.400 --> 00:08:25.940 Did you have this business logic in, for example, Kotlin and then Swift and so on? 00:08:26.760 --> 00:08:29.640 Yeah, exactly. So, like I said, that was all before me. 00:08:29.720 --> 00:08:32.680 But my understanding is that everything was basically built natively, 00:08:32.820 --> 00:08:35.940 which gives you some benefits, right? There are pros and cons of that. 00:08:36.060 --> 00:08:41.180 But at the scale that we're at now, it's just not feasible to have that much 00:08:41.180 --> 00:08:45.100 code and have that many different implementations. And obviously, 00:08:45.260 --> 00:08:49.920 just when you're building a security app, you don't, multiple implementations is a problem, right? 00:08:50.040 --> 00:08:54.340 Anytime you have to do that, there is now the risk that one of these implementations 00:08:54.340 --> 00:08:56.560 is vulnerable in some way that the other isn't. 00:08:56.720 --> 00:09:00.440 And we're trying to compare, you know, Swift code to Kotlin code to TypeScript 00:09:00.440 --> 00:09:03.980 to, you know, Go or whatever and so forth, and make sure that these are all 00:09:03.980 --> 00:09:05.020 doing the exact same thing. 00:09:05.180 --> 00:09:09.500 But those languages may have different underlying models for async or memory 00:09:09.500 --> 00:09:15.040 management or whatever it is. And so it just wasn't feasible to continue on like that. 00:09:15.200 --> 00:09:19.520 And so the REST core really helped us to, I mean, it just enabled features that 00:09:19.520 --> 00:09:22.060 we really weren't, that weren't possible before. 00:09:22.660 --> 00:09:26.520 In my idealized way to think about it, 00:09:26.840 --> 00:09:33.380 what I hope would happen is that once you merge in all of that code into one 00:09:33.380 --> 00:09:35.480 code base, into one Rust code base, 00:09:35.680 --> 00:09:41.180 that you see how different platforms or different languages solve these problems 00:09:41.180 --> 00:09:46.040 or different developers solve the same problem and some of them solve different edge cases. 00:09:46.240 --> 00:09:50.040 And then when you merge that together, you get a thing that is stronger than 00:09:50.040 --> 00:09:52.320 its parts. did that happen? 00:09:53.460 --> 00:09:56.420 Yeah I think so I think and you get the opposite too 00:09:56.420 --> 00:09:59.160 right where it's like you know we'll get one component and it's like what is 00:09:59.160 --> 00:10:01.980 this thing doing it's like oh we ported that from this other version like 00:10:01.980 --> 00:10:05.380 oh that was the worst version why did we pick that one you know and so you do 00:10:05.380 --> 00:10:09.480 see that but yeah I think in a lot of ways you definitely get the benefit of 00:10:09.480 --> 00:10:13.600 that and we see that having native clients I mean we've got developers who have 00:10:13.600 --> 00:10:17.320 done Swift and Mac development for you know 20 years or whatever it might be 00:10:17.320 --> 00:10:21.100 and so then they come at it and it's like okay hey hey, we need to build this feature. 00:10:21.460 --> 00:10:24.480 You know, I need some help with the Rust side of it. And you see something and 00:10:24.480 --> 00:10:26.840 you're like, that's not at all how I would have thought to do it. 00:10:26.880 --> 00:10:28.880 And they're like, well, here's how we do it, you know, in Mac land. 00:10:29.160 --> 00:10:33.520 And you start to get interesting new ideas, I think, about how you can handle, 00:10:34.040 --> 00:10:35.700 you know, how you can tackle various problems. 00:10:35.980 --> 00:10:39.740 So I think we get that just by nature of having all the different developers, 00:10:39.920 --> 00:10:46.020 but we definitely saw it in the growth of the Rust core and trying to pull things together. 00:10:46.020 --> 00:10:50.800 And now trying to add in some of the browser features that we had implemented 00:10:50.800 --> 00:10:54.860 natively in the browser, now that we're trying to pull them into Rust and compile 00:10:54.860 --> 00:10:58.740 them into Wasm, we're seeing some of those patterns again that we can learn 00:10:58.740 --> 00:11:00.480 from and improve throughout. 00:11:01.200 --> 00:11:06.600 Was the Rust ecosystem prepared for what 1Password asked it to do? 00:11:06.680 --> 00:11:11.120 Or were there any gaps in the Crate ecosystem, for example? 00:11:11.420 --> 00:11:14.620 I think there were probably some. I would say, in general, yes. 00:11:14.740 --> 00:11:17.160 I think the ecosystem was growing so fast and. 00:11:17.840 --> 00:11:21.340 There were so many people building interesting things that I think it gave us 00:11:21.340 --> 00:11:25.220 a lot of freedom to innovate on top of those. 00:11:25.380 --> 00:11:29.120 I think there were small gaps, which is where you've seen some of the crates that we've put out. 00:11:29.540 --> 00:11:33.440 Gaps like, for example, having those native clients, there's no type safety 00:11:33.440 --> 00:11:35.400 across the FFI necessarily. 00:11:35.400 --> 00:11:39.160 If I'm writing Swift and then I send something into the FFI and then into the 00:11:39.160 --> 00:11:41.620 Rust core, I'm just hoping the types line up. 00:11:41.620 --> 00:11:46.100 So we created the type share crate, which is, it's not giving you necessarily 00:11:46.100 --> 00:11:49.880 complete type safety, but it is at least making sure that you're not writing 00:11:49.880 --> 00:11:51.340 the types on the client side. 00:11:51.520 --> 00:11:55.320 They are generated from your Rust code so that if the Rust code changes, 00:11:55.540 --> 00:11:59.740 the client side types change. You're not having to manually keep those in sync. 00:11:59.740 --> 00:12:01.740 So I think that's been really helpful. 00:12:02.080 --> 00:12:05.180 And then there are other little things. Another one we released somewhat recently 00:12:05.180 --> 00:12:06.780 is called zeroizing alloc. 00:12:07.220 --> 00:12:12.020 Which is like a wrapper around the global allocator that makes sure, 00:12:12.300 --> 00:12:15.820 you know, if you're using this, whenever memory would normally be deallocated, 00:12:15.960 --> 00:12:18.080 which in that case, you know, it's sort of just dropped, right? 00:12:18.140 --> 00:12:20.540 It's free for the system to use for other things. 00:12:20.720 --> 00:12:24.420 We don't want to just let that sit around in case the system doesn't need it. 00:12:24.480 --> 00:12:27.540 And that memory sits there forever, right? We can't have that when you're dealing 00:12:27.540 --> 00:12:31.640 with sensitive data. So the zeroizing alloc crate will help to just flip those 00:12:31.640 --> 00:12:34.660 all back to zeros during that deallocation process. 00:12:34.860 --> 00:12:39.600 So there were little things like that, that obviously Rust as a language was 00:12:39.600 --> 00:12:42.600 ready for. There just hadn't been that use case necessarily. 00:12:42.880 --> 00:12:47.540 And so I think it created nice gaps for us to fill with some of those things. 00:12:47.900 --> 00:12:51.980 Yeah, I came across this zeroizing alloc crate. 00:12:52.500 --> 00:12:57.280 Actually before that, because the link was purple. So this is how I know. 00:12:58.440 --> 00:13:02.800 I'm surprised that no one else built such a crate before. Or did you look at 00:13:02.800 --> 00:13:04.280 some and didn't really like them? 00:13:05.120 --> 00:13:07.760 I don't know how we came across that. And I wonder to some degree, 00:13:07.860 --> 00:13:10.200 like if you look at the crate, it's not particularly complex, 00:13:10.400 --> 00:13:12.540 right? It's a fairly straightforward implementation. 00:13:13.000 --> 00:13:15.800 And I've seen this in other cases where... 00:13:16.550 --> 00:13:19.670 I think sometimes we look at a problem and we go, oh, it's so simple, 00:13:19.790 --> 00:13:22.010 like I don't need to make a crate to deal with this problem. 00:13:22.170 --> 00:13:25.790 You know, it's maybe a common problem, but it's like, I'll just throw this together. 00:13:27.430 --> 00:13:30.150 And, you know, maybe people don't want the dependency or something like that. 00:13:30.150 --> 00:13:33.970 I'll just kind of hand roll it very similarly or something along those lines. 00:13:34.090 --> 00:13:35.650 I think sometimes that happens, right? 00:13:35.790 --> 00:13:39.710 And people are obviously wary sometimes of dependencies, you know, 00:13:39.790 --> 00:13:42.330 especially ones that do smaller things, right? We saw, I think, 00:13:42.330 --> 00:13:46.070 in the TypeScript NPM world, there was like the left pad incident, 00:13:46.130 --> 00:13:48.790 right? where like all this thing is doing is handling this left padding. 00:13:49.050 --> 00:13:52.670 And it's so simple, but then when it's gone, now we have a big problem, you know. 00:13:52.750 --> 00:13:57.050 And so that could be the reason that some of those things just don't get created. 00:13:57.130 --> 00:13:59.950 It may not be, you know, I doubt we were the first people to think of it. 00:14:00.030 --> 00:14:02.830 You know, it's probably something someone else had solved before. 00:14:03.030 --> 00:14:05.270 They maybe just didn't make a crate for it or something like that. 00:14:05.330 --> 00:14:06.890 Or maybe there is one out there and I just haven't seen. 00:14:07.690 --> 00:14:11.090 What is the policy around creating crates at one password? 00:14:12.530 --> 00:14:17.050 You know, there's, this has been an interesting thing that I've seen here, 00:14:17.150 --> 00:14:22.170 right, is because one password, the password manager concept is 20 years old, right? 00:14:22.330 --> 00:14:25.450 And conceptually, a lot of it is similar to what it was then. 00:14:25.890 --> 00:14:29.210 And then the Rust app itself, you know, now is, you know, five, 00:14:29.350 --> 00:14:32.570 six, seven years old. I don't know exactly how old, but it's been around a while. 00:14:34.010 --> 00:14:38.350 You have these things that have grown so much and for the most part creating 00:14:38.350 --> 00:14:42.930 new crates internally it's just a matter of code architecture does it make sense, 00:14:43.090 --> 00:14:47.530 is it a necessary separation a lot of problems you deal with anywhere, 00:14:48.150 --> 00:14:53.750 making crates public is sometimes tricky because one you have to figure out 00:14:53.750 --> 00:14:56.810 does this make sense to make public like zeroizing alloc, we probably could 00:14:56.810 --> 00:14:59.090 have left that internal but we figured it might help some people, 00:14:59.760 --> 00:15:05.180 And it's not like a, you know, private, you know, secret thing that 1Password does. 00:15:05.300 --> 00:15:08.500 I think a lot of people know that, you know, we have to deal with memory this way. 00:15:10.020 --> 00:15:14.140 So you have some of those initial concerns about whether or not we should make this public. 00:15:14.340 --> 00:15:18.940 And then it's like untangling it from everything else you've built over the last few years, right? 00:15:19.040 --> 00:15:23.920 And, you know, there are things like our, you know, clipboard manager, 00:15:23.920 --> 00:15:26.280 it's called Rboard, that's made public, you know, and you got to go, 00:15:26.280 --> 00:15:29.740 okay, well, we had all these, you know, 1Password specific assumptions. 00:15:30.700 --> 00:15:35.120 Now we have to pull those out and make this just a dependency as though it were 00:15:35.120 --> 00:15:39.600 a third party dependency to us as well, you know, and so a lot of it is just, 00:15:39.700 --> 00:15:42.880 just small bits of process of untangling things. 00:15:43.120 --> 00:15:48.520 But, but as far as deciding to make it public, that's pretty case specific, 00:15:48.520 --> 00:15:50.220 I guess, or situation specific. 00:15:50.520 --> 00:15:53.980 And I think we've been trying to, to get more and more out there. 00:15:53.980 --> 00:15:58.160 You know, we released, for example, the passkey RS crate, which I think is only 00:15:58.160 --> 00:16:00.020 valuable to other password managers. 00:16:00.520 --> 00:16:03.300 Like, I don't know if there's anybody because it really just validates, 00:16:03.480 --> 00:16:07.440 like, does verification of passkeys. And so I don't know that anyone else would ever need it. 00:16:08.120 --> 00:16:10.580 But, you know, we released it because, one, it might help them. 00:16:10.660 --> 00:16:12.940 And we really want to see passkeys get adopted in more places, 00:16:12.940 --> 00:16:15.120 even if that's, you know, in a competing app. 00:16:15.280 --> 00:16:18.400 We want to make sure that that's available and so forth. And it's also just 00:16:18.400 --> 00:16:21.900 interesting, you know, rust that people might be able to learn from and so forth. 00:16:21.900 --> 00:16:26.960 So, yeah, it definitely depends on the situation, but it's a bit of a process either way. 00:16:28.160 --> 00:16:33.220 Maybe one of the listeners checks out that crate and builds a thing that we 00:16:33.220 --> 00:16:34.280 both haven't anticipated. 00:16:34.400 --> 00:16:38.180 It happens more often than I expect. 00:16:38.480 --> 00:16:41.920 And the other thing is open sourcing software. 00:16:43.000 --> 00:16:48.180 Whether it's Rust or not is a huge lift for every company, because what a lot 00:16:48.180 --> 00:16:52.580 of people forget is everything other than the code, versioning, 00:16:52.780 --> 00:16:57.380 documentation, testing, CI, communication, and so on. 00:16:57.700 --> 00:17:04.940 And also, to some extent, exposing how you build things at a certain company. 00:17:05.160 --> 00:17:10.000 And also, a lot of developers are afraid to share how they write code. 00:17:10.000 --> 00:17:15.400 And did you ever get any external contributions to make it worth it? 00:17:16.500 --> 00:17:20.360 Yeah, I mean, especially like with TypeShare, I think I'm trying to think of what language it was. 00:17:20.680 --> 00:17:24.860 I want to say like Scala or something like that. Like some, you know, we don't use Scala. 00:17:25.040 --> 00:17:28.880 And so we never built, you know, a TypeShare integration with Scala, 00:17:29.060 --> 00:17:30.280 but someone from the community did. 00:17:30.420 --> 00:17:33.180 And so now I want to say it's Scala. Now there is, you know, 00:17:33.240 --> 00:17:36.200 the capability to convert your Rust types into Scala and so forth. 00:17:36.280 --> 00:17:40.220 And I think those are nice. We don't, I don't know that we've ever really open 00:17:40.220 --> 00:17:44.220 sourced anything with the hope that people would build features that we need. 00:17:44.440 --> 00:17:47.560 You know, we generally are trying to do it sort of the other way around, 00:17:47.680 --> 00:17:50.600 like, you know, make sure that our work is helping people where we can. 00:17:50.740 --> 00:17:55.260 Like you said, it can be tricky, especially just from an operational standpoint, right? 00:17:55.360 --> 00:18:00.480 There's, I think I saw some, we have like 150,000 businesses that use 1Password 00:18:00.480 --> 00:18:01.940 or something like that or more than that. 00:18:02.280 --> 00:18:02.400 Wow. 00:18:02.600 --> 00:18:06.460 So when you have that number of people, the number of needs is pretty high, 00:18:06.540 --> 00:18:11.200 right? We have a lot of, this company needs this thing and this company needs this thing and so forth. 00:18:11.340 --> 00:18:15.660 And if you open source something, you lose the ability to make breaking changes quickly. 00:18:16.220 --> 00:18:19.520 You don't want to, I mean, I guess you technically could, but that's not a very 00:18:19.520 --> 00:18:22.140 good open source project if you're just breaking all the time. 00:18:23.420 --> 00:18:26.880 So that's one of the harder parts is when you're making that decision, 00:18:27.200 --> 00:18:29.100 is this something we can open source? 00:18:29.440 --> 00:18:33.000 And can we give, like you said, versioning, can we give any kind of guarantee 00:18:33.000 --> 00:18:36.760 that if we make version one, And version one is stable and safe and it's good. 00:18:37.270 --> 00:18:40.970 That's fine. But now if we need to make version two a breaking change because 00:18:40.970 --> 00:18:46.150 we need it for something we're trying to build, well, now version one kind of becomes unsupported. 00:18:46.290 --> 00:18:48.430 So if version two doesn't work for what you're trying to do, 00:18:48.610 --> 00:18:51.170 well, now what if there's a security vulnerability with version one? 00:18:51.290 --> 00:18:55.070 Now you've created these two branches that should be maintained by someone. 00:18:55.230 --> 00:18:58.910 And if that happens a second time and a third time, you just create this web 00:18:58.910 --> 00:19:03.270 of challenges. So, you know, it would be great if we could open source everything, 00:19:03.510 --> 00:19:05.670 you know, and let everyone see all that. 00:19:05.730 --> 00:19:09.170 And I'm sure there are paths to that. It just doesn't, it's not very easy. 00:19:09.370 --> 00:19:12.170 Like you said, it's very challenging. It's not as simple as like, 00:19:12.270 --> 00:19:12.950 well, just make it public. 00:19:13.150 --> 00:19:16.450 You know, you've got to do a lot of management to make that work. 00:19:16.590 --> 00:19:21.650 And, you know, as things ebb and flow, that can be really hard to keep up with, 00:19:21.830 --> 00:19:23.350 you know, responsibly and reliably. 00:19:24.190 --> 00:19:29.710 Yeah. And even if you didn't open source it, and even if you just used a crate 00:19:29.710 --> 00:19:34.990 across different teams, that is still a challenge. Do you have a monorepo? 00:19:35.450 --> 00:19:37.850 What does the structure look like right now? 00:19:38.390 --> 00:19:44.310 Yeah, so it is a monorepo. We have various repos for services and things like 00:19:44.310 --> 00:19:48.550 that, but the Rust core itself and all of the client apps built on it is a monorepo, 00:19:48.790 --> 00:19:54.250 which gives us some benefits from sort of a build and release avenue, right? 00:19:54.250 --> 00:19:57.270 Where everything, you don't have to bring in other, you know, 00:19:57.350 --> 00:20:00.170 repos and so forth to keep everything up to date. It's all in one place. 00:20:00.510 --> 00:20:04.690 But like you said, that means that, you know, you know, merge conflicts can 00:20:04.690 --> 00:20:09.810 be a problem and all these different things that are reliant on what you're working on. 00:20:10.270 --> 00:20:13.810 And that's, that's tricky, especially from, you know, a team sitting where we 00:20:13.810 --> 00:20:16.670 do kind of at the very bottom of the whole stack. 00:20:17.070 --> 00:20:20.550 You know, when we make a change, there tends to be a very significant ripple 00:20:20.550 --> 00:20:24.830 effect that, you know, and you get into challenges like, how do we manage that, right? 00:20:24.910 --> 00:20:26.950 Does our team, you know, if you have code that depends on that, 00:20:27.130 --> 00:20:30.010 do we just tell you, hey, we're going to break this and you need to be ready 00:20:30.010 --> 00:20:32.850 to work with us to do the new thing or do we fix it for you, 00:20:33.270 --> 00:20:39.170 you know, and so forth. And there can be a lot of communication that needs to occur as you grow. 00:20:39.390 --> 00:20:43.990 And, you know, you talk about like the mythical man month, you know, concept, right? 00:20:44.110 --> 00:20:45.890 Of like throwing two more people 00:20:45.890 --> 00:20:48.970 onto a project does not give you two more people's worth of time, right? 00:20:49.150 --> 00:20:53.290 You have extra communication. There's all these new channels that have been 00:20:53.290 --> 00:20:56.410 created between those people and the other people and so forth. 00:20:56.450 --> 00:20:58.350 And it will test your processes and 00:20:58.350 --> 00:21:02.110 your org structure and your code architecture, you know, at every turn. 00:21:02.250 --> 00:21:06.350 And so when you get to hundreds of developers working on sometimes completely 00:21:06.350 --> 00:21:10.110 different, you know, things, right? They're not even password management concepts. 00:21:10.290 --> 00:21:14.990 They are, you know, they may be related to secrets, right? Like the SSH agent that 1Password has. 00:21:15.130 --> 00:21:18.670 Well, that's related to some amount of secret, but it is not at all related, 00:21:18.930 --> 00:21:22.270 you know, to profiles or settings in the password manager or things like that. 00:21:22.270 --> 00:21:27.090 So you can get into challenging situations where you're trying to coordinate 00:21:27.090 --> 00:21:32.170 underlying frameworks across completely different feature teams and, 00:21:32.960 --> 00:21:36.480 Yeah, that's problematic at times, and it definitely can slow things down, 00:21:36.600 --> 00:21:39.400 but it also becomes a strength when you're learning from things. 00:21:40.180 --> 00:21:43.440 Let's talk scale, because people like numbers. 00:21:43.820 --> 00:21:51.400 Can you share some of the, let's say, I would say more interesting numbers about 00:21:51.400 --> 00:21:56.960 the code size and the number of people working with Rust and crates maintained and so on? 00:21:57.480 --> 00:22:02.960 Yeah, so we are, I think I just looked the other day and we were at like five 00:22:02.960 --> 00:22:08.560 or 600,000 lines of rust in the core across like 600-ish crates. 00:22:08.780 --> 00:22:12.680 I think we're just shy of 600 crates internal plus dependencies. 00:22:13.660 --> 00:22:18.880 So it's a pretty big code base, right? And like I said, that core makes up as 00:22:18.880 --> 00:22:22.220 much of the business logic as we can get it to. 00:22:22.540 --> 00:22:26.840 So I don't know the exact spread of all of it because, you know, 00:22:26.900 --> 00:22:30.320 when you're implementing a feature, you have to also implement it in the native clients, right? 00:22:30.580 --> 00:22:34.220 So some amount, you know, every feature is going to have some Swift and some 00:22:34.220 --> 00:22:36.440 Kotlin and TypeScript and all these different things. 00:22:36.860 --> 00:22:39.400 So I would say, you know, and then you've got server-side stuff, 00:22:39.500 --> 00:22:44.260 which not all of our server-side stuff is in Rust. There's a lot of Go on the server side. 00:22:44.400 --> 00:22:48.240 So I would say probably 50% of everything new that we write is in Rust, 00:22:48.400 --> 00:22:51.580 but it's definitely spread across all those other things. 00:22:51.760 --> 00:22:55.820 You know, writing an end-to-end feature will involve Go and Rust. 00:22:56.080 --> 00:23:00.380 And Swift and Kotlin and TypeScript and possibly go on the CLI side and so forth. 00:23:00.540 --> 00:23:05.140 So there's quite a bit that goes into that. But there's probably, 00:23:05.320 --> 00:23:08.660 I think we have a couple hundred developers now working across all the different 00:23:08.660 --> 00:23:13.360 products that 1Password and Collide and Passage and Trelica and so forth have. 00:23:13.680 --> 00:23:18.380 But we probably have, I don't know, I'd say 100 people that work pretty heavily 00:23:18.380 --> 00:23:24.160 in Rust or maybe 50% or more in Rust, something like that. But that's definitely a bit of a guess. 00:23:25.940 --> 00:23:32.540 Awesome which ffi bridge works the least well for you right now like what gives 00:23:32.540 --> 00:23:34.440 you the most headaches at the moment. 00:23:34.440 --> 00:23:42.240 It depends i think as far as the actual ffi goes the most challenging ones are 00:23:42.240 --> 00:23:46.800 probably well i guess android can be a little bit tricky sometimes, 00:23:47.860 --> 00:23:50.800 you know, especially just Android, the ecosystem's a little bit different. 00:23:50.980 --> 00:23:54.160 You know, we were built originally as a macOS app. And so I think there's still 00:23:54.160 --> 00:23:58.200 a little bit of that sort of, you know, Apple product DNA built in, 00:23:58.380 --> 00:24:01.980 which, you know, we've tried to spread to all these different platforms and 00:24:01.980 --> 00:24:05.680 make everything work equally well. But I'm sure there's still a little bit of that in there. 00:24:05.860 --> 00:24:09.080 And then the Wasm boundaries can be tough. 00:24:09.300 --> 00:24:11.860 I didn't know anything about Wasm until about a year ago, right? 00:24:11.900 --> 00:24:15.180 I don't think I'd ever really touched it at all. I'd heard of it and knew nothing about it. 00:24:15.340 --> 00:24:19.040 And then you find out little things like, I think there's like no built-in clock 00:24:19.040 --> 00:24:20.580 in Wasm or something like that. 00:24:20.580 --> 00:24:24.340 So you're like faking all these time-based things that you used to do. 00:24:24.560 --> 00:24:30.320 And so that can be a little bit tough when you have concepts baked into how 00:24:30.320 --> 00:24:34.340 the native clients communicate across the FFI that just don't work in Wasm. 00:24:34.420 --> 00:24:37.180 And we end up with a lot of abstractions. 00:24:37.300 --> 00:24:39.500 Like we have, you know, there's send and sync traits in Rust, 00:24:39.600 --> 00:24:43.060 but we have a maybe send and maybe sync trait that handles, you know, 00:24:43.120 --> 00:24:46.340 four people translating between, oh, is this going to be single threaded or 00:24:46.340 --> 00:24:47.720 multi-threaded and so forth? 00:24:47.860 --> 00:24:51.520 And so the WASM boundaries are probably the toughest, to be honest. 00:24:52.520 --> 00:24:57.400 Okay. Yeah. The maybe send and maybe sync sounds interesting. 00:24:58.560 --> 00:25:01.840 Wouldn't that be a question mark send and question mark sync? 00:25:02.280 --> 00:25:07.300 I think it could be. Yeah, I think what we have, so the way we've broken this 00:25:07.300 --> 00:25:11.380 out, right, is because we want, you know, code to be reusable across platforms, right? 00:25:11.700 --> 00:25:15.460 But it may not necessarily work quite the same. Let's say for pass keys, 00:25:15.700 --> 00:25:19.600 you know, or autofill, like, that happens completely differently on iOS than 00:25:19.600 --> 00:25:23.280 it does on Android than it does on, you know, Windows or wherever. 00:25:23.440 --> 00:25:24.960 And so there's all these different implementations. 00:25:25.420 --> 00:25:29.820 But you want to do the same process. It's just that all the underlying calls, 00:25:30.040 --> 00:25:33.240 you know, there may be syscalls or things like that, we reaching back out in 00:25:33.240 --> 00:25:34.320 the OS, they work different. 00:25:34.500 --> 00:25:37.480 Or, you know, some of them, you have to do it in the moment, 00:25:37.640 --> 00:25:41.060 some of them, you have to seed some operation at unlock, you know, or whatever. 00:25:41.220 --> 00:25:45.820 And so what we try to do is we have these, you know, we have FFIs by platform. 00:25:46.120 --> 00:25:51.580 And then we have like an app level, where you could have multiple platforms 00:25:51.580 --> 00:25:54.200 that use the same app level crate. 00:25:54.460 --> 00:25:58.060 But then what that does, that reaches out to services. And the service level 00:25:58.060 --> 00:26:01.220 is where all of your actual functionality comes in. 00:26:01.300 --> 00:26:04.840