The Changelog: Software Development, Open Source - A good open source password manager? Inconceivable! (Interview)

Episode Date: November 28, 2018

Perry Mitchell joined the show to talk about the importance of password management and his project Buttercup — an open source password manager built around strong encryption and security standards, a beautifully simple interface, and freely available on all major platforms. We talked through encryption, security concerns, building for multiple platforms, Electron and React Native pros and woes, and their future plans to release a hosted sync and team service to sustain and grow Buttercup into a business that’s built around its open source.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com and we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by our friends at Rollbar. Check them out at rollbar.com slash changelog. Move fast and fix things like we do here at Changelog. Catch your errors before your users do with Rollbar.com slash changelog. Move fast and fix things like we do here at changelog. Catch your errors before your users do with rollbar. If you're not using rollbar yet or you haven't tried it yet, they have a special offer for you. Go to rollbar.com slash changelog.

Sign up and integrate rollbar to get $100 to donate to open source projects via Open Collective. Once again, rollbar.com slash changelog. Welcome back, everyone. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. Today, Jared and I are talking to Perry Mitchell, talking about the importance of password management

in his project, Buttercup, an open-source password manager built around strong encryption and security standards, a beautifully simple interface, and it's freely available on all major platforms. We've talked through encryption, security concerns, building for multiple platforms, Electron and React Native pros and woes, and their future plans to release a hosted sync

and team service to sustain and grow Buttercup into a business that's built around its open source. So today we're here to talk about a conversation that's near and dear to your heart, Adam, and something that I use, although I'm not quite as excited about password managers as you are. And you always bring up password managers, specifically 1Password, which we're not here to talk about 1Password, but we probably will talk about it in passing. We're here to talk about Buttercup, but do we bring up the conversation of like why password managers matter? I feel like

our audience is probably on board with like, this is important stuff. What do you think, Adam? I think maybe a small recap, just the fact that through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but somehow computers can easily guess them. That's a direct quote from an XK CD cartoon I just recently read I think it just makes sense to do a 101 on why password just having them that are secure and then managers because hey they have to be hard enough right 24 characters 16 characters a mix of digits and special symbols or whatever but maybe it's still

one-on-one. Okay, very good. Well, we have Perry here. Perry, you're obviously all in on passwords being important as you're working on Buttercup, a password manager. Maybe from your perspective, why are password managers something that are vital for people to understand and to use? Yeah, for sure.

I mean, password managers are a bit of a stand-in for memory, I would say. I mean, we basically understand the premise of a stand-in for memory, I would say. I mean, we basically understand the premise behind why you need passwords and why they need to be sufficiently complex. Obviously, the more complex they are and the more unique they are, then the less chance of somebody guessing them or basically decrypting whatever protected content is behind them, forcing them in the air, of course. So a password manager is kind of a stand-in, like a phone book to remember all these things, an encrypted storage where you can store these secrets. But the reason why it's so important is that, obviously, every password should probably be different as well.

I mean, there are so many security concerns that maybe people don't consider on a day-to-day basis, but having unique passwords across all of your accounts is also one such factor, and having a password manager kind of allows you to deal with that necessity as well um and obviously obviously today so many people have uh in the tens or if not uh hundreds of accounts uh online so it is so important to have have those passwords stored somewhere where you don't really have to have to worry about the strength or the uniqueness there maybe to you jared i'm curious if you use as perry mentioned a different password for every account do you do that currently yes religiously every like when you

said every account there i flinched a little bit because i had to think okay every account um i used to not you i used to have like a series of passwords that were based on like a you know there were phrases they were good passwords but they were based on a system i came up with i'm nerd right so like i'm like developing my own internal systems in my brain and generating like versions sometimes it used to be based on like the domain name blah blah blah blah that was the bad old days um i do use uh apple's password management inside of mac os so i'm on iOS, I'm on macOS. They have their key chain and they have their password generators. And I have been using them ever since they came out,

which is probably only four or five years. I'm not sure exactly when that all launched. But before then, I used to have kind of levels of passwords, like my low security password where I'd use on sites I didn't care about very much and then my high security passwords, which I would use on things like email accounts on things like bank accounts. But yes, now that I probably still have some of those floating around out there, but for the most part, I do use a high security, fresh password on every website and i just use apple's built-in stuff which works pretty well and completely falls apart when it comes to sharing and teams and those kind of things which

we'll probably get into because that's where things get really complicated like how do we rely on icloud then too in that case yep and obviously our trust in apple yeah i mean you have to you have to trust somebody somebody's trust in apple yeah Yeah, I mean, you have to trust somebody. Somebody's trust in Apple. Yeah, trust somebody. And so on your side, Adam, you're a truster of 1Password, which is a very popular solution for these things.

And I would say that's only because they've been around a long time. It's not because... I would even contend they're one of the best. They're not open source. So my reason is simply

because they've been around since forever, basically. And they've evolved their service over the years, too. Yeah, they've got around since forever, basically, and they've evolved their service over the years too. Yeah, they've got a great UI, great user experience. The whole thing is very fluid. Definitely someone to contend with in the password manager field. I would definitely say that the drawback for a lot of users that I speak to

is definitely their pricing. But other than that, I would say that they're probably one of the biggest and the best to kind of set your targets on. So, yeah, I mean, I think that your trust is well placed if you're if you're working with one password. So, yeah, I'm actually I stopped using. Well, obviously, you remark some of this for future conversation. I've stopped using this

the Dropbox sync just because I hated to have to have Dropbox installed to into a new machine to then install passwords. It was always like this, well, I got to get into Dropbox, so what's my password there? And it was always some weird rigmarole to get in there. So I ended up actually using their hosted service now, which I agree their pricing is a little bit, hey, for security, right? I think you got to pay for security. There's one area you don't skimp, it's security. Or do you?

Or, yeah, I guess we're doing it. That's one area you don't skimp, it's security. Or do you? Or, yeah, I guess or do you? That's the question you can ask here. We're going to find out here. Yeah. Either way, though, the 101 is definitely use secure passwords. More importantly, potentially even, depending upon where you sit, make sure you use different passwords for each service. And then, you know, not to use the one password rule them all kind of thing,

but, hey, it's a good brand name. Usually you have one password to get into your manager that has, you know, not to use the one password rule them all kind of thing, but hey, it's a good brand name. Usually you have one password to get into your manager that has, you know, one key to all your kingdoms, basically. Would you say that's the same way Buttercup works here, Perry? Yeah, for sure. The whole idea of like a master password for lack of a better term, but kind of one key to the kingdom, basically. One password which you explicitly should not use anywhere else for that exact reason is that it's super valuable. It should be very personal.

It should probably be written down and stored somewhere in case you ever have a lapse of memory, but basically it should not be shared with anyone or any other service. And that is, at a very low level, your encryption key to decrypt your content, no matter where it's stored, whether it's locally or on a cloud service like 1Password's hosting. And at that point, if you can kind of get around that, then I think that you're already doing very, very well. Better than the majority of users

out there, unfortunately. I think that it's still such an issue kind of communicating why this whole process is necessary for someone to follow. People don't feel like they're a target. But obviously, these sort of things, these issues that happen with account hijackings and stuff like that happen en masse and it's never really targeted. You don't have to be a target. You can just be one of a group of people whose passwords have leaked through some service that you once used. And if you are not having unique passwords per service and you use that elsewhere then it's very easy at that point for somebody to just,

you know, brute force, say I have all these passwords on service a, I'm going to run them all against service B and see who I can get into. And so that's something that's happened on the regular nowadays, especially with services used by millions. And in certain cases, billions of people with huge data breaches.

Yeah, this gets back to the point of having unique passwords. I mean, this cross-pollination of services using duplicate passwords is such a huge problem. And if you go to the very famous site, Have You Been Pawned? You just drop in an email or a username and then it basically gives you a list of paste bins that your credentials appear on. And I've got numerous paste bins where my credentials have appeared on in the past and it's quite fun to kind of go through that and have a look and hopefully you've updated your password since then, but it's such a great example of why this whole process is necessary. Because in most of those cases too, when they're doing those data grabs or those breaches,

