The Changelog: Software Development, Open Source - 1Password is all in on its web stack (Interview)

Episode Date: November 12, 2021

This week we're bringing JS Party to The Changelog — Mitch and Andrew from the 1Password team talk with Amal and Nick about the company’s transition to Electron and web technologies, and how the company utilized its existing web stack to shape the future of its desktop experience.

What's up? This week, we're bringing JS Party back to the changelog. ML Hussain and Nick Neesey had an awesome conversation with Mitchell Cohen and Andrew Baer from the 1Password team. They talked about the company's transition to Electron and web technologies, how they pushed back on the idea of what native apps are on macOS, and how they utilized their existing web stack to shape the future for their desktop experience. Big thanks to our partners, Linode Fastly and LaunchDarkly.

We love Linode. They keep it fast and simple. Get 100% credit at linode.com slash changelog. Our bandwidth is provided by Fastly. Learn more at fastly.com. And get your feature flags powered by LaunchDarkly. Get a demo at launchdarkly.com. This episode is brought to you by our friends at Fly. Fly lets you deploy your apps and databases close to your users in minutes.

You can run your Ruby, Go, Node, Deno, Python, or Elixir app and databases all over the world. No ops required. Fly's vision is that all apps should run close to their users. They have generous free tiers for most services, so you can easily prove to yourself and your team that the Fly platform has everything you need to run your app globally. Learn more at fly.io slash changelog and check out the speedrun and their excellent docs. Again, fly.io slash changelog or check the show notes for links. Thanks. This is JS Party, a weekly celebration of JavaScript in the web. Tune in live on Thursdays at 1 p.m. Eastern, 10 a.m. Pacific.

Watch the show live on YouTube at youtube.com slash changelog or subscribe at jsparty.fm. All right, y'all. It's party time. Hello, party people. Welcome to JS Party. I'm your host this week, Nick Nisi. Ahoy hoy. And with me as semi-regularly always is Amel.

Amel, how's it going? Hi, everybody. Happy to be here. Excited to learn about passwords. Password. Got to get rid of a lot of password and passwords in general. That means I got to get rid of a lot of Post-its in my house. Send them my way. But to talk about passwords and specifically a singular password or one password, we have some members of the one password team here. First off, we have some members of the 1Password team here. First off, we have Mitch Cohen. Mitch, how's it going? Hey, it's going awesome. Thanks, guys.

Welcome. We're excited to have you. And with us as well is Andrew Beyer. Andrew, how's it going? Hi, I'm Andrew. I'm here to party. You got to tone that down. I'm sorry. Okay, I got to tone it down. Despite the party in our name, we're very serious. I see, I see. No, no, we love to have a

good time. And we're very excited to have a good time with you talking about passwords and specifically 1Password and the product that you work on. It's a product that I have used, I think, since I got a Mac, probably in 2008. I don't know if the company's been around that long, but around that time. And it's been the holder of my deepest secrets for a long time. So really excited to talk to you about 1Password and where we're going. And I guess we have to start it off with why you're here on a JS party JavaScript podcast talking about 1Password, which has traditionally been the Mac and iOS app that I know and love. So why are you here talking about it on a JS podcast? We made a new version of our app, which we do every once in a while.

And when we do that, a lot of people want to talk about it. And sometimes the reasons people want to talk about it are different from why they wanted to talk about it last time. And I think that is the part that's most relevant to your question. Well, actually, before we get into OnePass, can we just do a little intros? Mitch and Andrew, like, what are your roles on the team? And like, what do y'all do or not do? Totally.

So we're both kind of old hats. I've been at 1Pass right now for seven and a half years, back when it was just a handful of people. I knew them all by name. And I joined actually as customer support and kind of had a whole mini career at 1Password. And I'm now a product director. And I've been through the highs, the lows, the fun parts, the crazy parts. And I'm just so excited to be here to talk about yet another interesting chapter in the life of 1Password.

That's so cool. You know, like people who come with a customer support background, they make like the best engineers and product people. So you must be really, really good at your job because you have that heavy user empathy. Apparently, this story happens a lot, by the way. We have a ton of people who joined to do support and then took on roles in the company. And that's actually true for Andrew Beyer as well. I'm Andrew Beyer. I've been here at 1Password almost five years. I actually come from a background.

I spent almost a decade in the United States Army working on communication security and some air and missile defense. And I joined 1Password for two reasons. One was I had been using the app. I've been using 1Password for like 13 years now, I think 13, 14 years. I kind of lost track at this point. So I really wanted to work at this company where I really did enjoy the product. It was super useful to me when I was in the military. You know, you deploy overseas, you'd have to use some public computer, and I couldn't install apps or anything.

So I had my, I don't know, like iPhone 3GS or iPhone 4 or something with the 1Password app running on it, and I would be able to get my password and actually use the internet. But I joined 1Password because I love the product. And I was at the time looking for a remote job. I know now like everybody like just knows what remote work is like, but I wanted to do the digital nomad lifestyle. And I had gotten sick of not moving around in civilian life. So I was like, Oh, I'll join this company. I'll be able to travel the world, which didn't quite pan out the way I wanted.

But working at 1Password has been really awesome. Currently, I am in charge of our browser experience engineering organization. So ultimately, I'm in charge of kind of the browser extensions, everything about like filling and saving on the web. So I get to run you know, run the teams that deal with all of the web developers out there who want to make login forms and credit card forms differently. And then we're starting to expand some of that reach into kind of like our web client as well. So how you use one password, like as a web client. So do you find that web developers are just finding fantastic ways to break your work?

Yeah, we used to joke around that there's only a couple quote-unquote bad web developers, and they just jump from company to company and copy and paste their login forms and put it somewhere else. But to be honest, you'd be surprised. Even in the five years I've been here, the web standard and web design and a lot of like web technologies have gotten so much better. So like nowadays, there's HTML autofill attributes that like help password managers and help your browser understand more about your form. And I'd be happy to teach a

class or talk about that more. But I know that's not quite the reason why we came today. So. So cool. So yeah, so before we kind of get into some of the changes around one password, and you've made some exciting architecture changes, like moving to electron, which is like a chromium node, you know, kind of desktop app support system. I don't even know how I could describe electron in a sentence. But before we get into that, can you explain to us a little bit about how one password works? Like, what is it exactly? How is it secure? You know, how do you guys protect yourselves from data breaches, right? Because if you're the company that has everybody's passwords, like, how is that? How does that even work in terms of your security management? But

yeah, so if you could give us a little overview, that would be awesome. Absolutely. So at its heart, 1Password is a password manager. And it's since grown to become kind of like an everything manager, like anything you need to keep secret, you need to keep safe, you can put in 1Password and trust that it'll be safe there. And in the past few years, it's expanded to become actually sort of a collaborative version of that. So not only can you keep your secrets in there, you can also share them securely with other people who need access to them. And that's been a major focus of us as we've sort of grown out the product. And the thing that keeps it safe is something that's actually been in the news a lot lately, which is this concept of end-to-end encryption, where regardless of who we are or our relationship to you, we don't have

access to the secrets you put in 1Password. We don't even have access to the security keys you would use to get access to those secrets. And as long as that remains true, effectively, you can't attack 1Password to be able to get access to the data that people keep in 1Password. And we're very proud of that. And that's been fundamental to everything we've built for decades now. And it will be going forward as well. That is so cool. Yeah. decades now, and it will be going forward as well. That is so cool. Yeah, the story I like to tell is a lot of people assume, you know, you go to 1Password and you sign up for an account, you're