they're not only just getting your password password they're also getting other key information like potentially even things like middle name uh usually the email address goes with it so other key information they can then also use to act as you essentially go along with that you know it's really uh you know if you're using the same password across different services or having like in your case, Jerry, what you said before, some sort of like high security that's reused. And I'm not saying you're doing that now, but like I did that at one point, too, where I had, oh, this is my high security password. And I just would reuse it here and got their data intact or their security intact. And if they get hacked, then you're essentially open to hacks as well because, yeah, it's all works. Yeah, it's identity theft, basically.

And then they can use your identity, which at the base level is usually your email address. They can use that to attack you further or pose as you or do whatever with that. So, yeah, it's quite damaging, of course. So clearly they're important, right? I mean, password managers and or high security passwords are important, but maybe what seems less, maybe actually maybe more so in today's world

than maybe it was in the early days or beginning days of 1Password since the Goliath around here is that, you know, we're drawing more and more to open source software, not just software really in our world and more to open source software, not just software really in our world, but particularly open source software and in lots of cases around security. So maybe take us back to some origination for you. You know, you got Goliath

in the room. You started this from what I can tell in 2015. So it's not like it was yesterday. It was like three years ago. And you know, one password's out there. Not to mention LastPass, Apple's iCloud stuff. So there's big players in the market. Yeah. I mean, one passwords out there, not to mention last path, Apple's iCloud stuff. So there's big players in the market. Yeah. I mean, the funny thing was, is back in 2014,

2015, I had a, a really atrocious, uh, uh, kind of practice with, with my passwords. I,

I had some four character passwords on some services which allowed it. So I, I had a very, uh, one, two, three, four,

a little bit more complicated. It was alpha numeric at least, but no, still, still, four. No, a little bit more complicated. It was alphanumeric at least, but no, still four characters. Pretty, pretty bad. Pretty bad. And eventually got talked into using a password manager by somebody much more wise than me and started using KeePass because I was cheap and didn't want to pay for one of the services.

So quickly discovered how much I hated the experience of using KeePass and how broken the interface was and how lacking the cross-platform support was in terms of like a unified experience and also the complete lack of syncing. So syncing my credentials between devices was absent there. So that was a problem. And then obviously looked towards the competition and didn't find a whole lot, which I loved back then and just felt kind of this immense interest in the whole security aspect and the sinking aspect and, and kind of fixing all of these loopholes and doing all that and then getting

something for free. And of course it's not free, it's my time, but it's a kind of like a work of passion and then kind of providing that for other people actually, so they can go and get this this application uh without all the fuss which i was going through to find something so it's definitely to fill a personal need uh buttercup so it was it was definitely yeah uh it was kind of like my first big footprint uh in open source which i wanted to wanted to get behind and it's it's grown a lot since then so so what's impressive to me about it when i

came across it first of all buttercup.pw of course it's in the show notes for those who want to check it out while we talk but the ui looks very nice the the breadth of the work that y'all have done there's a desktop client which is cross-platform there's the mobile clients there's the browser extensions it just seems like there's a lot of work to do and that has already been done in order to compete in a place where like you said you want to be synced across your devices you don't want to have just access here and we're just access there a huge undertaking i know you haven't done it alone but the other thing that impressed me is it seems like it's pretty much a team of two maybe you tell us about the team beside yourself perry and then kind of how that's grown over the years yeah sure so uh my colleague slower um yeah he's he's been

obviously uh just a fundamental part of the whole whole process and uh just like couldn't have done this without him and his motivation his personality i think that like when you find the right people to work with uh you all know that it's kind of like key to getting any project off the ground. And we met when I moved to Finland, both working at the same ad tech job, not super interesting, but pretty technical, got to know each other and got to know that we both enjoyed writing open source software. And we spoke about the whole password manager situation and he agreed. And yeah, we pretty much just got off the ground then and started kind of throwing things around in Node.js and playing with the projects there

and kind of fell in love with crypto and kind of building projects around that. And yeah, the first project to kind of come out of that was the desktop application with Electron and React and it was just a huge amount of fun to build that. Completely new experience. I mean, back then it was still a huge amount of fun to build that completely new experience. I mean, back then it was still a little bit broken, a little bit rickety. It wasn't completely solid. It wasn't super friendly to build in, but it got things done and we were

able to very quickly produce a cross-platform application. Yeah. And it just kind of like spiraled from there. And after that, we just became, you know, insatiated with that and went on to the mobile app and then the browser extension. So let's talk about the core. I think the integration points are interesting. I think talking about how you integrate into the operating systems is so important for these types of applications.

And one of the reasons why I didn't use 1Password back in the day, Adam, was because the integration into the operating system was just not there. And that's not 1Password's fault. It was really Apple's fault in the case of iOS, where they weren't providing the hooks into the system in my head of like doing these passwords and so i was just kind of limping along with a semi-good password system because i hated the fact that i would have to like leave safari to go to one password to get the thing to get back into safari and a lot of that's been smoothed over in recent releases at least on the ios that i'm not very familiar with the Android side, but I love to talk maybe down the road in this conversation about those integrations, Perry, and how you work into Mac OS and how you work into Windows to make that feel seamless, because it really needs to be part of, you know, the kind of the core of what you're doing on your devices. But

let's talk about how Buttercup works internally. You said you've gotten very much into crypto. I have no idea how these things work. I assume you have some sort of, you know, some sort of secure vault that you're just encrypting based on this master password, but I wouldn't go any further than that. How do you build Buttercup from the inside out?

Yeah, I mean, essentially in memory, Buttercup's just basically an object store. It's just storing just obviously all of your entries in there, all your usernames and passwords. So essentially, it's just plain text when it's in memory, obviously protected by the operating system at that point. But while it's open, it's mostly plain text. When it's closed, obviously, all that's wiped.

But what's being written to disk is actually a delta, so a list of history of your vault. So what happens is every time you change a password, every time you move it in the vault, you change a username or something like that. So if you're updating credentials, this is very important. So the deltas are kind of kept in text format. So a huge list of all of the previous changes, probably a few thousand entries over some significant amount of time. And that's encrypted using AES in CBC mode. So it's just a really, really basic, but still extremely strong encryption,

which I would assume most password managers use or should be using. At least the big ones do. So LastPass, 1Password probably all use the same technique. So we encrypt that and we also compress it. So we GZip it as well. So we try to make the file as small as possible. And on top of that, we're obviously running key derivation. So obviously your password isn't directly used to encrypt the content.

We go through the process of deriving encryption key from that. And that's kind of where the security really comes in because obviously if people are trying to attack your vault, they're trying to gain access to it. So usually they're brute forcing it or something, or they have some sort of table of most commonly used passwords, things like this. So basically, when they're attempting to break your vault, they're usually trying to brute force it. comes in is that we use 250,000, maybe 300,000 rounds of key derivation iterations before we actually use the resulting key to encrypt the archive. And that's basically to prevent ultra-fast brute force attacks. So these are all pretty standard techniques, but what they result in is an industry standard, if not better, very, very strong encryption technique to store the contents of the vault

in a text format, essentially. Okay. So when I enter my master password in order to decrypt my vault and gain access to the password stored in, you're not hashing that. You're going through this derivation process. Is that right? Is that when it happens is when I enter it and then you go 300,000 times in order to get to what is eventually the hashed password.

Exactly. And there's also various other values which are stored with the vault, such as a HMAC, which is authentication. So it's basically to ensure that the vault hasn't been tampered with, which is another common crypto technique. So after your password is hashed, we also derive this HMAC, which is just another type of key. And we compare the two and basically make sure that the vault hasn't been tampered with. There's no modification to the data before that payload is decrypted. So there's a number of techniques we use there just to make sure that the vault is clear, not corrupted, not modified. And then of course, we attempt to decrypt it. And if the password is wrong, the decryption will fail, of course, but not after taking a

substantial amount of time to derive the key so obviously you have to wait uh x hundred milliseconds for the key to be derived which should hopefully prevent like a huge large number of attacks per second so yeah it's always fascinating to me the desire for slowness it's like the opposite of all other computation right like actually something that goes you, we talk about cryptographic algorithms and which ones work well. Most of the time you're going for speed, right? Like how can I get this decrypted fast enough?

But in these cases, you're actually wanting to go slow enough that it's computationally expensive to brute force. That's always interesting. Yeah, it's a really fine line to walk is like how slow do you make it before it actually gets annoying? And I think that we've skirted that a long time. It's been a huge challenge for us because if you take your MacBook, for instance, it decrypts and encrypts insanely fast. It's ridiculous. So,

us using 250 or 300,000 key derivation rounds is actually quite low. It's recommended to be a bit higher. But the second you take that process and you try to run the same process on a phone, especially an Android phone from maybe five to ten years ago, it's horribly slow. And the user experience is just not there at all. So you have to be considerate, but you also have to make sure that you don't just drop it down to an unreasonably insecure number. So it's a bit of a challenge. Not only that, but now you have, I don't know how this fits into derivation, but like you got face ID or touch ID or different ID types aside from the password. So you've, you've once authenticated to it and now you've got your face as part of the encryption process, which is a whole different thing.

I'm sure that's at the, uh, you know, iOS level, which we're talking about, Jared, the integration level and making that more and more seamless, which 1Password has done pretty well on that front, at least with Face ID recently, I've just started to use that. How does that kind of key part fit into this derivation process? Is that one more layer you have to add support for? Is that on the roadmap where you're at with that? How does that fit in? It's actually already done. I mean, not for desktop yet, but we have the Face ID and Touch ID working on the mobile app. So after you've logged into your vault for the first time using your encrypted password, you can immediately turn on Touch or Face ID depending on the device. So what that does is it basically stores your master key in an encrypted format, which is managed by the OS.

So it's an OS level thing. So at that point, then iOS or Android is responsible for storing that to its ability, the best of its ability. So you have to have some level of trust at each step, depending on what you want to do here. But of course, people obviously store their entire lives on their phones. So I think that it's a reasonable expectation to use something like Touch ID or face id for convenience at least so it makes sense yeah you definitely have to enter some trust and as you were talking through all this i was thinking gee should he be sharing

exactly how they do things because somebody could reverse engineer this and it's all open source bro well yeah of course i guess so but uh you'd have to dig so you'd have to either be you need harry how how hard you gotta dig to get at your guys's uh algorithms if you know what you're looking at it's it's right in front of you really it's like front page yeah and the thing is is it's not like people have raised that that point over and over and over for us it's like oh open source isn't it's not going to make it more insecure and actually that's kind of the opposite intention we're having is try to make it more secure i mean i enjoy crypto.

I wouldn't say that I'm definitely not a professional by any measure. Probably wouldn't say I'm a hobbyist, but somewhere in the middle, basically. And this is where it comes in is that I can't put this whole people's, all these people's trust in just myself or my colleagues. It has to be a bit bigger than that. And that comes back to the open source discussion is that it's for everybody to look at and everybody to critique and modify and improve. Obviously, we were very comfortable with what we first released in terms of being secure, but the intention is to kind of like make it better and use as little homegrown crypto as possible and use as much as the operating systems we're building on supply. So trying just to be very, very smart with that critical part because you only get one attempt at building a secure system like this. So you

don't really get, I mean, maybe some of the big password vendors such as LastPass, they've had a couple of successful hack attempts. So I think that they've obviously still pulled through, but normally those things are incredibly damaging. So we need to make sure that we have our ducks in a row when it comes to the crypto. How do you mean you only have one attempt to getting it right? I've got a bit of a pessimistic view on the whole data breach thing. I think that like it's extremely damaging brand wise, especially for someone like us where we're starting out.

So the crypto and the security measures there are definitely like a primary concern for us, just making sure that it's all put together properly. In light of that, did you have any concerns with choosing Electron and JavaScript as platforms with regard to this because of a lot of the transitive dependency problems that we've seen? I'm looking at your at least uh buttercup cores package json and your dependencies here are very small so that's great obviously more

dev dependencies than runtime dependencies but i assume once you get to buttercup desktop this list is probably going to balloon what are your concerns uh with regards to using third-party packages or is it more about using the right crypto algorithms and not rolling your own crypto yeah uh that that's a extremely good question uh i think there's definitely a bit of concern uh on the table uh with the dependencies uh i mean just today i got a message right before the right before this is that uh that there was another dependency uh injection uh fast that appeared on NPM, some event stream library,

which had some malicious code injected into the minified source. And this happens all the time, and it is quite scary. But from what I've seen, it normally happens due to the fact that whoever is the author of the package has normally done something quite questionable

and normally handed over the ownership of the package to somebody else or used terrible security practices or something like that. So at least from what I've seen, it's been normal carelessness. And I have a bit more faith in the larger packages such as React and stuff like that, where it's a very, very strong community and review-based progression model there. So I think that for the most part, if we kind of stick to kind of the core UI libraries and don't haphazardly install kind of like, you know, time-saver dependencies, I think that we'll be mostly okay there. But it is a constant concern, and I would ideally like to reduce the list of dependencies down to something very, very manageable manageable something which is just bare bones and just what we need but i mean at some point you know it might it'll just become

overkill of course because i mean you know like you can't make it perfect at some point you have to use somebody else's software you have to use electron you have to use react it's like i think that you can get it to a point where it's a it's of little to no concern but it's the same as the thing as, like, it's the computer you're running on secure. You know, have you installed something which is questionable? Are you on Windows and did your mom or somebody else install some questionable package from the internet the day before? All of these things are going to increase the chances of your computer being hijacked, your passwords being stolen, your secure information being tampered with. So, yeah, I think you have to draw the line somewhere, but both the dependency model and everything else

is definitely a concern for us. So, yeah, I mean, easy with the core, but with Electron, yeah, obviously it's going to explode. You need a lot to get off the ground with that these days. Yeah, exactly. The reason I thought of that, well, first of all, it was also because of that, I don't know if it's a zero-day, that specific vulnerability that was pointed out with regard to an NPM module that was snuck onto NPM and then propagated down. And the difficulty with that is, and I agree, it's often often the case and in this particular case it was a the main the main

maintainer of the package gave contributor access to somebody who then pulled in another dependency which had this issue it's like these things are very difficult to manage right because um you may not even be the maintainer of the project it can be be a maintainer of a dependency of yours, or maybe even a dependency of a dependency that was lazy or that was malicious. And so these things are very difficult. That's one of the reasons why I thought of it. The other reason is because we just recently interviewed Brian Bondi, who's a CTO of Brave,

and they were maintaining their own fork of Electron. Brave is a web browser built on Electron. And they were maintaining their own fork of Electron with specific security patches against Chromium that the Electron people weren't as interested or motivated to keep up to date because of the way Electron's supposed to be used. It's not necessarily built to be a browser platform um and so i was thinking you know they had security concerns there and i was thinking well what about electron in the context of a password manager certainly a password manager is not being exposed to as broad a swath of potential attacks as a web browser is but nonetheless um these things most definitely are things that you're probably thinking about since security is so important. Yeah. Electron's actually probably the worst for us. I mean, obviously we have the

browser extension, which is all browser based. So that's also concerning, but I would say that the desktop's the, probably the most concerning because you're right. It's pretty much a full blown browser when you look at it. So that's a bit tricky for us, but we do, we do bundle everything when we release, which is very important for us. So there's a very, very small amount of dependencies which are installed when you actually install the application. So what we're actually releasing should stay relatively,

well, mostly untouched before it gets to the end user. So there are a couple of low level dependencies which actually need to be installed on the host operating system to actually work because they have OS-level bindings, C-level bindings, stuff like that. However, everything else, such as the UI libraries, all of the helpers, the Buttercup core, stuff like this, these are all bundled with the application. So, these are not modified after you install them. So, they don't have a chance to download something