entering your password into this website, and they assume like, obviously 1Password has that, right? And that is where we, years ago, fully embraced web technologies. And with the advent of web cryptography and web crypto APIs, we can actually download you a little JavaScript client right there on the web. When you create your account signup, we never actually send that password across the internet ever. It's always stays on your device. We provision those crypto keys. They live on your device. And from there on throughout your one password journey, you're always using your kind of secret key and your account password to do what we call secret, secret key derivation, or two key derivation. And we basically kind of make the

unlock keys for your account. So I think that's like one of the really cool aspects is we're so ingrained into the web, but you never have to send us any of your secrets, you only ever send us the kind of encrypted blobs for the secrets that you hold on your side. Yeah. So everything is always encrypted going to the, like if you're using like the family plan or things like that, it's always encrypted and you have to decrypt it locally, whether that's with the client or in the browser. Yep. A hundred percent. Yeah. And when you mentioned the family plan, what's remarkable about that is you can have transactions

between two family members where they're able to share with each other, but we have no insight into what they're sharing and no ability to access it. And it's kind of challenging to set up that environment, but we figured it out several years ago. And honestly, it's industry leading. Very few others can say that they have this kind of sharing system that's so secure. Wow. Yep.

And it's all thanks to private public key encryption. You know, we basically provision these vaults. They all have separate keys. And then from their family member from their own device can essentially ensure other family members have access. So, yeah, along the entire way, essentially, it's encryption all the way down, which is really cool. That's super cool. And so is this architecture, and the keys are unique by device, right? So even if like, I'm one person with two devices, I'm using different keys. Like, how does that work, actually, if I'm using the same account across multiple devices?

The keys to unlock your account, or essentially what we call the master unlock key, easily named, is unique to you, right? It is unique to you and your account. So your account password and your secret key derives the master unlock key. And from there, it's just a whole hoist of other keys, right? So you'll have a key per vault and those kind of things. They aren't unique to device. So when you have two different devices, you're using the same secret key and those kinds of things. They aren't unique to device. So when you have two different devices, you're using the same secret key and your same account password.

And that's essentially how we ensure the end to end encryption there. We do offer kind of some authentication on top of that. So like every device has a unique identifier and we use that just for the server to know the devices out there that it can download the encrypted blobs of your like one password items to and we can do things like multi-factor authentication that way where you're doing the base kind of authentication is all done through encryption but if you want to add on another layer you can add on like ubkey or time-based one-time password. And that's where

like that device UUID will on the server, it can perform that MFA. And really the only protection that adds is if someone were to obtain your master unlock key or your account password and secret key, they can't use that on a new device to download your encrypted information. So it does add kind of a different layer of making sure that nobody can add to remove from your account, download your account on new devices. That is so cool. And I'm assuming that this is like architecture pattern has probably replicated across other password managers. But one pass were like the first major player in the space from my understanding. I don't think any of it's fully replicated across anywhere else I've seen. We do

document it. It's in our white paper. So people are free to take a look at the whole architecture. But we're really pioneering in so many areas here, especially over the past few years with our sharing features. And honestly, like where we'll be a year from now, and I know we're going to get to that later is even more exciting than what we're able to talk about now. That is one piece of advice is if you aren't using one password, and you're looking at other one password managers, you really do need to dig into the implementation details, right? Like most people don't care about implementation details on stuff. But when it's something where you're relying on it for your entire security of

your life, you really do need to dig in and find out like, how are they doing this? Because obviously, the worst case scenario is they're just some database running somewhere with all of your passwords in it in plain text, right? And then there's varying levels of security from there. That makes a lot of sense. And so we honestly could talk about that one topic for the whole show. But we're kind of here to talk about stuff that's changing. So what's changing in 1Password? And I think we kind of alluded to that a little bit with Electron. And so kind of, can you tell us about like, what prompted that change? Why Electron? Sure. So we're releasing a new set of desktop apps, when we're calling them 1Password 8, because the previous version was 7. And we did something that probably you should never do, but we did anyway, which is

that we wrote all our apps from scratch, starting from the very foundation. We picked our tech stacks, sort of clean slate. We wrote all the logic, all the user interfaces, built all the features, and ended up to a point where we had something that was just way cooler and more performant and even more secure than what we had in the past. And when we were ready to share with the world, we announced it actually in early access. And the reason we did that was because when you are trying to recreate an app that's been around for over a decade, it's going to take a while to make sure you've met sort of every user workflow. Even though you have really cool new workflows that you're excited about, you want to make sure that users can install it and continue on with their work because 1Password is so important to their lives. So that's exactly what we did. We

sort of built our new tech stack into these apps and announced them for early access. And that's where a lot of the interest has been. And to that end, what was it before? Now, like my experience has only ever been on Mac and iOS devices, but 1Password has existed on other platforms as well, like Windows and elsewhere. Were those all just separate native apps for the previous version? They were a hodgepodge of different things. And I mean, that's true about any sufficiently large piece of software. You end up with all sorts of bits and pieces built over the course of years, kind of connected together. But one issue was that they all felt very different. So the way I started to think about it was it almost felt like someone was making like third party

fan clients for our service, even though we were the ones making them. And definitely that was something on our minds when we set out to build our new tech stack. And of course, our new design language and features that accompanied that tech stack. But the other interesting thing about them is that they also all had web technologies in them. And we always have used web technologies heavily and pioneered them. So as Andrew already alluded to, we used web crypto very early on to power our web service and to make sharing possible over the web. But even on the desktop apps and mobile apps, we had web views, we had web-based integrations. And in fact, the most important part of our desktop app, which people interact with every day, has always been web-based and

very heavily so. And that, of course, is the browser extension. So it's interesting to see people think of what we're doing as sort of like a move or a shift when really it's just taking something we've always cared about deeply and continuing to use it in our product for the things that appeal to us about it. I can see that perspective, though, because I definitely when you say that 90% of my interaction with 1Password is through the browser extensions and command slash to open that up. I guess I just don't ever think about it as like, well, it's really just this thing. And I'm never really opening up one password proper unless I'm like doing more in depth, like searching or things like that. But it's usually like most of it is just straight through that web thing. And it's just when I thought about that, I never really, it never really came to my mind that that was my primary interaction with it. And that's a great observation, because it's something we both noticed and heard ourselves that people were saying,

the part of 1Password that I actually use is the part in my web browser. And we both, that informed what we're doing with 1Password 8, first of all, because we wanted to bring some of what made the browser experience so special sort of into the rest of our app. But we also want to move faster so that we can give you a reason to open that desktop app more often, because we think that is a great place to organize, to share, to understand sort of your security. And if people are only opening it to troubleshoot, well, we have to do better there. So one thing we're very excited about with 8 is actually making it so that you do interact with all of our service and our apps, not just sort of the command backslash,

as useful as it is. So that's really on our minds. How so? Like, how would that change my usage of going to a site and wanting it to auto-populate? And how would it bring in the desktop version? So one example is we actually have a new dashboard for our Watchtower service in the desktop version? So one example is we actually have a new dashboard for our watchtower service in the desktop app that shows you sort of your security situation as a whole, which is