else, fetch malicious code. And we have, I would say quite strong review process like we we check obviously the the network access we modify all we manage all the requests uh before each release so i mean this will improve obviously when we kind of flesh out a bit more of a larger team that we can actually use to to quality assure the product we're releasing but all in all I would say that I feel quite confident that the built product coming out in the desktop is still not changing so much when a user is installing it so I would say the risk there is much more reduced based upon just the fact that we package everything before we release. This episode is brought to you by Linode, our cloud server of choice. It's so easy to get started.

Head to linode.com slash changelog. Pick a plan, pick a distro, and pick a location, and in minutes, deploy your Leno Cloud server. They have drool-worthy hardware, native SSD cloud storage, 40 gigabit network, Intel E5 processors, simple, easy control panel, 99.9% uptime guarantee. We are never down. 24-7 customer support, 10 data 10 data centers three regions anywhere in the world they got you covered head to leno.com slash changelog to get 20 in hosting credit that's four months free once again leno.com slash changelog So I guess the next layer of security is, you know, one, am I installing something that is, in fact secure. And then you kind of go back to this idea of reproducible builds, which is essentially the concept of, you know, you build it once and you give me a binary and I can confirm

that binary relates back to its original source. And then obviously once it's running, you have runtime concerns, but where are you at with reproducible builds and that security level? Yeah, I mean, this is something that we obviously care about and it's not just from a security point. I mean, that's the most important, but obviously from a stability point,

having reproducible builds is very important. Having a whole lot of things which change dynamically on install time is generally not super nice to debug and play with. So, yeah, so this is something which is important for us. And Electron has a really great system here. Obviously, it has a whole lot of bundling support, so you can bundle everything using Webpack or whatever you want beforehand, which we do. So that creates static files for the most part, which is great because then they don't change. They're what we run and what we test and then what we release and then

ultimately what we sign as well. So that's all well and good. And then obviously there are still a couple of low level OS integrations which need to be installed, file system connections, things that Electron has which patch into the OS to kind of give kind of the look and feel of a native application. These things we can't avoid. We obviously can't bundle. So unfortunately, they need to be installed at install time. But we can kind of obviously restrict the semantic versioning there and kind of be quite strict with the versions that we're installing. So at least if we're locking to a particular version on NPM, then that should be the same code that everybody gets, obviously, again, the trust has moved elsewhere. It's moved to NPM. It's moved to the fact that they can run a secure firm there. So the buck has to stop somewhere, of course. Yeah. Random, somewhat related question. Just wondering about Electron, because there is so much pulled in.

Let me tell you about dependency management. There's so much there. What was the original reason for Electron? Was it because you know web technologies and you want to go cross-platform. That's what I would assume would be why you selected it. But why not write every line of UI from scratch, right? Why not remove that dependency? Yeah, true. I mean, I actually started my development career, my hobbyist interest in development actually with QBasic and very quickly moved on to things like

Delphi actually, so Pascal and Delphi and did a lot of raw interface development there. And I can see the value behind it because it's so easy to get off the ground and build very, very powerful applications. And it's got native performance, which is something which I really value. It's the whole stinging feeling of using a web-based application when you can kind of tell it's not quite as responsive as you would hope. So, that's a crucial point for me. But at the same time, after all of that, I'm left with the Windows application, which can run on a couple of versions of Windows and nowhere else. And of course, there are other cross-platform systems which allow you to build cross-platform native applications. But I've seen so many of them and they don't really

look super good. And we wanted something which looked beautiful, worked really well, and was obviously less work for us because there's only two of us working full-time. And obviously, we have a lot of really great contributors. But at that point in time, it was important that we could get it done and get it done quickly and then have a lot of code reuse. And then most important, a UI, which is uniform across the operating system. And we got three operating systems for the price of one, minus the bugs, of course, and the quirks with the UI.

But apart from that, it was super easy to get off the ground, and Electron was like kind of really coming into its prime then. So for us, it was an obvious choice. And both of us were React developers, so it just made sense to kind of couple all of that UI work that we were playing with with Electron. So it worked really well. So if the Electron team is listening,

what could they do to make your job easier from a security front? I think that like having as much eyes on kind of the security aspects and kind of like the regular updates because obviously electron uses uh obviously chromium under under the hood and and kind of being as up to date with with uh with the actual base there the the upstream is is so super important because obviously uh the obviously the funding levels are a little bit a little bit different the the effort going in into each is a little bit different obviously the the interest and directions like you mentioned earlier a little bit different. The effort going into each is a little bit different. Obviously, the interest and directions, like you mentioned earlier, are a little bit different.

But ideally, security should come first. I mean, it's so important in the browser landscape to have something which is secure. And this comes back to the runtime security as well. It's like, do I trust Chrome to be secure in terms of runtime attacks and stuff like that? Yes, for the most part, I would trust it to be quite secure, but it's never going to be perfect. But it's so important that there are so many applications now being based upon this platform

that it's more important than it's ever been that it's more secure. It's not just a browser anymore. It's the base for a huge swath of applications and obviously in how password managers so yeah we're very interested in in kind of the development cycle being kept kept very tight is it a case where you would ever move away from electronic fae or is this just good enough for now where it gets you to a certain point because you're a smaller team or you're you know you would have more to talk about later but like pure you're pre-funding or I'm assuming revenue at this point, you get some sort of service ideas or business around this to sustain it in the long term. But is this good enough for now or you eventually think we should probably build most of this on our own after a certain point? Super good question.

I mean, and that also relates strongly to the mobile application, which is built in a React native. It's very much related to this topic. So I think that, yeah, would we build them native if we had the resources mobile? Absolutely, yes. I'm done with React native. It's a beautiful system to get off the ground. It's a lot of fun to work with in the beginning, but to maintain over the long term, it's been a huge pain in our neck, especially with crypto. And I'll get to that later. But in terms of Electron, Electron's treated us really well and it's been very enjoyable. But I think that if we had the development resources, I think that we would definitely strongly consider building

native, obviously to reduce security risk. And another thing to reduce package size, because right now our installer is around the 55 megabyte mark. It's gigantic for what it does. And obviously that's because you're packaging a whole web browser and no JS with it. So if you could get rid of that issue there, you'd end up with a faster, smaller, more secure application. But obviously that involves a lot more work than we're capable of putting in right now before we actually get funding and be able to work on this full time. This is probably a crazy idea and it's probably also a bad idea, but

there's so many electron-based applications running on any given machine on a regular basis. It's almost like you should have like a dynamic linked library that is electron or like a single instance of chromium or something that all these electron apps would be running against that shared memory like that seems like that's probably pretty stupid right no i i think for most applications it probably would be okay i mean but then the emphasis is on how much security is actually but it's better especially like shared shared memory like i mean the second there's any vulnerability then you've just kind of opened the doors for for an attack vector there so i think that there's and of course like if you tell explain that process to people they're only

going to criticize electron more than they are already today so yeah i think that like for the small increase in performance it's probably not worth the bad publicity i would say i was thinking the same thing jerry but i was like that's kind of a not a very smart way to do you're smart enough not to say it i was thinking that though because i was like well that's the case i mean if you can remove node.js and you can remove chromium but if you had a trusted local source that but then it only makes it more and more niche right like that's that's not going to be everybody well right like not everybody's going to do that even if you can you'd have to have like a full build and then like a linked build. Right.

Yeah. It's like I said, it's probably a bad idea, but I thought I'd throw it out there because I was just trying to solve this problem. Like, it seems so silly that, you know, you get this new application. And because of the same reasons that you picked, Perry, they wanted to be cross platform. They understood web technologies. They wanted, you know, these things that were so easy. A lot of people are building Electron apps. And as an end user, you know, I don't care so much about cross-platform as long as it's in my platform, which is the same for everybody, right?

But on my platform, like, I just, I do not want to have a new Chrome instance for every single app that I'm running. And all this memory blow and stuff just seems like overkill. And so I'm just trying to come up with ways of solving it. And that was for you. It's all just for me, but yeah, no, I know.

I'm just joking. Cause it's, it makes sense to be selfish in that way. Like you want to be, you want your, we talk about this in Apple nerds all the time, like certain applications, just blowing up the, you know,

blown up the Ram or blown up the CPU. And you know, this is why, cause you have multiple builds or whatever, just basically waste chilling there. Just basically waste, chill in there and we're particular. Yeah, of course. That's a big concern of ours as well.

I think that both of us are very perfectionist in terms of getting the best out of it we can and obviously sometimes to our fault of not being able to release things fast enough, we'd like it to be as perfect as possible and one pain point as such is definitely the UI. We feel like we kind of love the look of it and love how it responds, but in terms of like the resource usage, yeah, it's a huge pain. And that would be something

which would be great to get rid of. But at the same time, having this unified deployment and build process and everything means that we can also release fixes and updates much quicker. It's, you know, maybe like half a day to get a brand new feature in and all cleaned up and released instead of, you know, spending a couple of days on one OS and then going across to Mac and Linux and doing the same build process, which would be a huge pain. So, I mean, you really need a team to do that simultaneously, especially in terms of security releases and stuff like that. You can't afford to have a long release cycle at this early stage. So, Electron's kind of helped us with that, but I can see that we might outgrow it at some point, but at the same time, I can see Electron improving by leaps and bounds in the not so distant future. So, I'm optimistic that it will

get smaller and faster and lighter and more secure all the time. But of course, that's just a pipe dream at this point. So if you had your rathers, though, you'd rather, as you just said, rather than move on to native builds for each. Yeah, I think I definitely prefer the process. Like you said, I'm a web developer. So for me, it makes a lot of sense.

And we kind of like started this whole project as like a javascript project it was like it was the javascript password manager um kind of like really embracing the community there uh so everything is built with javascript bar the mobile applications crypto stuff because we actually released the first version of the mobile app with the crypto brazzerify library so basically the the node.js compiled crypto libraries, which were gigantic and they were terribly slow on mobile, didn't work very well, crashed on a lot of devices. So we basically rewrote those in native Objective-C and Java and built a bridge across to

the app to use those. And that was a great thing because the speed increased and the size of the app went down. But that's also a huge pain to maintain. Every time we find something we want to add in terms of crypto support, we have to do the JavaScript modifications, a lot of painful testing on a React native, and then we have to do the native code in Objective-C and Java and obviously do tests for that as well.

So it's a huge development process when we have to manage those native builds. Are you actually writing those crypto libraries or are you importing and statically linking them? Yeah, so we were using the built-in crypto stuff in Objective-C that Apple provides and the same in Java that Android provides. And just recently, actually, we've moved across to Rust. So we've removed all of that and now the crypto library is built in Rust, and it's the same one which is deployed to both Android and iOS. But that is using Rust's core crypto library.

So again, nothing that we've rolled our own. It comes with the base system. So very confident that we're using the best and the safest there. But now we're back to kind of having one build for multiple devices, so it's a little bit nicer to work with. And from React Native, let's talk about the mobile apps a little bit because you're frustrated with React Native. It sounds like a lot of that is because of running

the JavaScript-based crypto stuff on phones. But it sounds like it's providing you at least the ability to call into that Rust code or the compiled output of the Rust code and to do these low-level things in a kind of a cross-platform fashion. Tell us about your experience, maybe some of the reasons that you are frustrated with that platform without just tracking people. No, actually, to be honest, I love React Network. It's been a fantastic experience and I really feel it's still somewhat unrivaled across the other development environments for mobile. I've worked with titanium and a

little bit of ionic and phone gap and Cordova played with all of them and really it's just that the infrastructure was not there and React Native kind of offered a familiar interface obviously through React style building of components and that really appealed to me and I gave it a bit of a go and it worked amazingly well immediately on both platforms. And we just thought, hey, this would be a great way to start. And that felt like a really good idea up until we had to do the crypto stuff. And then we realized our mistake. But at that point, we just kind of said, OK, I mean, there's no way around this. At some point, the crypto is very, very performance and security heavy. So it needs to be native in most cases.

So we just bit the bullet and built that natively. But I think that the biggest pain point for React Native is just the debug ability. It's just sometimes it gets you into a position where you've got some really, really gnarly transpiled and minified code running, which you're debugging on a virtual phone on your computer, which is using all of your memory and CPU. It just gets to the point where it's like, why am I doing this this way? It just feels very counterintuitive. But you walk away from it and have a think and come back to it and then it's okay. Or you delete all of the work that you did over the past day and start again. But I mean, we've gotten through it with the mobile device and we have something which we're quite proud of. But I think that would be the first thing that we would, we would rebuild in separate native applications had we the time. So.

One small statistic, which maybe is an outlier or a red herring, which you can speak to is Buttercup desktop has 42 contributors. That's the electron based app. Whereas Buttercup mobile has just three contributors. I'm speaking ofron-based app, whereas Buttercup Mobile has just three contributors. I'm speaking of code contributions, realizing that there are many other contributions besides code, but maybe this shows that, you know, the difficulty

of working with React Native or maybe just the learning curve. And those, I'm sure, two of those three are yourself and Salar. So just one third-party contributor on that one. Maybe the age of the repo

also plays a factor, but has it just been less-party contributor on that one maybe the age of the repo also plays a factor but uh has it just been less community focus on on that application it really has and we've tried to stir up focus in it uh we've had some bounty source uh items opened on the mobile application we've had uh lots of like outreach on twitter trying to get help with it and just yeah very little feedback and i mean not for like a trying it's just been just been so little interest and i mean if you look at our users as well right now um we have a 350 000 downloads on the desktop application uh which includes uh some updates of course but uh that's probably our biggest number of like active users is coming through the desktop application and then comparatively uh to the mobile application, maybe we have just a few thousand compared to that.

So it's, it's, it's a much smaller interest group to start with. But at the same time, I just think that the, the reward in developing in react native is just not there. Everyone I know around me that uses react native is doing it for work. Like they're getting paid their,

their salary comes from their work on react native, whereas so many people I know that work with Electron, they're doing it for hobby projects and really enjoying it. And I love it as well. I feel like it's a very, very different environment, and I think it's such a steep learning curve in terms of actually getting everything to work, getting all the libraries installed, getting the perfect environment, getting Xcode to a point where it doesn't want to update when you open it.

Yeah, it's a huge, huge lot of work to get that working, whereas Electron is very much just plug and play. You install everything and you run it and you have a working application. So yeah, it's vastly different and that definitely does show in our contributions. It's much harder for us to get the mobile application to a point where we're as happy with it as the desktop application.

Jared mentioned some concerns earlier about integrations. It's always been a stickler for him in terms of user experience and even using a password manager in the first place. What are any gotchas on mobile around the experience in terms of integration. I know with iOS, you have the up arrow that lets you choose other services when you're on like a password login page, which I'm not sure that's a standard or not, or if it's because I have one password install, but that key icon that lets you then choose or launch something, I believe it's just one password. I could be wrong, but maybe you could walk us through some of the UX concerns you may or may not have around mobile for you. Yeah, that's a good point. And that,

if you're talking about the key, I believe it is at some point an iOS level feature they have in iOS 12, they have the new password manager integration, which is really funny for Apple to do because for them to acknowledge the password manager community as something which needs a direct integration like that is actually really cool. But yeah, so you can obviously integrate with that. You need to obviously build it into the application, which we haven't done yet

because it requires some low-level native code to do that integration, which is still beyond us at the moment. So that's currently in progress, but we haven't released it yet. But that's obviously very, very helpful. And that bridges a huge gap in terms of usability because you don't want to switch applications, like you said earlier. You want to just have it at your fingertip.

This is where 1Password's really kind of pushing things forward here because they were, to my knowledge, they're the first ones that announced the integration. So, yeah, that's definitely where we want to be as well. And those are very, very tricky because these are things that React Native will never be able to do, in my opinion. I just don't think it's going to be a focus for the community to build. It requires a lot of low-level native integration and testing and making sure it works. It's not available in every iOS version. So it's going to be something which you need to write the Swift or Objective-C code to get working. So that's a bit tricky there, but still a very important point for a password manager to be usable is having the connection from the interface