something we didn't have before. Now you can see exactly what passwords you need to go fix. And the interface sort of helps you understand that and make progress there. And that's something that of course is more fit for a desktop app. Whereas the browser is very good at helping you use your passwords. We want to give you ways to also sort of organize and work on your security situation. So that's one example. Another would be our sharing features, which, again, the desktop app is a natural place to have sharing, both the ability to share and also to understand what information is being shared with whom. And a lot more of that is now exposed in the new desktop apps than was before.

Nice. Okay. That makes sense. Cause I was actually, I did download the early access and was like comparing it to the old version. And I was like, oh, this watchtower thing is cool. Where did, I thought that there was that in the old app, but there wasn't.

And I really liked that dashboard a lot. I only have six terrible passwords by the way. So. Well, that's fantastic. And that's funny too, because we've had several people point out things that they don't like about the new app that weren't in the old app. So it's always interesting to see how people remember sort of what was there versus what they have now. And in some cases, the grass is always greener.

But we know we have the data. We can do this side by side. And we're specifically focused on improving a lot of the experience in big and small ways. Yeah, and discoverability was a big piece of this project, right? We wanted as part of this, essentially, a complete rewrite of the client app experience, we wanted to make sure that we were building a product that was modern and discoverable in this day and age, right? And we had a lot of problems there, whether you were on a Mac and switch to Windows, or at the time, we didn't even have a Linux client. There were parts of 1Password that felt, looked and acted differently, right? And a lot of that's because of our origin story, right? So

we had two founders that started this company over 15 years ago, they built the first Mac app, and essentially built the company from the ground up that way. And when the time came to add Windows, you know, they just hired someone to write a Windows app, joined the company, started building up a small team, same for Android, started with one person. And we've grown in size of just like the ecosystem, the complexity of one password, adding on memberships and sharing and all of those things where it's no longer just one individual developer adding something to the app that they think is a good idea. And we have a more well thought out design and engineering process now. And a lot

of that comes down to how can you capture those thoughts, have your own design language, and then share that across your entire ecosystem. What's up, friends? This episode is brought to you by our friends at Retool, the low-code platform for developers to build internal tools. Some of the best teams out there trust Retool. Brex, Coinbase, Plaid, DoorDash, LegalGenius, Amazon, Allbirds, Peloton, and so many more. The developers at these teams trust Retool as a platform to build their internal tools, and that means you can too.

It's free to try, so head to retool.com slash changelog. Again, retool.com slash changelog. Again, retool.com slash changelog. All right, y'all. So that was really incredible learning about some of the reasoning behind those decisions, which really, for me, seemed like very obvious at this point, right? You've had, you've seen successful platforms like Xamarin enable cross-platform development for mobile apps, you know, where you're able to ship to the iOS store and the app store and the Windows store, writing one language.

It's easy for dev teams to kind of have end-to-end ownership of all of your apps. And then, you know, nowadays, Flutter has kind of taken end-to-end ownership of all of your apps. And then, you know, nowadays, Flutter has kind of taken over that industry, maybe the best in class for cross-platform apps, although Flutter web has, like, failed pretty hard, thank God. So, and obviously we've seen Electron, you know,

over the past, like, decade just really kind of take off and really push forward what you can do with the web across desktop apps, Linux included, which is great, right? But I'm curious, like, there's still this gap of like, browser extensions, right? Where like, you're still writing something for Chrome, for Mozilla for, you know, so you're still writing these different things. And then also, like the security around browser extensions is quite horrible. The ecosystem is quite sketchy to say the least. And I'm just curious, like, what's that like for y'all having to kind of navigate in this like murky waters? And also, how do you trust other extensions that are on your users browser, right? Like,

in terms of snooping and whatever else that they're constantly fixing security holes. So I'm just curious how y'all dealing with that. Because there's still fragmentation. And there's also bad security, right? That is a lot of questions in one question. So I will, I will try to start at the beginning. And you let me know which ones I don't answer. So browser extension, great example. And it's actually the origin story for one password eight. So a few years ago, I want to say a few friends got together. And this is when Mitch and I actually worked as developers directly together. And we started, we rewrote our browser extension, right?

With a lot of different goals in mind. But one of the really important goals was we wanted a browser extension that could work without a natively installed application on the machine. And there's a lot of reasons for that. One, at the time, we had no Linux app, right? So that was a part of the market where like, I've been using Linux since like yellow dog on my original iMac, whether I'm using Linux now, or not, I always wanted one password on Linux, right? And this was a really easy way to make something that would run on Linux immediately. The other thing is you have this thing called like Chrome OS, which is the

system. It runs Android apps sometimes, but it's another place where a lot of things are done on the web. They're done within Chrome. It's a great place where you want a web extension or a browser extension that doesn't need, you know, a Mac app running or something like that, right? That is kind of our starting point of where we built something that was a web based one password client, it can run completely by itself inside of your browser. And it has a React app front end. And all of this is done in TypeScript, because we get a little scared of JavaScript. I don't honestly understand people who don't use Type is done in TypeScript because we get a little scared of JavaScript. I don't honestly understand people who don't use TypeScript.

Like TypeScript is freaking awesome, especially in this day and age. You hear that, Jared? With browsers just constantly evolving and JavaScript platforms and all of that. Holy cow. TypeScript's awesome. So that's kind of like what we at the time branded as 1PasswordX. We did that because we had two browser extensions. Now with the 1Password8 transition, this is the browser extension.

And what's awesome about it is it really is better for your everyday user. Like Nick said, 90% of his time is done in the browser. I would say as a new 1Password user, probably like about 100% of your time should be done in the browser, right? You go install one password. All you really need is the browser extension to start saving and filling logins, generating passwords with our smart password generator, those kinds of things, right? Once you get more than three of these things, you know, or 10 or 20 or 50 of them, you want to start sharing them. You want to start managing them in different ways. You want to start adding new, different and exciting item types.

That's where it really makes sense to like download the app, start digging deeper into 1Password. And so that was kind of the goal of the browser extension and why it's so like important to 1Password. The cross-platform thing, I will push back on a little bit and say that's getting better. It started with Google. They created this thing called Web Extensions. It's not an official platform API. And then Mozilla finally kind of converted over Firefox.

Edge, for a while, were working on this Web Extensions API. What was a real shocker to us was Safari always had this thing called an app extension. And two years ago, they actually launched support for the same Web Extensions API. And then one year, well, actually, like three months ago, they launched support for the Web Extension API on iOS and iPadOS, which, I don't know, is like a billion plus devices. So like Apple is actually heavily invested in. We're going to support this Web Extension API technology. So I will push back and say, like, it's not 100% standard across the board, like everything on the web is. But essentially, if you can write something in JavaScript, if you can learn and use the web extension API, you can actually build a web extension or browser

extension that works in all of the major browsers, right? Like pretty much everything is Chromium nowadays, then you have Firefox, then you have have Safari and it will work everywhere. You know, there's a lot of caveats to that where like, okay, Safari supports this. You got to package it into a Mac OS app and ship it on the Mac app store. Like there's all sorts of like distribution issues, right? So for example, for 1Password, we have to work with Google to distribute our browser extension. We have to work with Mozilla to distribute our browser extension. We work with Microsoft to distribute our browser extension. We have to work with Mozilla to distribute our browser extension. We work with Microsoft to distribute our browser extension, and we work with Apple. So it's like pretty much all of the major companies, right? So like, it's not as easy as like, I just put up, you know, I have DNS and a domain name. And now I have a

website, like you do have to do a lot of work to get there. But there is the standardization of the ecosystem for browser extensions. And honestly, it's really good for us. And it's really good for anybody who wants to build an application that will run everywhere, right? Yeah. There's not a lot of apps out there that can say that, right? Like it will run on Chrome OS even.

So I think it is getting better. Security wise, you are correct. Web extensions, browser extensions, they have a ton of power inside of the browser. So this is managed by way of a permission system. So when you install a browser extension, it will basically tell you, here's the creepy permissions that your browser extension will have. But it's not language that users...

Nobody reads that. Yeah, nobody reads that. And it's not really... Also, incognito mode is another thing that's scary. It's like sometimes there's the listening in incognito mode is another thing that's scary. Sometimes there's the listening in incognito mode, unless you explicitly tell them not to, or you have to explicitly disable some things is, we don't. We essentially, our company policy is, you're not allowed to use any browser extension that we don't use. And the reason for that is because it is a very scary ecosystem. You install one of these things,

and it could essentially be scraping every website you go to and throwing that up on a server somewhere. So you have to be extremely careful in what browser extensions you use. And you have to trust the company that is creating them right so we've we've been essentially creating browser extensions since before there were browser extensions so dave and rustam are our founders before browsers well they would actually swizzle safari and inject some creepy code that was legit into your browser to make one password work in safari right

and safari saw that and they're like we need to add something to like not get people to go down this road right and so my friend rustam actually demoed like the very first version of one password as an extension at like wwdc i don't know like 20 i don't know 10 or something or 25 I don't know, like 20, I don't know, 10 or something or 25. I don't know. It like back before I even like worked in development that much. But to be honest, like browser extensions are super scary. I don't use a ton of them. I'm very careful with them. I use different browsers or different Chrome profiles. If I do need to use an extension that I don't trust as much. Right. But I am happy to say, like, this is a known problem and people are working on it. So Apple and Google are chairing

a new W3C community group for web extensions. And Google is pushing this new, what they call Manifest V3 changes, which do dial back some of the permissions. And they really changed the overall architecture

to browser extensions. And so Apple is also co-chairing that. And if anybody listening to this podcast or watching live is interested, like we need more people to join that group. That is one of the ways like 1Password has a whole bunch of people in there, but we need a diverse community helping to drive the next like revision of the standard, both in like diversity and people, but also diversity and markets and engineers and that kind of thing. Right? Yeah. What's it called? Is there a link to the is there like a link to the group and stuff like that? Yeah, I can post it in the chat. But

you can also just kind of go on w3c.org. There's a GitHub repo, and there is to go read the charter and open issues. But also there's a community that you can go join and they meet bi-weekly and essentially are like it's new right like within the last couple months new but that is kind of gonna be in my opinion a year or two from now that will be like a really solid web standard right like you basically have apple and google behind it you know mozilla's participating as well and then there's people from your favorite ad blocker companies, your favorite password manager companies, like we're all trying to come together as a community, all the security nerds and drive a standard that works for us, but also helps make the end user more secure. The web a better place. Yeah, yeah, yeah, yeah, no, totally. That's amazing. And yeah, kudos to Google for doing that. I mean, they're so great at, I think, pushing standards forward.

And I think nerd herding, similar kind of initiative happened with DevTools. But DevTools and Chromium were kind of developed as like an interfaceable API such that you can connect with DevTools, you know, in VS Code and you can have that same protocol in Edge. And, you know, and so it's really great to see things like that kind of get standardized, you know, things that are kind of outside of the box that we typically interact with,

like in the browser, but that's awesome. So I think maybe my last kind of question on this is really like now that you've done this shift to cross-platform and, you know, you're able to, I'm sure, leverage your own abstractions to manage a sane code base for all these different extensions, right? Because you can write your own abstractions. But I'm curious, how has your development cycle changed

now that you are basically shipping in one language, one stack across all these platforms? Are you still supporting the old stuff, quote-unquote, right? That all the native apps, you have to retrain your dev teams. I'm sure there's a ton of velocity that you've gained, but I'm just, I'd love to hear about this from your own mouths, I guess. So I want to push back on this idea of native apps because it comes up in every conversation these days. We've done a ton of research, a ton of interviews, and to the normal person who doesn't

watch this show and isn't part of our Twitter tech community, a native app is an app that has like an icon on your dock that has like keyboard shortcuts that you can download and install on your computer. And a preferences panel that opens up on its own window, right? We're building that and we're building that in a big way and we're building it for every platform we support. And I mean, like we're going deep into platform features.

So we're doing things on Linux that no one's ever done before. For instance, having biometrics and browser extension integration and integration with the system keychain. The Linux community has been really grateful and appreciative of that. Me too, because I love Linux.

And on Mac, I can go into detail forever. There is a ton of native code in this app and native integrations from support for Touch ID to apple watch to all the keyboard shortcuts you can think of to text transformations to interaction with the system clipboard for secure copy and paste to the universal clipboard sharing setting it just it goes on and on and we're always going to do that because the app isn't very useful if it doesn't integrate well with with your computer But the buttons are not NS button.

And that's where I'm just, I don't really care anymore. I just, I want to build a great product with great features. And I think that's true for all of us. So that's basically what we're doing. Yeah, I think that that's a really good vision to have, right? You care more about the result than how you got there. And I do too. All of those features that you listed, those are the things that I absolutely love about 1Password. And if this changed to somehow not let me use Touch ID or like the Apple Watch to unlock and things like that, then it would be a big step backward. But it's not because it does support that. And kind of shifting a little bit, I want to talk about the technology and actually getting into the weeds a little bit about that. And so kind of to tie this up, I'm curious, are the browser extensions, are they still

going to be fundamentally the same code base going forward? And did the new Electron-style native app, did that get born out of the original 1PasswordX code? Or how did that happen? It's a bit of both, actually. We have some of the heritage of the app is 1PasswordX, especially the React components that we share between them. Some of it is actually in code that was originally written

for our older Windows app, which was written in Rust, which is an important foundational element of the new apps. And a lot of it is brand new. So we have such a sort of a huge iceberg of a tech stack behind us that we can sort of pull the pieces that have worked best and then innovate in areas where we haven't had anything before. Your much older Rust app. For some reason, that's just not computing to me. I don't see Rust being old enough to have old apps yet, but that's just me.

Yeah. So 1Password7 for Windows had a ton of Rust code. That team was kind of early adopters into Rust. And they were essentially like, why are you looking at all this other stuff? Like Rust is awesome. Rust got really interesting to us because we were actually doing this cross-platform code thing for quite a while.

And our kind of infrastructure is written in Go. So we were big Go fans. We still are, right? Our infrastructure still is. And for a while, we were writing cross-platform code in Go and using it kind of cross-platform all the way to the browser

using this really cool library called Gopher.js, which will transpile your Go code into JavaScript. It has some ramifications there, which is you get an entire Go runtime, garbage collector, all of that running in JavaScript. is you get an entire Go runtime, garbage collector, all of that running in JavaScript. So you get a fairly large bundle, but it does work. And as like a browser extension where you're not loading it on the web, you're kind of downloading it maybe once a week or once a month. The gopher.js approach kind of worked for us for a while,