that you're currently looking at logging into. I don't really mind app switching. I mean, I guess I'm less a Jared and more an Adam in this case because I would actually deal with the security over convenience factor, although I can remember a day when I've been a one password user for a very long time. So that's my perspective. I'm speaking from not so much keeping to marketing them,

but you know, there was a day when that integration wasn't there and I would app switch from, you know, my login screen or the app login screen back to this thing and, you know, copy the password and remember the username and, you know,

mainly type in one piece, but then paste the other. That's turning Jared's stomach right there. He almost threw up in his mic right there. I mean, I was okay with that. But it sounds like what you just said was that you would have to move away from React Native to get that kind of feature set.

Well, no. I mean, we could do the same thing with the crypto, basically. So you basically build the local, sorry, the native integration in Objective-C or whatever the code base is, and then you have to build another bridge to the React native. So the JavaScript is calling an asynchronous bridge to the native code. And that becomes very fiddly because testing that is pretty much impossible. It comes down to acceptance testing via the UI and then maybe unit testing either side separately. But it's a huge pain to kind of manage that

and debugging it's very painful because you can't just write logs on the native code side and expect to see them in your console. This is where I thought eventually Apple would just buy the Goliath in the space and maybe this is what's drawn you to that could be wrong but i've always speculated that apple would eventually buy one password and just be done yeah i mean that's a very good question yeah but i mean of course like it's a it's a huge target and i mean you you're buying so much when you look at these companies you're buying a huge uh expansive users and operating systems and integrations.

And I think that it would be quite a smart move. But at the same time, like Apple also doesn't shy away from building things themselves and having fully fleshed products. So it wouldn't surprise me if they went either way with that. I mean, it seems like they're already taking quite the route of doing things themselves with password management anyway. Yeah, I mean, I'll say, you know, 1Password is a power user tool, and it's for teams, and it's for advanced situations. Apple's iCloud keychain stuff completely suits me as just a regular user that just wants my stuff, my passwords just there.

Yeah, you're right. Yeah, Apple definitely looks more focused towards, like, the end user, really, really not. Not so much the teamwork side of things. This episode is brought to you by our friends at GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. Check them out at gocd.org or on GitHub at github.com slash gocd. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization.

With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end with no problem. They support Kubernetes and modern infrastructure with Elastic on-demand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use, and they have professional support and enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. So we're talking about mobile integration and the main thing that you need on your mobile device that you also want on your desktop that you also want, I don't know, on your wristwatch or wherever else you need passwords is the same vault, right? You need that sync. So this was one of the main things that I think you started off saying you wanted, Perry. So tell us about the sync story

with Buttercup and how it works to get that vault propagating around. Yeah, I mean, this was one of the points which actually got me started on Buttercup was obviously maybe KeePass wasn't the best decision for me to start with. But it was a great start. It was free, has a lot of open source applications around it. So that was kind of my starting point. And I noticed that there's no syncing. I mean, they have some sort of basic, really, really hard to set up web server, which you can use to kind of sync your accounts, but just not very user-friendly there at all.

So that kind of propelled me into building Buttercup in a way which would be easily synchronized. So Buttercup writes to vault files like we spoke about earlier. They're just text, basically. So they're really easy to store and send and very very lightweight while being secure so i immediately thought okay well where can i put this like where can i put it where it's accessible everywhere and i happen to be running my own cloud server at home so called own cloud which is fantastic free open source software uh but obviously not everybody does that so immediately we also built a dropboxbox connection as well. So pretty much everybody

knows Dropbox. It's a household name. It also happens to be free. And the fact that we're encrypting the content before we store it there kind of negates, in our opinion, any risks which might be associated to using a cloud service provider. Not all of them, of course. I mean, again, we're still trusting a vendor, but at the same time, storing it on your own computer, storing it in your cloud server, at least Dropbox has a team of professionals behind it. So that was an obvious choice for us. So we started with those two in terms of syncing the archive

and made it available via a web interface to all of our applications. So very easy to load it up in each device, decrypt it, run it, save it, write it back to the host there. So I'm feeling like a failure, Adam, as a changelog-er. I've never heard of OwnCloud. How about yourself? It's first for me, man.

I'm with you. We missed it. So maybe an upcoming episode on OwnCloud. That's something you think is pretty cool, Perry? Yeah, it's really cool. It's a PHP-based system. It has a couple of derivatives. Also, NextCloud, which I want to give a shout out to. Those guys have been amazing helping us with integrations. All of it's open source. It's as good, if not better in my personal opinion, than some services like similar to

Dropbox, obviously because one, it's free, but it's also very, very fast. They have all the clients, mobile applications, and you pay nothing for it. Of course, you need to be relatively tech-savvy to set it up yourself. But other than that, these services are a lot of fun to work with and kind of teach you a lot about cloud storage as a whole. And it just seemed like a natural start for us. And we also added WebDAV support, which many online web hosts support. I'm not sure whether Amazon Drive does anymore, but many of these cloud services support WebDAV, which is a great way to integrate with cloud storage, which we

also support. So at the beginning of the show, Adam, you were mentioning that you used 1Password with Dropbox support and then you upgraded to some sort of paid version because you had problems or you didn't enjoy the experience with Dropbox specifically, Buttercup based on dropbox or own cloud or webdab but um curious what reminded me adam what the issue is with dropbox with your password sync well i always had like 2fa going on there so i obviously had some sort of like crazy long password to get into dropbox because hey it's dropbox right like i wouldn't want anybody in that thing. So my password, your Dropbox, right? My password would be in one password. So to install it, you know, I would have to read this super long password from my phone or something

like that, that did have access to one password so that I can install Dropbox just to sync it. And then, well, of course I've got tons of stuff in my Dropbox. So it's like, how do I prioritize what to sync to a brand new machine? So that whole song got more and more troubling. So I was like, you know what? I love Dropbox sync for most things, except for brand new machine installations, which was the first thing you're going to install is going to be, you know, your password manager, because you're doing lots of stuff.

Yeah. I mean, there's a lot of friction there, obviously, with logging in. And I've done the same thing a couple of times, log into the vault on my phone and needing the password to the storage host that I'm storing it on. So I need my desktop computer and I need to open up the password there so I can kind of type it in my phone. That's kind of like unavoidable, unfortunately. I mean, unless, of course, you have a paid hosted account with whatever provider you're using such as one password but of course i mean we would like to still circumvent that somehow like we have some plans to release like a a secure qr code which you can just scan on your mobile app so basically if you've got your computer nearby you could instantly connect

uh to the same same vault and the same source just by scanning it with your phone. And that would alleviate some of the typing in of multiple passwords and kind of getting that to your device. So we have some ways to get past it there. But ultimately, yeah, we'd want to end up with a lot of people using our eventual hosted service, which would kind of alleviate a lot of these self-storage and issues with using providers like Dropbox and other ones. It sounds like from

that perspective, I'm assuming this, I'm hoping you answer it however you feel like it, of course, but that you're in this for the long haul. We've had this great conversation about some really thoughtful stuff on how you've built out Buttercup. So a lot of thought's gone into various

layers of this, various tons and tons of hours of your time have gone into this. And it seems like the next step past sync is the service, which could be the next step to some sort of like long-term game for you. What's that look like for you? Yeah. I mean, this was still obviously a hobby for us at some point, but like we've gotten to the point now where we realize that we're, we're extremely serious about what we've built and the community has been super supportive and like really positive about what we've been providing so far.

And a lot of people wanting to get in on it and use it. And we've received a lot of compliments and already that's kind of fueled our desire to actually make something of this and kind of keep it afloat. And as much as we enjoy leaving work, leaving our day jobs and coming home and then spending several hours on Buttercup, which we will continue to do, of course, no matter what, I think that it would be great to kind of make this a full-time thing

and actually have a team behind it and see where this will go. So we have plans to release a hosted service, hopefully sometime in the first half of next year, where we could host people's vaults online, similar to the other services. However, we're trying to create a really, really low bar of entry for people, and we're intending to have a free hosted service for single personal use vaults.