but we ran into those like performance limitations. And so that's why we really looked heavily into Rust is because they had, and probably still do, I don't want to get into any debates about it, but they had a really incredible WebAssembly tool chain and folks working on WebAssembly support. And so a lot of the code that you see running natively in 1Password8 from things like how we compute time-based one-time passwords, how we generate your passwords. All of that code, even in our browser extension, isn't actually run in JavaScript. It is Rust running natively on your system, in the case of the Mac and Windows apps and Linux, or it is Rust code that's compiled to WebAssembly and used

within our browser extension. And that is one of the ways that we have this whole new, like, write it once, use it everywhere mentality, or the way we look at it as kind of project managers and developers is all of your bugs existed, like one one area of code, right? Like, so if there's a bug in one of these things, whether it be URL parsing, any of this back end business logic of the apps, it's going to be in one place, no matter where you find it in the apps. And so we're very heavy backend in Rust to WebAssembly for the web, but we're very heavy frontend in languages

like TypeScript and frameworks like React. We even use Svelte from time to time when it's interesting. So for example, our in-page suggestions, we needed a really fast JavaScript solution there to draw a menu on the page. And so that's written in Svelte from time to time when it's interesting. So for example, our in-page suggestions, we needed a really fast JavaScript solution there to draw a menu on the page. And so that's written in Svelte. So we kind of toy and play around with pretty much every possible solution. And then that's one of the reasons why the native, the desktop apps landed on Electron was we looked at every framework. We tried everything and Electron just happens to be the industry standard and the best. Like we went from basically almost in a single night.

Well, maybe it was like two nights. The very first version of like 1Password 8. We took some React components. We took some of our backend code. We threw it in an Electron and we had like a desktop app in it. It was ugly. I wish I had a screenshot of it, But it worked like in basically a day. And that is that is what's really amazing about it. The funny thing about electron is it's actually

the most boring part. And I know everyone wants to talk about it, but there's not much to it. It's effectively a glorified packaging format, right? It just takes a web front end and a native back end and connects them. And actually, in our case, we're connecting them with a really nice tool called neon, which has done a lot for us. And if you do want to use Rust inside of an Electron app, I strongly recommend checking out the Neon project. But there's not much to say about Electron itself. I'm sure something eventually will come along that does what it does better or makes a more compelling case. But until that happens, there's not much use to be gained out of railing against Electron on the internet. You're not going to get much from the development community. It's pretty much like you're a unified client

and you ship a bunch of different binaries with it like that are native. Is that right? Like I'm just trying to understand what's it like hooking into that because there's node is supported by default, right? What are you using to kind of connect that node layer to run your binaries? Because are you using C++ or is that like where the Rust core comes in? Like, I'm just really curious to understand that architecture. It's a little fuzzy in my brain right now. So that's what I was just referring to, which is we write our code in Rust and actually compile it to your system. So not just to native code, but to architecture specific native code.

So, for instance, if you you took our Mac Electron app, you couldn't take the resources and run them, never mind on Windows, you couldn't even run them on an Intel Mac because it's compiled to native Apple Silicon machine code. And it's very fast, by the way. And we hook that up to the front end with the Neon project, which basically exposes an FFI, a foreign function interface, to allow JavaScript to talk to Rust.

And it's nice. It's a nice developer experience. It kind of lets us get past that part, right, and focus on the app and what we want it to do. So it's good. Yeah, and then the cool thing about this architecture, and one of the reasons why I would advocate looking at web technologies, is if you write your front-end in a web technology, like not only can

you use it in the browser, but a lot of these cross platform frameworks and utilities and packaging and all that stuff will essentially support this stuff going forward, right? So we're not really coupled to Electron in any way. It's the smartest way to package and ship the app today, but it probably won't be in five, 10 years. Who knows, right? Like, we're actually funding a couple projects to see if one day we can do this all in native system web views and those kind of things, right? We're actually very interested in driving this approach of like, right across platform app using web technologies, because it's awesome. You get to dictate your own design language. I don't know if anybody's been paying attention, but like CSS and JavaScript has gotten really freaking good in the last five, 10 years. Like it's a whole different world from when I was trying to write

websites back, you know, 20 years ago. It's a really awesome technology stack to work with. And it's very developer friendly, I would say. Yeah. I was going to ask about the choice to go with TypeScript there. Was that an easy choice or was there some kicking and pulling? Always looking for a TypeScript angle, Nick, you know. That was the easiest choice we've ever made as a company. Yeah. I've had a dollar for every time I heard that question from Nick, you know. It's pretty funny.

Like Mitch used to toy with me. He'd be like, once you need TypeScript, you can use TypeScript. When we would like start a little project or whatever in JavaScript. But honestly, even now in like my side projects, everything I do in JavaScript, I start with TypeScript. It is amazing tooling for what you get, just even the compiling it to run on different platforms and that kind of thing. It's really awesome. This episode is brought to you by Sourcegraph. Sourcegraph is universal code search that lets you move fast, even in big code bases. Here's CTO and co-founder Byung-Loo explaining the problems that Sourcegraph solves for software teams. Yeah, so at a high level, the problems that Sourcegraph solves, it's this problem of, for any given developer, there's kind of two types of code in the world, roughly speaking.

There's the code that you wrote and understand, like the back of your hand. And then there's the code that some idiot out there wrote. Or, you know, alternatively, if you don't like the term idiot, it's the code that some inscrutable genius wrote and that you're trying to understand. And oftentimes that inscrutable genius is like you from, you know, a year ago. And you're going back and trying to make heads or tails of what's going on. And really, Sourcegraph is about making that code that some idiot or inscrutable genius wrote feel more like the code that you wrote and understand kind of intuitively. It's all about helping you grok all the code that's out there, all the code that's in your organization, all the code that is relevant to you in open source,

all the code that you need to understand in order to do your job, which is to build the feature, write the new code, fix the bug, et cetera. All right. Learn how Sourcegraph can help your team at info.sourcegraph.com slash changelog. Again, info.sourcegraph.com slash changelog. Again, info.sourcegraph.com slash changelog. And by our friends at FireHydrant. FireHydrant is the reliability platform for teams of all sizes. With FireHydrant, teams achieve reliability at scale by enabling speed and consistency

from a service deployment to an unexpected outage. Here's the thing. When your team learns from an incident, you can codify those learnings into repeatable automated runbooks. And these runbooks can create a Slack incident channel, notify particular team members, create tickets, schedule a Zoom meeting, execute a script or send a web hook. Here's how it works.

Your app goes down, an alert gets sent to a specific Slack channel, which can then be turned into an incident. That will trigger a workflow you've created already in a runbook, a pinned message inside Slack already in a runbook, a pinned message inside Slack will show all the details, the JIRA or clubhouse ticket, the Zoom meeting, and all of this is contained in your dedicated incident channel that everyone on the team pays attention to. Now you're spending less time thinking about what to do next and

you're getting to work actually resolving the issue faster. What would normally be manual tickets across the entire spectrum of responding to an incident can now be automated in every single way with FireHydrant. And here's the best part. You can try it free for 14 days. You get access to every single feature, no credit card required at all. That way you can prove to yourself and your team that this works for you. Get started at FireHydrant.io. Again, FireHhydrant.io. Again, firehydrant.io. So let's dive deeper into this, the architecture a little bit and kind of the native and web interface, like how, where those two meet. And I want to dig and understand a little bit more about how, how it all kind of works together and why, why it's the best decision for 1Password. I think the question we're, we're looking for is like the architecture.

And this is, I'll be honest, one of the places where I think we as 1Password probably didn't have the best messaging out the gate, right? When we first launched 1Password 8. Because we did go heavily into the architecture, which is, look, a lot of your app is running native. And that is true. The vast majority of your app is either native code running in the backend, all the business logic,

or we have a ton of Swift and native API code tying stuff together, right? I'm not 100%. I'm still waiting to see, is there another Electron app that does unlocking with Apple Watch? We might be the only ones. I haven't found another one. But we spent a heck of a lot of effort into actually making our Mac app as good in 1Password8 as 1Password7. And unfortunately, I think one of the messaging approaches we had was to talk about

that, right? We were really proud of that, and we still are, are obviously but what people see between electron and something that's written in app kit or swift ui is a lot of times they're they're kind of looking at like the mac native ui right mac native ui is really the when i click into like a drop down menu does it look like the drop down menu on other parts of my system. And the truth of the matter is you can actually do a lot of that stuff in Electron. Like one of the things you brought up was the permissions dialogue not being in a separate window. We actually at one point had the app do that. Like that is something you can absolutely do. That's not an Electron feature or a problem with Electron that prevents you from having multiple windows. We made a conscious design choice to bring kind of like the one password design language

into these new apps. And so in a lot of places where it didn't make sense to use kind of native UI for your system, whether it be for consistency, for things like when you switch platforms, consistency and support documentation, just all of those kind of reasons. And we think that we've developed an incredible looking one password design language, a feel

and look and feel to it, where whether you're using a desktop app, whether you're going on to a web client, whether you're using our browser extension, you're going to get the same exact experience. And that is where web technologies really help us. What do you have to add to that, Mitch? So a lot of this conversation has been about what Mac users expect. And it's always like a hypothetical Mac user, right? So people will tell us this is what Mac users expect.

It's interesting to me. First of all, I've been a Mac user for as long or longer than the people telling me this. And I know what I expect. I know lots of Mac users. Wait, are you Steve Jobs? You know, you guys might have been inventing browser extensions before browsers. You've been using Macs since before Macs.

I mean, you know, just be like Steve reincarnated. He may or may not have a Lisa in that room. Oh, nice. I actually have an Apple Lisa sitting in my desk over there. You can see it on the screen. Oh, M-J. That belongs in a museum. That's incredible.

It doesn't turn on. I'm still working on it. That's cool. Yeah. The wonderful thing about Steve Jobs, by the way, is that he was not nostalgic, which is...

Well, I think you just go to his grave and get like a drop of his blood or a piece of his hair and it'll turn on, you know? I'm just kidding. All right, I'll stop now. I love the Mac. I love the platform. I love every Mac that comes out. I'm sitting here on this wonderful M1 MacBook Air. It's the best computer I've ever had. And the Mac has succeeded beyond where it was, vastly beyond where it was when I joined this company, when we were making just a Mac app.

And that's wonderful. And when you look at people who use Macs today, they're not part of that community that wanted like a very specific kind of Mac app. They're just normal everyday people, right? You go to a Starbucks, a college campus, you just look at your friends, family and co workers, and they love their Macs. But you look at the software they're using, and it's normal software, right? It's cross platform software,-based, a lot of times just inside of a web browser. And they don't really think about it that way. They don't ask for apps that look like Apple made them in the 90s, the way that I think a lot of people kind of want us to go back and do that. And regardless of what technology we use, we're not going to do that. We're going to

make an app that looks and feels like the experience that we want, just like every other developer effectively is doing in 2021. I mean, really, you look at the apps that come out nowadays, they have their own very strong branding, their own design language, their own user interface. And that's just kind of what people expect. I actually think that for the average college student, for instance, who uses a Mac, they'll think of something like Discord or Slack or Notion and say, that's what a Mac app looks like. That's how it works. They're not going to point to these apps that came out decades ago that sort of are the standard bear came from when I'm thinking about how our app should look, how it should work, and what its relationship is to the host platform, which is macOS in this case. Yeah. How challenging is it to work for or on a platform that is so

closed in many ways, right? Like in terms of community feedback and having your input actually heard and having an opportunity, you know, like it's a very different company than Google and Microsoft, right? Google being on the like far left, Microsoft being somewhere in the middle and Apple just being far on the right in terms of like community engagement

and, you know, taking people's input and right also the extensibility of the platform is fairly like limited, right? So I'm just curious, like what that's like for you. i think this is almost a different question if you're talking about mac os versus ios mac os i guess but okay i mean i'm not familiar with the differences between the two though so i don't even yeah it's a kind of a hard question to answer because i don't honestly really feel that way especially on the mac right i think that in this day and like, honestly, macOS at the time OS X 10 was like one of the coolest innovations the Mac platform has ever had. And there's a

reason why we're still on that foundation, right? You take something like a homebrew package manager and a terminal, and I don't really feel like I need Linux. I use Apple platforms because I love the ecosystem. They do work really well together, whether it be receiving notifications on your Apple Watch, those kind of things. It sounds silly. And if you're fortunate enough to be able to afford kind of a more expensive ecosystem, right, like that is one of the downsides is a little bit more expensive. But working on Apple products and using Apple products, I think, is very open and inclusive. I don't know how many developers know this, but when you go to WWDC, the Worldwide Developer Conference for Apple, they give developers time with Apple engineers, right? So this last, like three months ago, when we when they announced iOS web extensions, I had three separate sessions with engineers directly working on those APIs.

And we were able to say, hey, here's what we need. Here's the problems we're encountering. Here's what we're working on. And like, you do have a lot of input there. Also, Apple is very open source and open in the community as well, right? Like Swift is open source. WebKit, you can go on there and just file any issue you want. I don't really feel that it's a hostile environment for developers or users, right? I know we hear the horror stories where some high school student reported a bug to Apple via radar and didn't hear anything back. And it was

this huge security issue. Like there's a lot of horror stories, but to be honest, you go on Google's bug tracker and file an issue. There's a good chance you won't, you know, I have issues that have been open for six years over there. You know, it's just the nature of the game and it's, it's part of the prioritization, but I would say it's a great platform to work on and build for. Well, I'm really, I'm so happy to hear that feedback because you know i don't think that it's just not a common sentiment i think outside of people who are doing the day-to-day work because i think a lot of us still have that perception of apple and its closed system and apple is really hostile towards the web apple keeps trying to kill pwas because they want things going through the app store and right so there's

just kind of like apple versus web and Apple versus like open source and ecosystem. Like, you know, we can't even get their developers to come to a conference for God's sake. There is still a level of reservedness, which is there. What I would say is every company changes.

Right. I remember when I was 13, 14 years old running, I mean, I was running like open Suse 7.3 or something back in the day just loving raging on like how microsoft was for the you know like the man has got me down and i gotta go linux but look at microsoft today they own github they are pushing typescript they are just like crushing it in developer relations and i would say apple is probably on that trend as well

you know what i mean like it takes a lot of effort to move a company that big and they have a lot of different challenges both internally and externally in communication wise i'm sure just like we do right but i would say they're on that trend as well and i um there were days when we would say like internet explorer is killing the internet, right. And look at them now. They're just another arguably pretty great chromium browser, um, these days. Right. Yeah. Well, I, I just want to actually hand the mic back to Nick's thinking to cut a point, but, um, I just wanted to say that funny story about internet explorer. A lot of people think that it was like the worst thing for the web, but it actually in many, many ways was like the best thing for the web because it actually pushed the web.