So there won't be any charge to host your vault on the site due to the fact that they're so super small. And I mean, obviously that's going to be great for adoption in our eyes as if it's not going to cost anything. But we intend to also have a team-based cost model behind that, which would hopefully drive some sort of company which support the development of Buttercup in the future, including the open source, of course. So our intention is to build a company behind it and have that which support the development of Buttercup in the future, including the open source, of course. So our intention is to build a company behind it

and have that also support the open source community in whatever way we can. So it's just going to make the whole project a much stronger entity. So is that where you go on that route because you think it's the great way to take the business the next step, or is that the preferred route to some sort of sustainable funding you know because there's other ways you can go about sustainability i'm just curious if that's the route you chose to go because of some sort of grand vision and future yeah i mean we've looked at other other ways of uh of of funding this and we've had a we've had a

lot of talks with some great investors around Helsinki as well. And I don't know. I think that, like, we've chosen it because we would actually like to kind of see it built into a company. It would be nice to kind of, like, have some full-time employees around and actually have some sort of process there. We've tried things like Open Collective, which has worked exceptionally well. But I just don't think it's going to scale to a level fast enough where we kind of need the growth where we want it now. So I think that getting some funding and actually getting this off the ground and actually getting some people which are building these things on a

daily basis, I think we're going to see some great growth and we're going to get away from all these pain points which we're seeing now in terms of actually release times and not being able to devote the full day of work to it. So once those things go away, I think that Buttercup's going to definitely catch up and be someone to contend with. So just to harken back to Open Collective, you've got a, from what I could tell, a $283 estimated today's balance. So you've got an annual budget of $285. Yes. So I can see how that's

not going to scale to employees yeah i mean we also haven't spent anything on marketing really right so it's kind of hard to say uh right now like where that would go um and people have been really supportive already obviously doing that but of course uh if we want to say hire a full-time developer which would be the the first place we'd probably want to start i mean developers aren't cheap really anywhere you look so i think that like having having some some high level funding behind that's going to be going to be crucial to kind of getting off the ground if we had someone working even just full-time on buttercup that would be like an immense help for us uh pushing out new new features and getting these these low level integrations on mobile devices which are sorely needed yeah, I think that's the direction we're looking at taking at this point.

Just from an outsider's perspective, I'm not a domain expert on enterprise security, but it seems like having a hosted solution could potentially lend itself well to an enterprise play wherein you could go on-premise. Because if you think about what an enterprise needs or what plays well financially at the enterprise level, mission-critical things that are infrastructure

and security-focused, where they'll want to run it on their own networks and potentially play a premium to have a self-hosted version on their own networks. Yeah, potentially some options there. So definitely an interesting potential future. What kind of service will it provide? What additional features?

Obviously, it's going to be syncing without the need to have a Dropbox or an own cloud, but are there team features? Are there other things that you're thinking that will be offered that Buttercup Core or Buttercup, I don't know, non-hosted or self-hosted or cloud won't do? I mean, the sharing thing is

something we're gonna have to work on because uh the way that we've built the vaults is uh is is quite complex but we feel that like the sharing aspect of things is going to be going to be fantastic for us to actually have as a paid feature because i think it deserves that of course but at the same time uh having like an array of vaults where it's just kind of seamlessly synchronized between users being able to invite people easily having your family in there and then having the ability where people can modify the vault at the same time but it's still at the end of the day stored in the one same spot under the same encryption key and i think our vault structure right now lends itself

to being uh very very easily merged so like we have conflict management built into the core, which is going to play very, very well for sharing and also offline vaults as well. So for instance, if you're on a plane or something and you update a password or add an entry or something like that, and then you go online and then you want to merge your changes, these are things which need to be thought about. And I think that our structure actually lends itself quite well to that and to the sharing aspect. And of course, there's also the benefit of encrypted media, such as maybe you have like a photograph of your passport or something in your vault or your driver's license or something. And these are things which we also need to consider

storing securely. So yeah, there'll be many, many features which we will release, both in the free public open source version and obviously some to enrich the business side of things. But primarily, yeah, it'll be team-based. It'll be hierarchical if that's what you choose in terms of your company structure. So different permissions for different vaults, maybe read access, stuff like that. So, I mean, there's a huge amount we could do there, but once we get off the ground and we have the free version released first, then we can look at what we want to do with the teams. I did see a notes field in one of your UI screen grabs.

Is there currently the ability to store additional metadata or non-passwords, maybe SSL certificates or API keys that aren't specifically passwords and use those in different ways? Not in a user-friendly way. We do support it, but we haven't updated the interface yet. That is currently in the works.

But yeah, we have an intention to first store basic things like basic text files, like SSH keys. But I think that one of the most requested features which we have yet to release is the ability to store media, like images and videos and documents. And that's very, very tricky because we're trying to manage a very performant encryption process on mobile and different devices. And when you're encrypting media, you need to be obviously very careful how

you transfer that around. And I mean, how we store that as well on a cloud service, do we bundle everything in one file or do we split the media based upon what they stored? So there's a lot of questions we have to answer there and we need to kind of choose wisely before we release that just to make sure that we have the future in mind in terms of performance one thing that's cool is you guys have an open source roadmap repo with an overview and all sorts of stuff in there so you're very open with regards to where this is heading but i'm just curious about you know as a side project that you work on at night after you're done you know doing your nine to five coding how do you prioritize how do you get motivation like what do you decide to work on

on a thursday night after you've just finished work like do you have a a prioritized list of tasks and you're just working down them is it whatever you you feel like, you know, sometimes it's like, what am I feel like working on? Right. Cause it's about fun anyways. How do you make these decisions? It's been the biggest learning, learning process of this entire entire procedure really just kind of figuring out what motivates me. This has been an amazing teacher in that regard because until you,

you undertake projects anywhere near the, you don't really realize like what is a super killjoy for you and what actually kind of really gets you up in the morning. And the crypto thing kind of started off, but you very quickly realize like, oh, this isn't so fun. I don't really want to come home and do this. So, you work on something else. That's funny. And I think that Buttercup has been a lot of that, actually. We've kind of worked around the edges to start with around the things that we love. And then at some point, you kind of have to build the meat of it to kind of get it going.

And it's been so much like Salah and I kind of bouncing things off each other, like kind of picking each other up. Like if we didn't have each other to kind of get through this, like without us motivating each other and kind of getting us psyched about what we're building, it would be so much more difficult. But I think it's about who you surround yourself with. And then it's also the feedback loop you give yourself online as well. Like when you're giving this to people and when you're talking about it online, it's setting yourself a realistic feedback loop for enjoyment. Like you're setting yourself realistic goals, not goals, which are too far in the future and kind of get the small things done and then kind of take solace in the fact that, hey, I got this done. This is amazing. And doing that over and over and over

again for days and days and days on end until you actually have something which you want. But it's just make everything smaller has been kind of the key for us. And it's worked, obviously, because we've gotten three large scale applications out and we would not have been able to do that if we set off day one wanting to build three large-scale applications. You have to start super small and just keep building on the building blocks and just keep focused and try not to go off and start something new every day. But that's been a huge battle for us. Focus is key. We learned over the years just how important focus really is.

It's pretty easy to be squirrel or squirrel or shiny object focused i guess which is sort of the anti-focus but geez i mean you know being able to focus on one core thing for the day or one or two primary things i like to call them you know what's my what's my primary mission for today what can i do today to make it successful and try to camp out there and once i've gotten that done it's like okay now i can move on to you know more squirrel based operations where it's like what's the most pressing or shiniest thing that i could do next now that i've done my primary thing i had to do today to make today successful and and it also comes down like build something that you want to

use something that you want to do like don't build like i always think that like so many people say like okay you should probably find a market market for what you're actually building if you really want it to be successful, but I'm completely opposite. Forget the market, pick something that you want to do and then find the market later. Obviously not really the right way to go about things in terms of business sense, but you're not going to get it done if you don't really enjoy it. You have to love what you're doing to actually to get it there. So kind of pick what you're interested in first and eventually you'll come to the point where actually build something that you want to actually use. And the day where we kind of like woke up and realized that, hey,