It did its job so well that it's still relevant today. It kind of like went off the track and like really innovated hard. And yeah, it's kind of stuff that's not standardized or whatever, but it's all stuff that really pushed the web forward. And so in that way, like it really actually did its job very well. You really need a villain to push the heroes. Yeah, but it's a perspective that people don't get to really think about often. And I was taught that by a friend of mine

who, you know, was kind of a platform nerd. But yeah, so Nick, you were saying? Yeah, I hear that sentiment about Apple being like that, not necessarily for the Mac, much more so for iOS and like their closed, I'll say closed mindedness on PWAs and things like that. And like just the, the approach to the web and the overall, like the Safari being so far behind and not, not allowing any other browser out there on iOS. I guess that's the bigger, the bigger debate and the bigger controversy with Apple.

Yeah. Everything is WebKit, you know, Firefox on iOS, Edge on iOS, Chrome on iOS. It's all like WebKit underneath. Yeah, but like WebKit is great. We like the browser engine competition, you know? Of course, we don't mind WebKit. Yeah, WebKit's great.

Yeah. I did not know we were going to get into an Apple, Microsoft, Google debate, honestly. So I didn't come prepared for it. But I will say that, like, I mean, I am an iPhone user. I know at certain times there were Android phones that, like, came prepackaged with antivirus and stuff like that. And when it comes to, like, my mobile platforms,

I just want them to work really well. And so some of the closed nature do promote an environment that just, like, it works really well. Don't get me wrong we have spent our fair share of like praying for just our app not to get killed because we go over a ram limit or those kind of things and i really am excited about like that's one of the things that's so exciting about web extensions on ios to me is I saw the other day someone wrote an iOS web extension that allows you to use like developer tools on your iPhone basically or your iPad right

that's something that doesn't actually work natively so you can actually start writing JavaScript there you can manipulate the DOM like the fact that they did that makes me think that Apple is definitely on the track where they understand the status quo and they are willing right like they're willing to allow you to basically write a JavaScript app and run it in Safari on iOS and iPadOS. So I think it's going to be super exciting. I think that's going to actually cause a surge in the market of browser extensions.

Like right now, password managers and ad blockers are kind of like the big ones that everybody knows about, but I'm super excited to see even day one from what I've seen on Twitter, there's a lot of really cool stuff coming out to iPhone because of the fact that they're allowing kind of JavaScript apps to just basically run inside the browser. So it'd be interesting to see how that works. And as we noted security before, it will be interesting to see. I'm sure there will be some sort of level of fallout or something that kind of happens because of that. But I think

Apple is becoming very open to the fact that like, and I think being fairly respectful of the web and a lot of the APIs and the platform APIs. I'm so glad. Great. It's 2021. Glad they're coming to the party. They're not quite here yet, but they're in the cab, you know, so we'll welcome them when they arrive. But just to kind of wrap this discussion up, I can't end this show without asking my burning questions, which are really around Web 3.0 and this world of permissionless apps that we're seeing with blockchain technologies. And I'm really curious, you know, where you all kind of see, you know, if you had to wave a magic wand, you know, and like kind of put your speculation hats on, you know, like where do you kind of see digital identity really heading? Are we going to be more anonymized?

Are we going to be, you know, go the other way hard integrating with technologies like Clear or services like Clear, you know, biometrics verification? And so, right, like, are we going to be real on the web or are we going to be anonymized? And then, you know, what does permissionless mean for tools like 1Password, right?

And like, I'm curious if you guys are even part of the blockchain conversation around development. So there are two parts to that answer. One is that we've been through several changes in user behavior on the web and in relation to their own privacy, security, and digital identity. And we've always succeeded by adapting sort of how one password works to how people actually think about their identity online. So like the first big transition was from sort of an app to the web and then to mobile and then sort of

wanting sort of it to become like a collaborative sharing experience on a service and now we're kind of seeing another transition to to passwordless for lack of a better term and we want to be there too because we don't want to be telling people you know here's what you have to do to be productive to be secure online we want to help them do it the way they already want to. So obviously, we've done a lot to make sure that biometrics are a first class feature of 1Password so that it used to be all about what we used to call your master password. And now that's like a minor detail. Most of the time, you're not even thinking of that password.

You're interacting with us through the biometric interfaces on your device. And we keep sort of making that more central to the experience. Beyond that, though, we also are very interested to see in how people are using passwordless services and SSO, as you mentioned, and all blockchain services for identity. And we want to help them do that. Because the one thing that we've seen that will always be true is there are all of these services competing for people's one true identity but we're always going to be there as kind of the source of truth for you know all these things you have to keep track of and and pay attention to to keep yourself secure online we're going to be a safe place for you to to store and use and interact with those services so you

guys are the shovels on the highways yeah that's one's one of the reasons why we don't have an SSO service ourselves, right? We saw it in the beginning days, but we want to be that collection, that out-of-band kind of place that you store your entire digital life and digital identity. And I think we are going to see more moves to passwordless, but I think you'll always have secrets you need to store. Just like somehow I find like things where I have to actually fax people information. And it's just one of those things where we have a bunch of stuff on our radar and on our kind of long term roadmap to support a lot of the transition and kind of be their industry thought leaders in that space. Right? No, that makes a lot of sense. So I mean, you kind of mentioned something, Mitch, around SSO and Adam, you did as well. So there's essentially kind of like these

widely growing adoption of like third party logins, you know, whether you're logging in with Facebook everywhere, or Google, or whatever, GitHub, Twitter. And then there's kind of this centralization on the engineering side of services like Auth0 that are kind of gateways and providers for that login and auth handshake, right? And so I'm just curious, like, where do you kind of see that as a good thing, a bad thing, a liability? I mean, clearly, it's a vertical that you've intentionally chosen to stay out of, right, which I think is so smart. You know, you want to make sure that you're relevant in all cases, and you're not trying to compete here. So I think it's very strategic move on your side. But I'm just curious,

you know, what are your thoughts on these services? Because I'm personally starting to see Auth0 as a bigger and bigger liability for the web. I'll take one of them. And that is like, I have a recent personal SSO story. So I will share it with the group just so if anybody else, I was going to write a blog post about it, I just haven't gotten around to it but my recent personal SSO story was I've used Gmail for basically since the beta days when they released the I think it was at the time called Google domains and then it was like Google Apps Google Suite now Google Workspace whatever it was called I basically always had like my own personal domain hosted on Gmail, using like a G Suite ish account. And just this year, I finally decided, you know what,

it's time for me to like, take this off of the Google ecosystem. I actually switched to fast mail who are very privacy and security focused and a really cool company that do contribute to a lot of open source kind of technologies. And they're right over there writing RFCs on JMAP. And if you haven't seen that, you should definitely check it out. But basically, I did do that. And I finally shut down my Google account. And of course, with that, I actually had Google Fi, which I basically couldn't close this G Suite account without switching my Google Fi to another carrier.

And I had not a lot, but quite a few little SSO sign-in kind of websites where essentially once I kind of closed that Google account, that no longer worked anymore, right? So I look at SSO as kind of a, you're tying yourself to that company or that provider. And in some ways that can be good. For example, I think it's really smart from a business perspective to like off board a user and just immediately kind of kill

their access to various services. But from like a personal perspective, and especially in this day and age, if like Facebook or Google or somebody does something that you don't like, and you personally don't want to support them anymore. SSO is a way that you're really tied in and it makes it very challenging to get out of that ecosystem. Agreed. Quite frankly, though, on that same note, I mean, the fact that people's emails are centralized and they don't own their domain nor their content, like, you know, if Google cuts you off, there goes your email.

Like, that's a problem, you know, also. Yeah, there's a ton of ramifications there. But so that's why I'm a little mixed, right? Like, honestly, what I want is I want SSO in certain scenarios, I suppose. But I want a service like 1Password to basically keep track of all of my SSO logins, where they are, what they are. So like, if I do go through a transition like that, I know immediately like, all right, here's the accounts that are going to be affected by it, right? And I think that's a place where like, having a third party who aren't invested in trying to lock you into their ecosystem

is a huge benefit of using a product like 1Password. That's awesome. And to your question about like the trends, I think users are eager to sort of adopt password list technologies, but they want to feel like they still have control. And that's something that a lot of these providers aren't really offering, or at least aren't being open enough about like, what do I give up if I use, you know, my Microsoft account without a password for everything? How do I change my mind about that?

How do I migrate? So we kind of want to help people have that kind of control and flexibility. And we don't want to create another sort of system of lock-in that forces people to do it the one password way instead of someone else's way. That's pretty cool. So does that mean it's easy to migrate

into one password as a customer and migrate out as well? Yep. Essentially, we've always had the premise that like it's your data it's your secrets so you can export them and take them anywhere with you also like if you sign up for a membership and you stop paying us you'll essentially still have read only access to that data like we never make it to the point where we're keeping anything from you and i think that's always been kind of one of the big values of 1Password is

we're going to respect your privacy, we're going to do our dang best to keep everything as secure as possible and something that we include into our design, even though it's sometimes user hostile, right? Building something that's secure sometimes makes it more challenging to use. And you're always going to have that data portability in and out of one password. Yeah, well, I mean, honestly, kudos to you all for even just doing what you've done. I'm really excited to check out your white papers, and we'll link them in the show notes as well. I mean, ultimately, like I've said this tons of times, I'll say it again today. The internet was designed to be open.

It was an open network between trusted peers. And architecting security into a system that was designed to be open is extremely challenging. That's why it's so painful, right? And so if we could re-envision what the web could be, if we architected the web and created new protocols that were secure first, how game-changing could could that be, you know, those would be great conversations to start having. But you know, first, we have to stop arguing about basic stuff. So. So with that said, actually, hold on, I do have a security question for you before we end, which is, you know, how with password managers, you're always copying things onto your clipboard. I always find that

a liability because it's like not a one-time copy. And so I'm just curious if you guys have ever considered working with like browser operating software folks to maybe change that or develop a new standard for like a password copy that's secure in one time, like, and that's also time limited, right? So it's still on your keyboard or still on your clipboard and you haven't pasted it anywhere, it just goes away after 30 seconds or something like that. That's actually a feature of 1Password. OMG. Even in our new modern web-based front ends, we use the system APIs to do that most effectively. So on macOS, we actually use a secure clipboard and clear it after a timeout. And we even do this on Linux and Windows in sort of native ways. That's amazing.

And on like iOS and mobile platforms as well. Basically, that is one of the reasons like we always go out of our way to support those APIs. And I'll be honest, that's actually a web extension API I would love to see because we don't have one of those from the browser extension. But in the browser extension, one of the nice things is you can basically click on an item and have it automatically fill into the page. So it basically keeps your system clipboard or anybody listening to that clipboard kind of out of the loop. Yeah, no, that's awesome. Well, I tell you, you gained one customer today. I'll tell you that much. It's perfect timing because I'm one by one. I mean, that's that's how we grew. Yeah, right. I'm due for like my last pass renewal. So I'm sorry, last pass, you guys have been great, but time for something new. It's been a pleasure having y'all today.

Seriously. Thank you so much. Yeah, absolutely. Thank you for having us. And I will do one quick call out, which is if anything we said sounded cool or something you're interested in, we are definitely hiring. I am looking for web developers. If you know TypeScript, you want to come join us, just check out our jobs page on onepassword.com. And honestly, we are a really cool group of people to work with. Not to mention, we're trying to like really innovate and there's opportunities with us if anybody's interested. Awesome. And where can people find you all online you can find me on twitter at f-i-r-e-b-e-y-e-r firebuyer on twitter um that's like the only basically the only social media platform i use

i'm not a huge uh social person i find it like even linkedin it's like uh just makes you a spear fishing target and those kind of things so i've deleted pretty much every other social media platform but you can find me there if you want to chat or set something up, obviously you can find 1Password at 1, the number 1password.com. And then Mitch. And I am also really only on Twitter, MitchCHN. And I've enjoyed all the conversation there about 1Password8 and participated in it. So please feel free to hit me up with what you like, what you don't like, what you disagree with, what I said on the show. That's great. I really love this conversation. And hey, you might find out that I agree with you and we'll get your change into the app. Because like I said, it's an early access and we still have some time to go before

we're ready to release it to everyone. So now's the time to let us know what you think about 1Password. We're listening and we're working to make it great for you. Yeah. Mitch does funny tweets of like 1Password spinning on the desktop because people thought that like Electron couldn't do shaking like we had in an old app. So some of his content is really funny to watch. And I also do real work, by the way.

He does some real work, by the way. And I will give a good quick shout out if you are an iPhone user, iPad user on Monday, iOS 15 comes out. And one password will have I'm hoping the best web extension there. So you can see what it's like to run one password as a web app on on an iOS device, which is pretty groundbreaking. It's really awesome. Yeah, that's so cool. Thank you so much for listening to your customers. And thank you so much for helping drive like really good decisions. And obviously, like I would say, world class user experiences.

And I think a lot of product companies, you know, just regardless of what they're doing for their customers, I think could take a few notes from y'all. So thank you again. It's been a pleasure. And that's a wrap, kids. It's been super fun. Awesome. Thanks. Thank you. All right. That's it for this episode. Thank you for tuning in. What do you think about 1Password's move to Electron? Are you long or short 1Password? If you could talk directly to Mitch and Andrew, what would you say? Let us know in the comments.

They're listening. If you haven't yet, check out ChangeLaw++ to support us directly and make the ads disappear in all our shows. Get started at ChangeLaw.com slash plus plus. Coming up next week, we're talking with Ilya Grigorik about Shopify's recent release of Hydrogen, an upcoming release of Oxygen, and the future they're building towards with server-side rendered React. Also on deck is Jessica Lord. Yes, this show has been delayed a little bit, but it's coming, I promise. Thanks again to our partners, Linode Fastly and LaunchDarkly.

Check them out, support them, they support us. Thanks also to Breakmaster Cylinder for making all of our awesome beats. And of course, thank you to you for listening. If you enjoyed this show, do us a favor, share it on Twitter, Reddit, Hacker News. Tell a friend, whatever works for you. Word of mouth is by far the best way for shows

like ours to grow and the galaxy brain move is to subscribe to our master feed i do and get all our podcasts in one single feed check it out at changelog.com master that's it this show's done thanks for tuning in we'll see you in the next one.