I'm actually using Buttercup as what I wanted it originally, probably like a year later from when I actually set out doing it, was like a really kind of like a woke moment for us. It's quite rewarding to get to that point already. And obviously we've kind of gone past that and we have bigger goals, but it still comes to the fact that every day I use the application, which I started building. And I think that's such a rewarding experience, no matter how big or small that is. So I think that if you can pick something which you want to use and want something that you want to do, it's going to mean success in some level of measure. Well, let's tee things up for the audience that's listening, because I'm sure that there's at least 20,000 people psyched to hear this show and hackers jumping at the bit to come and help if they can.

So you've got roadmaps, you've got goals, you've got your own focus. So if you can focus yourself, can you focus others? Maybe, I don't know. We'll see. But, you know, how do you help on-ramp others to come in and help out? Is this a project that you're inviting others to come in and help? Or is it primarily around security-related things? How can you invite the community to play a part to ensure that Buttercup has the next step?

Yeah, I mean, I think that, like, at least everybody, which is obviously kind of at all interested in tech and stuff like that. I mean, you use computers every day. I mean, you probably have hundreds of accounts and this is something which affects all of us. It's like, how easy is this process going to be of staying secure? And it should be enjoyable, I think, because it's something you do so often. It should be something which you don't think about or something which you look at and go, yes, that's how it should be. That's really nice. And we want Buttercup to be that. And it can be everybody's. It's kind of like we can all benefit from this process. So, like, yeah, we really appreciate people jumping in and giving

us their opinions and redesigning things and saying, oh, you know, you could basically remove three or four clicks from this whole process. Like, we would love that. And there are so many things that we haven't thought of. And so many people which have had these really strong opinions over their entire time using a password manager, which they bring to Buttercup and it just blows our mind. It's just like, this is fantastic. And I think that Buttercup is a really low level where they can just jump in and kind of just give us their opinions and actually see them implemented quite quickly. I mean, there's probably not a huge amount of places where you could take these to actually

have some real effect, but we're willing and waiting to get these great ideas and to move forward with them because I think that Buttercup is in the perfect position now to actually have all these things implemented and tidy it up and add all these cool features which are going to make it a pleasure to use. I like too how you got it in your issues, at least for Buttercup Core where you've got effort, priority, status, and type in terms of tags and then you've got like obviously for the effort you got you know low medium high same thing for priority low medium high and status being available or unavailable or

if it's a an enhancement the type is enhancement or something else i'm only seeing enhancement for type but that's kind of interesting too that you've made it a little easier to, to jump in there. So a lot, a lot of these issues, uh, us large generator, is it community generated? What's the, what's the makeup of some of these issues and how do you, how do you drive people to the right issues and invite them in? Yeah. Um, that's, that's, that's, uh, it's, it's been quite a big learning process for us as well. I mean, core is probably the oldest repo in Buttercup, so it's probably got the most mature label set out of all of them.

And I would say that Core has been probably mostly our internal issues, I mean, with a few contributed externally, but I would say that the desktop is the complete opposite. It's definitely the majority of the issues are from the community, which has been really good. So their opinions, their discussions, their ideas coming from them, and very few are actually ours, which been really good so their opinions their discussions their ideas coming from them and very few are actually ours which is really good so obviously you can see a lot of people using desktop application saying that this is a great but and then they're making a couple of issues and we get a

lot of PRS there we have localization working with a tens of languages on the desktop which we still need to integrate into the other ones so obviously the second that we open up the localization we had like maybe like five to 10 PRs immediately for different languages. That was fantastic. So, I mean, yeah, it's just, we're trying to basically make it easy for people to find it and kind of get into these. And we've tried a couple of times kind of marking like these are easy to start issues if you haven't looked at Buttercup before. We're on Spectrum, which is an amazing chat system, which allows us like threaded discussions in a little bit of a faster manner.

It's like a little bit easier to use than GitHub and easy to connect with. And the guys over at Spectrum have been giving us a pretty good rundown of how to use this system and kind of giving us a lot of publicity there. So we have several channels between Twitter, GitHub, and Spectrum where we can actually kind of like help feed people into the right areas if they want to help and share their ideas. We're coming close on time, but I have one last question and a suggestion. So we'll start with the question.

The question is, we haven't asked you about the name. Buttercup. What's Buttercup? So in 1987, there was my favorite movie was released called The Princess Bride. Oh my gosh. Yes. Fantastic. Absolutely love that movie. Very, very special place in my heart. Watched it day in, day out every day for several years. Just fantastic. You're either a Jack Pratt Roberts, something Pratt Roberts fan or a

very romantic person. which are you? No, no, probably the former. I just, I just think it really spoke to me. I think I actually, funnily enough, I was actually a huge fan of Carrie Ells at that point. It's just like the whole, and Mandy Patinkin, obviously he just kind of really, really stole that part. And obviously Andre the Giant. I mean, the whole cast was just incredible and the movie was amazing and definitely a very warm and happy movie. And because it was so fond, I felt that the name kind of came from there. Buttercup was obviously the name of Robin Wright's character and that just kind of really spoke to me and the name stuck. It was

unique. It was kind of a little bit, it sticks on the mind and it was kind of used jokingly at the start but at the same time it it did just stick so yeah uh salara was very accepting of it and it just took off so started there and it's got a pretty pretty funny beginning oh my gosh the most amazing movie ever i mean how andre scaled that wall i will still never know all right so that's a good answer for the name then. So we'll close with a suggestion then. So you mentioned your distaste for marketing, at least in terms of choosing to code instead or tackle a to join or email or something like that. So they can say,

Hey, I'm kind of interested in your future sync platform that you plan to have, because one, it would help you with marketing it really easily. And then two, once you do get to it, you got a nice base of people to say, Hey,

we're open for business. Come check us out. Cause I mean that I'm ready. I want to add myself to that list. So this is kind of self-serving, but you know, we're here on a podcast and might as well make it open for business. Come check us out. Because I mean, I'm ready. I want to add myself to that list. So this is kind of self-serving, but you know, we're here on a podcast. We might as well make it open for everybody. But I'd like to add myself to a list that says, hey, when Buttercup has my Buttercup up and running fully for syncing and hosted, or maybe even future team services that I

can check it out because that's the key feature that I personally need. Yeah, that's a fantastic idea. And I think that's definitely going to be an important first step for us. We actually want to have a select group of users actually alpha test the platform as well. So I think that that list would also play into that very well. So yeah, fantastic idea. I think that we'll definitely chase that one. There you go.

Well, Perry, thank you so much for your time today, man. It's been a pleasure talking through this with you. Clearly, you're passionate about it. We, we also share your passion for the desire for a more secure, more performant applications like this. I mean, thank you so much for sharing your time and thank you for doing what you do. So thanks for coming on the show. Thank you so much for having me. It's been a pleasure, really. All right. That's it for this week's episode of The Change Log. Thanks for tuning in.

If you enjoy the show, if you got any value from it, do us a favor, go into iTunes or Apple Podcasts, rate the show, review it. It helps us get ranked up inside those indexes so more people find the show. If you're using Overcast, go ahead and favorite it. And of course, tweet a link to a friend or share it wherever you might want to. Huge thanks to our awesome sponsors and partners, Rollbar, Linode, and GoCD.

Also, thanks to Fastly, our bandwidth partner. Head to Fastly.com to learn more. And we're able to move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. We trust Linode because they're fast. They keep it simple. Check them out at leno.com slash changelog.

Today's show is hosted by myself, Adam Stukowiak, and Jared Santo. Editing, mixing, and mastering was done by Tim Smith. And the music is done by the ever awesome Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for changelog master. You'll find it. Subscribe, get all of our shows, as well as some extras that only hit the master feed. Once again, thanks for tuning in. We'll see you next week. I'm Tim Smith, and my show Away From Keyboard explores the human side of creative work.

You'll hear stories sometimes deeply personal about the triumphs and struggles of doing what you love. I got really depressed last year. And the reason it was so hard is because basically everything culminated at once. All these things I'd been avoiding, all these things I'd swept under the rug, they all came out at once. New episodes premiere every other Wednesday. Find the show at changelog.com slash AFK or wherever you listen to podcasts.