Here we go, Warren, how are you just jumping right into those personal questions?
I know right who? I can't remember who the guest was.
We had a guest on it was earlier this year, and I asked her because we do like a little prep before we start recording, and I say, you know, there's no like stumped chump questions. Everything should be laid back in conversational. And I asked her how she was doing and she's like, I thought you said there would be no hard questions.
I was like, oh my bad.
I had the right answer here. Actually, I was planning for this the whole day and then you went and you asked me, and I totally forgot what it was that I was going to say here, So.
You know, thanks for that.
Yeah, yeah, that's that's why I'm here, joining us back after a long break. And she just dropped offline. I'll just foreshadow it. Jillian is back as a co host on the show, but she's had audio issue, so she'll be joining us later in the episode, but then also joining us today as our special guest, Brian valaalonga from Doppler.
Brian, how are.
You I'm doing well? Great to be here, dude.
I'm excited to have you looking forward to this conversation because we're going to be talking about secrets management, which men, there's so many different ways to deal with that, so I'm excited to hear what your take on that is. But before we get into that, could you give our listeners a little bit about your background and how you got to this point in your life.
Yeah?
Sure, So, I mean, I've always been a founder at Hearts Dopplers. I think startup number eight or nine. It's been quite a journey, a lot of a lot of companies that now looking back probably feel more like projects.
But yeah, a lot of failures along the way. So I'd say is just don't give up.
But I think for me, where Topla really got started was I was working and I was working on a side project at the time while I was at uber in my free time, and it was a crypto machine learning marketplace, kind of like all the buzzwords in one and I could not funding was guaranteed, right, you would think, and you would think that customers were guaranteed. But turns out I was just a little too early and none of that was guaranteed at all. If anything, it was
really freaking hard to get it off the ground. I felt like pushing a boulder up a hill. You move one foot forward and slipped five feet back from exhaustion.
It just sucked.
And which is funny because like, now there's a company today that just like is enormously successful doing like ninety nine percent of what we did. But that's just how it works, Like you gotta time it correctly, and we didn't.
But yeah, I was working on that for a long time and I was just getting frustrated, and so I realized at some point I was never going to be able to get this thing off the ground, and so I started looking at the proms I was facing while running it and managing environment variables, API keys, database URLs, and other sensitive information that typically is used to like can figure an application, like I kept struggling with it
felt really weird to share with the contractor. At one point in time, it's like, oh, are they gonna walk away with my crypto keys that I can't like really change, and then all the customers are relying on us to keep securely and then like we drop crypto one point, and we were using like Stripe for pay and processing, and we had the stripe production key in staging the Stage one and PROD and took us a month to
realize why we weren't doing any transactions. So we were up in an operational and could not do a transaction, and it took us so long to figure that. It was just like so many of these like like face palm moments where it's like, damn that that sucked.
And so I.
Go back to I go back to this in San Franisco, to this dinner that had a whole bunch of founders and developers, and I'm like, hey, am I a shitty engineer, is a world broke? And I just can't tell anymore. You tell me real problem. And they were like, yeah, this is a real problem. We're all struggling with the two.
And that's what kind of got us started. And after that we started building the MVP, which took a couple of weeks, and on the fourth week we got some set of customers and then we were off the races right on.
I mean, that's a quick turnaround to have to be onboarding customers on your fourth week.
Oh yeah, we were. We were like, speed is the only thing that gives us a permission to survive here these not We're going to get slaughtered, And so we just moved incredibly quickly, like there were many many days with no sleep. I mean, Doppler was you was our we were the first customer of our own product. Before
we even had a dashboard in a UI. We would just only use it with the with the API, and whenever I needed to change secrets, I would literally go into the database and edit the secrets before the h the encryption step.
So it's like, right on, that's awesome.
So just to put things in context, you kind of hinted to it, but let's clarify what we mean by secret. You mentioned, you know, API keys, database, URL's passwords. Obviously, what kind of things fall into the scope of secrets management.
Yeah, this is a great question.
I generally recommend it's anything that configures the application, and I know that can go even into a little bit of extreme, Like some people on the call could be like, what about my port? Is my port really a secret? And my answer here would be yes. And the reason why is because if you have to start making a decision about what's a secret and what's not, then you're you could be wrong. And the one time you're wrong. That could lead to the company dying or some like
crazy event happening. So instead, I say, my view is, anytime you're configuring an application with a variable of some type, an a pike or poor to a logging statement, whatever it is, treat all of it the same and treat
it all as the most sensitive thing possible. That way, you're kind of offloading this decision making and you're saying, Okay, we're just gonna do the most cure thing by default, and so we're reducing our chances of a bat event happening by by what every engineer now kind of like randomly deciding what's a secret and what's not.
That's a good point because I think that adds to a lot of the complexity I've had managing secrets in the past, is defining Okay, we do our configure variables over here, but then our secrets you're over here. And you've just in hindsight now that you said that, I just doubled my workload for really no no real good reason.
And usually they end up being like two completely different systems, and so now it's even harder to track of like which one to one in which system it's not like it's like there's like a branching point that you like can like track that and have a review around it.
And so a lot of times now you're just hoping.
And praying every engineer in the company kind of just makes the right decision at all times, which, like we're all humans, We're most like at some point in time, someone is going to make a mistake. The problem is that mistake could cost the company big time and.
All of its users.
Yeah, so a really important point there, I think is not really worth like really worth diving into for a second. So I really like this topic because I actually have a conference talk that I've been doing for a couple of years now specifically about teaching about secrets management and all the different strategies out there, and there's like quite a few of them. Secrets manager, the cloud providers have key management services, there's like open source faults and whatnot.
And the sad story is the only real strategy that works in theory is something like bring your own keys, where things are secured by default, and the number of providers out there that support that, Like I know we do at authors like let our customers bring our own keys, like the number of customers out there that are working with a provider, even like something as important as Strife or even some of the cloud providers, they don't support that, Like you can't bring your own keys to any of
those critical systems. It's sort of ridiculous that this is the world we live in of only bad options are available.
Yeah, it is.
I mean I would say, like where we really now? I agree with you that it's really we're living in a world of bad options. Doppler tries to and obviously I'm biased because I found Adoptler. I'll just call that out, but like I think that just so anyone knows, but I do think that, like you can get to a pretty good state.
And then I would say where the.
World's going in a second, one I can talk about is like the ideal state, but at least a Doppler. We went through a lot of iterations, like we rebuilt the product from scratch like three times, and what we realized is that you're never gonna be able to get developer ad option unless you make vegetables taste like candy and vegetables being the security can you be in the developer productivity.
Developers are never gonna use it.
Developers are children in this scenario because it.
So right, but yeah, you gotta, you gotta. It's it's really around like are are you taking energy from them?
You giving them energy in a way, right, Like developers want to stay and flow state. They want to be super productive, and if you can help them be more productive, if you can give them like a tailwind, then they will love your tool and they'll use it regardless of the security benefits. But if you give them headwinds, well they're gonna run away from you because they don't like that, understandably. And so for us, that was our trick to making
it a tool that developers truly loves. The company gets security benefits is give them about two hours a week of productivity games and there's a whole host of ways we do that. We don't have to get into that on this call, but like that was the fundamental reason that I think doubt war has become somewhat successful in helping developers want to manage their secrets better. It's not about forcing them to, it's about getting them to want
to do it. And then I think I mentioned before, like where it's going in the ideal state, we're moving to this world of like identity based seek, like identity based authentication. And so the idea here is like with like we have something like pass key, where like you can scan your fingerprint or scan your face and get into another system with just your email address and that like fingerprint or that face ID, and that's called passkey.
It's getting rolled out across like all these major sites today. That's gonna start happening with secrets like API keys. Instead of having this API key, you'll have like this identity and so the fact that you're on your laptop or in an AWS cluster, you'll automatically be authenticated to stripe in the future. And that's like a really powerful thing.
And my guess is it will be like a little bit difficult to set up without like a proper secrets manager like Doppler, But once it is set up, it'll be seamless, like you're just in the machine and it just works. You're automatically authenticated and there's nothing else you need to do, and there's now no worry about actually losing this secrets, which can cause a breach or anything like that.
It'll just be secured by default.
Yeah, for sure, So that scenario sounds to me a lot like or like very similar to the open id connect platform. We use that a lot with our GitHub integration. So the way that works for anyone who's not familiar with it is GitHub. When your GitHub action runs, it sends an authenticated request to your AWS environment. ABS validates that request, and then issues back a temporary set of credentials tied to a specific role that has been set up.
So now your GitHub action has permissions inside your AWS account to do only the things that are permitted by that role and only within the timeframe set by those keys that were issued to it. And it is a pain in the pain and he has to set up, but like, once it's set up, it's so seamless and smooth and you never have to you never have to lie to your security guys and say, oh, yeah, we rotated the keys.
Absolutely.
I really liked that you brought this up, actually, because the canonical name that you called it was open id connect, which isn't wrang and the like GitHub and AWS jumped on oi DC as the acronym for it for making this work, and that's not what open idconnect is at all, but that's what all these providers are calling it the canonical term ridiculously is actually known as workload identities, and
they're sourced from the some trusted location. So in this case, you're having your aw's account trust GitHub as a source, and then your workload is getting its own temporary identity which can authenticate to your cloud profighter. And yeah, for Charlotte, this is the dream come true of bring your own keys.
Workload identity is being able to be passed from wherever you're running to whatever the third party application is that you're integrating with without ever needing to do anything else other than potentially sharing a public key exchange, because I think that's still going to need to be a manual step by everyone involved.
How does that line up with the future as you see it, Brian.
It's very close. I think we need some.
Player, and I think Doppler is going to be that middle player that kind of acts as like the network highway for everyone. So I'll give you an example. Let's just say you're an AWS. We're gonna make it super seamless to be connected from AWS to Doppler, and so anytime you're in AI of US, you're automatically authenticated to Doppler with all the right roles, permissions and all that stuff.
And then you're gonna also want that because you're a Doppler to be connected automatically to Stripe, to Twilia, to your database, to the ten thousand other services you're using. And so now you're gonna get this beautiful world where you don't have to configure all these individual relationships painfully
in AWS. Instead, you'll set up one relationship with Doppler, and then Dopper will kind of give you a seamless way to like manage the rest, and so you kind of get this like one to one and then one
to many. Right, So, the fact that you're an a of us, you're not authenticated Dopper, which means you're authenticated to Stripe, and it all just kind of like works seamlessly in the background, like Dopper kind of like fades away and it's like just opera and completely in the shadows and giving you that authentication to all the services that you care about. And that's kind of like the world we see ourselves playing in in the future.
Right on what.
You know, did anybody like ever use party lines or anything when they were a kid and you'd have to call it and they would direct you to where you needed to go. And then in the background, you know, like the nosy neighbor would be listening in on just everybody's call and would know everything that was going on.
That nosyas nosy neighbor was my grandma. She was always on their listening.
Yeah, I had I had some mounts like that too. They always knew what was up. And let's stop for Doppler knows what's up too.
We try as hard as possible not to know what's upment you're looking for.
Right, Nice save Brian Nice.
I think in like reality, we we'll end up thing is like we will like offload the like we'll giving because while the relationship with Stripe or any of these services, it'll all just get encrypted at the end day, and we'll just try to make sure that we set up the encryption in a way that we can't possibly like read the output of because I like, for everyone's benefit, we don't want to be able to see that data.
Yeah, I mean, I think the biggest problem today is that those serve, those products, those applications that you really want to have protected, have some of the worst security and ever. Like you used to Wripe as an example, and I'm not it's not the worst one there is, but you can't even like I can't even get SSO to work with Stripe, like they they don't support it anymore. Like literally Stripe does not support SSO, And I'm just like how, like why not? Like I want that to
be integrated into my into my seam system. I want to be able to authenticate there and have two factor off through whatever provider I'm utilizing, and it doesn't support it, so like they don't even support that baseline. So I have very little faith that in the very near future strife will support workload identities to.
Be able to prove that. But I mean, if we get there, that would be great.
So far, the number of providers that really support this is just absolutely minuscule.
So I have two thoughts around that, because we put a lot of time into thinking about like how do we get the community to My gut reed on what's going to happen is eventually there's gonna be an open protocol that everyone can.
Like adhere to that's like pretty easy to use.
Probably they'll be like SDKs and all the popular languages, and then some company or a band of secret spanagement companies are going to put out a leader board and they're going to show all the companies that do support it. It will be kind of like the SSO tax website, and you kind of just like want to be on that list or don't want to be on that list, depending on how it's structured. And my hope is that like that will create enough peer pressure. And then on top of that, I'm only.
A bet a lot of money that, like as.
AI gets more and more sophisticated and can go from like being a co pilot to like a full blown engineer, like AI engine years and I'm talking about humans that are using AI to engineer. I'm talking about an AI
that is fully capable of being an engineer. Those those AI agents are going to want identity based authentication and they will push aggressively for it, and I bet that's gonna, like those two things together will probably lead over time to like all the big players eventually like doing this just because they have to.
I love your optimism, Like it's just it's just so great.
I mean, because like today we see so many.
People putting credentials in plain text, let alone whatever else we're going to call a secret, So getting them to, you know, go down a different path is a huge challenge there. And the other problem is like there is a bit of a standard already around the providers where they.
Can use it.
I think everyone could stand up any sort of open id, but it doesn't give them a lot of like, it doesn't give them money, like, it doesn't help the businesses grow to support that as an optional. Less some bigger players as yeah, we like, if you want us to use you, you have to support this. And I think the great example of that is you brought up a SSO tax, which I think does the wrong thing. I feel like it's positive reinforcement for all these companies that
do the wrong thing. I see this leaderboard of all these companies, and now I read that name, and is there something known in psychology is called preferential attachment. I see this company listed there, and I forget why, Like I don't remember SSO tax and you remember the name. And then months later I got a call from one of their terrible salespeople trying to harass me on my personal phone number, saying, hey, do you want to buy our product? But I heard that company name before, so
now I'm tempted to actually buy their product. Even then, the reason I know about them is because they were listed on a site that says they did the wrong thing. We see the same thing happen with vulnerabilities and data leaks. You learn about companies because they had a data leak, and that just actually enforces how great they must be, because then they send out those emails thing, oh, we're committed to security, we're going to change things and uh,
and that gives you. That gives you some confidence in this particular company. So I think there's a special message that has to be sent that actually does the right thing. Having a group of standards can work, But if the companies haven't taken it on themselves to actually implement these, I don't like. I don't see magically that it's going to happen in the next ten years.
Maybe another way to I mean I used to think the same thing about Pasky's, but now it's getting rolled out. So but on the flip side, also, this could be a place where like war compliance comes in, like they added to the compliance bodies of like if you issue out secrets, you have to you have to support these methods.
So let's take a quick step back and talk about like what are some of the other common strategies that you've seen for managing secrets, just to help people put into perspective or like recognize themselves as owners of this problem even though they may not recognize themselves as that group yet.
Yeah.
So typically the way I see it is they're coming from a couple of different worlds. One is they're using something called an eb file or like a plane piece of text file that has a whole bunch of secrets on it. That's bad for a number of reasons. One, those secrets are unencrypted on disc, so like they're very easy to like steal. Two, they are now shared in insecure ways like slack an email, again another breach point that can happen. And three the manua to be coordinated.
Like imagine if you have a ward doc and I have a ward dooc and everyone else on the team has the same wartock and we're all editing in real time before Google docs or Notion, and we have to all keep it in sick.
That's like quite hard.
So another thing we see is like they're only using cloud providers, which generally works for production, but then they're using like eethos eb files for development, and like where the problem really gets bad is like they can't answer these like fundamental four questions. The first question is like do I know where all my secrets are?
These?
You cannot possibly protect your secrets unless you know where all of them are.
Do I have a point? Right?
Do I have the ability to like access control these secrets because if you can't put permissions around them, again, you can't protect them. Very hard to do that when everyone's just sharing files back and forth. There's no real permission model.
There, right?
Three?
Do I have logging and auditing around every action that's taken, including reads?
Right?
Do I know every time someone has read a secret from development of production and everything in between? You'd be surprised how many times production credentials and then end up in a development environment. Right, So you need a tract development too, Like you'll see this all the time where like developers like, oh productions having an outagy, I'm just gonna like create myself with produt E and v file
and test production locally real quick. Now you got proud secrets on your laptop, what are you gonna do?
Like?
And then the last one is when you do have a data breach because something went bad, can you stop it very quick and very quickly in the orders of like minutes, Like if you think about how fast data can leave your system, right, like data can leave your system like bigabits per second right from a tows, Well that's the case.
A couple of minutes of.
A data breach is actually a really really big deal at this point, ours is like an like disastrous. And so if you can't answer those four questions confidently, not like oh yeah, I can run a piece of paper, but like I am extremely confident I've bet my job in my life on these on answering these questions. Confidently you have a problem and now it's on you to fix it.
I like that, that's pretty clear cut. I will not go on record answering those questions.
Definitely be my life there, Like I.
Think maybe much for me, I mean since I since I guess that leaves me and uh. I run a technology company that focuses on providing log in and access control for applications that our customer is right, and so I feel like secrets is super important for are both
us and are our customers there? And we're pretty extensively using complex crypto and things like key Management Services KMS and AWS and some of the other cloud providers to do that at location, that site based encryption there, and I definitely don't trust a lot of people to get that even close to correct.
Yeah, it's hard.
It's really really hard, especially if you're like building I found that if like again, you got to you gotta get the productivity part, like if you got to make it super simple and easy to use, where there's no footgun moments, you can't shoot yourself on the foot The default easy path has to be the right path. And that's that's probably like the hardest part that I found with building this. It's like, at the end of day, at least for us, it didn't feel like building the
tool that was secure was a hard park. It was like at our frontish foundational level of like the infrastructure layer, but building it so that the end the end user experience to the developer being secured by default, that part was actually really hard to get right because also because like every developer has like a differences in mind, and so like now you have to like support like a very wide variety of different setups and they all have to be secured by default, and the most secure thing
has to be the default thing, and so like talking a little bit about like what a solution would look like, even if you're not gonna use you don't have to use Doppler. That's not my job here is to like sell you guys on that. My job here is to sell you guys on the problem, and then you guys should go solve the problems so we don't keep having data breaches because the.
Number is only rising. It's rising fast. It's like like a high growth stock right now.
What you need is you need a service that centralizes or a system that centralizes all your secrets in one.
Place that's encrypted, super super important.
You need a system that does not encourage secrets to be on disc so you're reading and if you're reading from the environment, you immediately clean that up from the environment after your like frameworks and libraries at booted up. You need a service that has access controls and auditing built in, with a really strong audit story there. Ideally can also push those logs into a centralized logging platform like data Dogs, Blowing and Zeo Logic so you can do more robust analysis on it.
Set up learning, you.
Need the ability to automatically push the secrets when they change into your infrastructure, so there can't be a human step involved, or like, let me file your ticket and wait three weeks for this ticket to get closed, because your code's going to get rolled out automatically. So by default, even without the security problem, you have an outage guaranteed because you have this race condition of a human filing fulfilling a ticket versus GitHub automatically rolling that out to
AWS or your infrastructure. Right, they're like one's going to move a lot faster than the other in the order of like seconds versus like days and weeks. So you have to have it automatically rolled out, just like your code is. And ideally it has to be rolled out before your code does, so your code has it to consume when it boots up. And the last thing is you've got to be able to rotate your credentials, either
automatically or manually very quickly. If you have a data breach, you cannot learn how to firefight and firefight at the same time.
It's too slow. You have to have like your procedures down.
If you know what buttons you're gonna click, and you're gonna have to know how fast it takes you and if you're if the data breach happens and you're going to take minutes to hours to solve this.
Problem, you are in a really really bad spot. So you can do those things.
Whatever tool you use, you'll be in good shape or anythink I missed anything, uh.
Not at all, actually, but the thing that came to mind is like I'm wondering about. The corollary is like, you know what other solutions are there that are out there where you're playing in the same space, and I'm trying to understand like whether or not it's closer to say a secrets manager that one of the cloud providers offer, or open Bow or hashing corpus Vault are say you know your competitors or whether or not there's something specific here.
Yeah, So with the secrets managers from the cloud providers, those are actually partners of ours. So almost all of our customers are using a TOUS secrets manager and Doppler and kind of like the the mental model there is kind of similar to GitHub or get lab or developer pulls their code down, changes it on their laptop, then pushes it back up and then one it's ready to get released to production then get hub or will then push it to AWS, which has its own repository store, and.
That gets deployed. Dopper does the same thing.
We'll like allow you to pull those secrets down, change them, and then when you're ready to push them up into production, we will push it to a to B secrets manager or its pramer store or whatever, using on as your GCP, and then that will then push it into your infrastructure. And so it's kind of like the same model there.
So we are very closely partnered with the cloud providers and most infrastructure companies we support, like I think forty different infrastructure companies right now, and then on the like
even Kubernetes resupport, which is in the company. It's an open source initiative, but we support that pretty extensively too, And then on open VOW, I would say we're more closely competitive, but I would argue that it really solves different problems than we do, Like we're looking specifically to solve secrets regarding API keys, database riels, and other things
that configure your application. I would say open Bow is more like a generic key store and like you can put anything sensitive in it, like a photo of a passport, or social Security number or some medical records, not things that are like deeply connected to your application and your infrastructure. I would say they're missing a lot of the layers going back to that, like make vegetables tastes like candy.
They squarely have the vegetables, but there is no candy involved, and without the if, you're not really solving the problem. And so I would say it's kind of like Dropbox versus Amazon S three. They both do storage, but like like one is like here's some APIs, go figure out what to do with it. The other is like a whole end end experience. It makes it super easy to securely store managed secrets. And that's where I think we
fit in. So while they're competitive, i'd say we're almost operating in different market, so like we don't really see as hyper competitive.
That makes sense.
One of the things you keep coming back to that I really like, it really resonates with me, is making the vegetables tastes like candy and making the right thing the default thing. I just think that works so well because like your target customers, not just yours for Doppler, but like mine at my organization. You know, I support the engineering teams, like I try to put in just guardrails so that they can do whatever they need to
do to get their job done. But then I've got guardrails in place so they don't accidentally do something that they didn't want to do, and so they by default they end up doing the right thing even when they don't know what the right thing is.
And I think that's so important to.
Get to get that right to have adoption so that you don't have to add this extra layer of technical expertise and competency on your developers to do the job that you hired them for.
One hundred percent agree, Like I would assume like almost every developer you're going to hire is coming with positive intent. They want to do a great job. They want the company to be secure, they want it to be successful. But a lot of times if you force the question on the if you force them to answer the question of like is it secure, is it's not? What's the best way to secure this? They may not get to the right answer just because they don't have that expertise.
And so it's important to kind of like abstract that all way. And developers love abstraction. They love SDKs and frameworks this is just another one that just equals security. Right, So yeah, one hundred percent agree with you. I think one thing we haven't chat about that is worth calling out is like why should we care? Like why is everyone on the call? Why should they care about keep
being the secret secure? And I know we've talked a lot about data breaches for companies, but a lot of times, for me at least, it feels like the company has a data breach and they get a slap on the wrist, right, they get some fine that they can pay with like one day worth of revenue. They maybe get a bad press article that turns into a good press press article later in their minds, as Warren was talking about earlier, because now they remember the name, and but like, what
is the actual real impact here? Because that doesn't sound like a lot of negatives right there. That almost sounds like not that bad. And I think the real risk
is actually to the users. Like it's it's so easy to forget that every time that we talk about like gigabytes or terabytes of data, we're talking about usually people's data, like real people to your customers, and they are trusting you to keep their data private, like to keep their private data private and when that when that breach happens, you're breaching their trust because that private data becomes public and there's real consequences to that.
I actually have a real personal story that scared this shit out of me.
I just moved to Austin for anyone who cares, and I took my mom out to some barbecue and while we were there, I got this call. And the call it was from someone who claimed to be at the Texas Customs and Borders and they called me and say, hey, you're being federally investigated. We found a package that has illegal drugs and money in it and you cannot hang up from this phone call. Everything's being recorded and it
will be used against union court a law. And I was like, oh shit, this is a day my life just falls apart, Like like I legitimately thought I was fucked that day?
Am I allowed to say that? I hope you guys gonna end it?
And one of us in this group continuously drops F bombs.
I'm not going to call.
That person out. Yeah we never should.
Uh. But they started asking me all these questions about like where, like have you been at this address?
Have you bought these things?
Like that kind of stuff, like stuff that you'd feel like owly the government would know, like really owning the government would know. And like this went on for like forty minutes where they were just like asking me questions and I was validating myself on and I was with my mom. My mom and I were both freaking out, and at some point we bring on the company lawyers to like really make sure like I get my I probably should have brought them on earlier, but I was scared and.
I just felt so real.
And it was only until like an hour and thirty minutes in when our lawyer when we all caught them slip up on something, and it was like my lawyer started pressing them pretty hard, and at some point they got frustrated and their accent kicked in Texas accent to like some other accent that I that I was like, you are not from like America.
And at that point we realized we were getting scammed.
But they were only able to get to that point of trust because of all the data that had been breached in previous data breaches. My data has been in like ten data breaches or so like including equal facts, and so they just had this rich history to lean on to validate who they are as like an authority, and I trusted that for like an hour and a half. And like I have security training. I run a cybersecurity company.
I can imagine my mom, my, sister, anyone else who has not had security training, like actually go the entire ten miles and give them everything, and they wake up tomorrow with like a huge amount of social security problems and like they're at bank count strained because now know everything, and like that can happen to real people all the time. And that's the real cost that we pay when we mess up and we have a data breach.
That's a great point because yeah, like you mentioned, you know, from a corporate level, there's it's almost a net positive to get a data breach because the fine that you pay actually turned out to just be like really cheap marketing is the way it comes out. But like when you tie it back to and think about like your mom or your your sister or people that you know, and you can make it personal like that, that's actually like it feels like good incentive to take this seriously.
So I think there's a couple of things there that are definitely worth repeating. The first one.
The first one's Brian, what was your social Security number?
Again to point out real quick, like the fens are going to come to your door, not call you, although that would freak me the hell out, and I don't I don't know that I would consider that on the phone if I just got a call like that, But for any anything else, you know, if this is a scam that's going on, I'm pretty sure they're just gonna come. They're gonna come get you.
I know that now, right, Yeah, yeah, Like, just as soon as the worst a call is that you get, no matter what it is, just hang up first. That's that's the number one thing you've got to do. Uh, if you like, it doesn't matter what happens, You're not going to get penalized for hanging up the phone.
I mean, there's no way.
I And that's the whole point. They try to keep you on the line because as soon as you hang up, it's it's actually over for them. The number of times they have to call back will be a problem. So for sure, just just do that and uh, if they don't call back, then no problem.
And if they do, then you know, you can continue.
It from there. If you're so worried. If it's so critical for them to figure out what's going on, they for sure would call back. Yeah, so that's certainly one of them. But on the cost for companies, there is a huge aspect here that So my CEO actually did a talk couple I think last year about the ROI on security and she joked that the ROI actually stands for a return on incident because it's so beneficial to actually have this happen for you. And the thing is
that it really depends on where you're at. So companies in the United States, in Russia, and China get attacked the most. It doesn't matter how big you are, how many customers you have, it doesn't matter your scale or your size. You will for sure get attacked. And without these practices in place.
You will for sure get breached.
The other thing that's really interesting is there's a lot of countries that just don't care about punishing you. So like the amount of fines that you get because of like say GDPR, you can actually go look it up. They're incredibly small, like sub one hundred thousand in most cases for mass of incisive. There was one recently where the company did get.
Sued out of business though, So that's funny.
And the other thing is that so it's good, you know, I felt great that you know, someone did something wrong and they really took the brunt of the punishment. There.
The really interesting thing here is being a company in Switzerland is there's no professional there's no punishment from the government for companies from corporate level if we perform or have a security breach that's a result of executive negligence, there's up to like fine personal fines the government will charge you with and there could be other legal repercussions as well. And that's just so ridiculous. And if you work in it tar in the United States or in
any NATO country, that's also personal fine. It's it's up ten million dollars and ten years in jail for having perpetrated sharing sensitive data that is regulated. So like it's not even like the company is potentially at fault there. They don't care. The company for sure doesn't care. But you as an individual, like there actually could be real repercussions for you.
Yep, absolutely, Like we share this with sometimes our customers all the time of like, it's real negligence if you don't manage your secrets. You can't just like look away, right, because again, every single time sometimes up for your website or does something, they're trusting you, and that trust is basically broken if you don't actually manage the key to your digital kingdom. It's like, hey, ere, hackers, take the keys. That's what you're basically saying, if people protect them.
Fair point.
I think another thing, like, I think another thing that probably is an additional challenge to this is the level of effort required to get from where I'm at today in secrets management to like the ideal world that we're talking about here, because like the question number one you asked is do you know where all your secrets are some of the places I've worked in the past, Like that could be a three to six month project just
to answer that question. And so how do you get executive buy in to put time and resources towards that.
It's hard.
I think one of the first things you can do that's pretty easy is, like there's a bunch of open source secret scanners. Truffle Hog is one. Dopper will have one at some point, I'm sure get Guardians another, and you can just like put that in the codebase and it will. You can have it set up so never admits back out, so like you know that like whatever your findings are, whatever your code is, it will not go to Truflehog or gig Guardian. But you can just get a report and just put that as a check
in every repository as like a commit check. Right, So, before I can even push to get hub, I'm going to do a check to scan my code for secrets. And all of a sudden, if you can't push the production anymore because of.
That check, you're probably gonna start pulling secrets.
Out of product, out of out of code real quickly, and you're gonna always want to stay in this state of a green check mark. I EI there's no secrets found. And that's like one first way I think to like.
Really move the needle there.
That is basically free and it takes a couple of lines of code to implement.
It's really really quick.
Yeah, And I guess from there it's it comes down to like a campaigning issue where you start campaigning for support to get this as a prioritized project.
Yeah.
Yeah, I mean there's something interesting here that could be really helpful because getting it. So we talked about workload identities in there being a burden of responsibility on the API provider whoever they are, to make some changes. The one that actually helped us a lot at authris was we automatically revoke found credential so if one of our customers leaks those credentials online, we will find those automatically
and revoke them immediately. And you may be like, oh, well, you could break someone's production environment, and that for sure is true and has happened. And then we get a support like, oh my god, our production environment is broken? Why did authors do this to us? And the sound truth is yeah, I know, okay, it for sure happens. But the sound truth is that credentials that are found on GitHub take less than two minutes to become utilized
by a malicious attacker. Yep, that's it. Two minutes. So like, which do you want? Do you want your production to be broken or do you want all your data to be compromised? And if you look at it through the lenses of I like, well, you should be thanking us for you know, stepping in here and doing something. And the scanners are really great. They do this.
Yeah, do that too.
Sorry, I was just gonna say, AWS absolutely removed to credentials if you put them, say in GitHub, which I have no personal knowledge of them.
Really, I just heard from red.
I mean.
It's almost it's almost funny though, because there were a couple of people who wanted to do some experiments with the AWS credentials, and they were struggling to do them because every time they intentionally leaked their credentials to different places, ABS kept on revoking them. And they're like, no, I want to set up a hunting pot.
Doing here AWS and doing it.
Intentionally, we're actually doing and yeah, so like in our emails, we actually say oh, yeah, you know, please let us know if this was like actually intentional, and then we can try to figure out how to somehow exclude this scenario because at least they know that there's like a solution path here rather than just like automatic credential revocation. And then be like, but I really want this to happen.
What's going on. My credentials are invalid. Let me go create new ones and release them again to get up right like something happened there. I'd like to go through that five or six times before they learn their lesson.
We've done the exact same thing with Doppler. If you if there's a Doppler token found, we will automatically broke it. I think one step we want to get you even closer, though, is being able to have some secure way of scanning your secrets that are in Doppler to see if they've been in a breach. We do something similar today with passwords.
Were like, if you sign up for a Doppler account with the password that's been in a data breach, we actually you and we say you have to use a different password, and if you log in again and that in that time since creating your account, your password has been a data breach, we will force.
You to change the password.
That's pretty cool.
Yeah, I forced.
People to change it because Google tells me that about my passwords all the time, and I'm like, oh, but I'm supposed to be secure. Instead of just rotating, you know, like various things that I rotate through for passwords, they don't make me change it, which is which is a downfall for me.
Password one, password two, password three, Now I've got to remember password four as well.
I know, right, what am I going to do?
Use a password manager?
You want like a fifty character a long password that you could not possibly remember that's what you want.
So you got to be careful there, because I actually had to start keeping a list of all of the websites that told me that I could put a sixty three character password. But then when you sign up, but then when you go to enter it, it said it doesn't match because it's secretly truncating some part of it. Yes, So like it really starts to get annoying when you think that they support something to the level of security standard that you want and then secretly, under the hood
they do something different. And I have a I have a list of those companies that I've paid very.
Maybe that have you published it?
No, that's still private for the moment, and don't jesus, I got some I got some good stories here. So one of them would truncate your password down to twenty characters, but for the two factor off. What it would do is it would ask you for your TOTP.
Six character code and.
Or pen that to the end to make a twenty six character password and send that in the password field. So if your password was anywhere above twenty six characters, you would just get a wrong answer. But if it was somewhere between twenty one and twenty six, it would cut out part of the TOTP code.
And like it wouldn't work, and then you just wouldn't be.
Able to get in at all. And also what that does is it tricks your password manager into thinking the TOTP code is part of your password. And every single time I go to the site, it asked me if it want if I should remember that new password update. Please don't do that. Like, if you're designing a system, please stop using passwords altogether, honestly, Like we have this off by default for all of our customers.
They can't create a password.
Database unless they come and contact us and justify, like who their audience is, why they need this, and what sort of rules are going to put in place, because it's just so ridiculous in the corporate space, like con federated logins, oidc samill sso all of those are so much better. Please just use one of those and don't use passwords password Like eighty six percent of all vulnerabilities are a result of password usage, like simcard swapping, you know,
found in breaches, et cetera, et cetera. Like just please, like passwords are gone, like they're done, they're over.
I think everyone on this can agree with that.
I don't know you're still using passwords.
Or and I don't know that you're like, are you are you serious about that?
No, I agree with warn here. I think passwords should be done. Their time is come. I'm just agreeing with them.
So, uh, my CEO actually has another talk at q COON in November in San Francisco that everyone should go to if you're in the area, and she'll actually be talking about the fact you do need to have like somewhere between three and five actual passwords in your life. Unfortunately, like there's no way around that, and you probably should have ones that the Rendall Monroe correct horse battery staple or is it horse battery staple correct. I can never
remember the order of the forewords, that's the problem. But uh, you don't want to just use a set of path like words as your password, because now all of the brute force attacks know that up three to five words could be your password as well. So you got to
you got to make some changes in there. And uh, Apple actually has a pretty good strategy for dynamically generating passwords, where they make a bunch of fake words that are consonant vowel sounds that are strung together so you can sort of remember it and use that instead.
So that's pretty clever.
But I highly recommend like all those things with symbols and whatnot. It's it's just it's it's it's over, honestly, So three to five. If you have more than five passwords, you're probably doing something unsafe.
What about my pets names?
Oh, those are totally in scope.
Yeah, fantastic.
I mean for some like now, you've got to tell them those Callilli.
Which pets?
For those Jillian, it could be Eddie pet, it could be pets from like here to childhood. I think, isn't that a common security question?
Like yeah, what's your first dog's name.
Your first pet, first car, like all that kind of stuff. So I don't know if it's good enough for the security question, it should be good enough for my passport.
It's pretty goodly you brought that up.
I'm sure Brian has some opinions on this too, likes just reidelines of the eight hundred.
I do just come on the show and start trouble like I have.
Now it officially says now it actually if as like you like you shall not force password rotation, like we know, like that's wrong. For sure. Secrets are a little bit in the gray area of whether or not force rotation. Uh is required outside of expected data breaches, but uh yeah, for sure, like if you were forcing password rotation. Now there's a government that is more ahead of where you're at as far as good password hygiene.
Another thing that I'd strongly recommend is whenever they're asking for there's like recovery questions of like what, uh, what's your mother's maiden name or what's the name of your first pet, don't actually put that go and generate a new password and put that in like like in like one pastord begin of multiple fields outside of the used name password, create another field call that the name of the question, and then have a type password there and put in like a sixty character password in there.
So create a fake family.
Yeah, really long family.
I do have a warning there.
So a long time ago I thought this was a great idea, and I generated this site to actually dynamically generate shot two PTY six encoded answers based off of the questions. So I don't even need to remember the question. I just copy and paste the question into this generator and it will generate a shot hash for me to put there.
However, it broke me because I was talking with some.
Customer service experts who would often be on these calls that have to verify security questions, and they for sure were like, yeah, we do get people with the list and when they ask you to verify your question, some people for sure just say, oh, yeah, it's just some random characters, like I don't remember, like that's what I put there. I put random, like it's not a word. I put random characters there. And that gets by having put like a password in the security question. So security
questions are over too. But I definitely recommend a real word. Definitely a real word, but not the right answer, as Brian said, and to get over this and just store that in your password manager as well.
Maybe should be one of those passwords that are like a chain of words together that you can easily remember, like.
I would to the park or something like that.
I got a list of those that don't accept that, because some of them thought they would be really smart and there would be a drop down menu of the answers that you could pick, because you know, that's what they wanted to go with and I'm like, first of all, my right answer isn't even here, Like it's like what was your what it was your first instrument you played? And I'm like, I couldn't even put the right answer because it's not listed there.
So like I don't know what game you're playing.
Yeah, I'm really curious what like ten years from now, what this whole identity space is going to look like, because it's changing.
Yeah, the rest that I would talk about that because that's pretty much what I spent all my.
Day thinking about.
And I'll say that there is this aspect of past keys via hardware tokens isn't the future because it's still too much churn in difficulty and complexity for most people to get right. And something where the past keys can be shared between multiple devices is probably correct, but not the Google or Apple approach, but something way more secure,
and it's coming. There's actually an open standard that allows for past key transmission between different devices in a secure way, and I think that will be the first step that really helps us there. The next one is the root of trust, like our browsers working for us and making sure that the security cokens the JWT's the session keys that we have are device bound and can't be exfiltrated to an attacker and then reused to generate new stuff and will always be stuck in cross site scripting land.
But those actual tokens will now be worth outside of the original device because you'll need the device private key in order to sign each request. And we're working on it. It's happening, the right working groups are focused on it, but you know, it's still a thing that and users are not going to see a huge impact and say the next ten.
Years, yeah, and then once it does happen, you're gonna have to like roll it out, which will also be another wave of adoption as well, a slow one.
It's hard to convince those companies that don't have a financial stake and doing the right thing to make a change fundamentally, And so like, I'm really looking forward to whatever impact Doppler can make on the industry to actually convince people to move to workload identity verification for every request and not just because your customer happened to be someone that had was in Germany and had some ridiculous security requirements there or required twenty seven KO one or
something or Beta ramp high in order to.
Get those customers on board.
We have some active projects around looking into improving the compliance body so that they are more compassing of like secure secrets management, and I I think when we make some serious progress there, our goal is to like make that more because once you get into SoC two, it's a beautiful thing like SoC too.
In a way, it's like if one company saw to, every company sock to. That's kind of how it has to work because.
You have a requirement that all your all your vendors that use are sought to. So that kind of just has like this ripple effect where if all the BDOC companies are sockd to, then every B two B company sock too. And if we can get in in SoC two, I think that's a pretty effective way to roll to roll out what we're looking for. That's the dream at least, but it's gonna take a long time and a lot of work to make that happen.
I I love your optimism.
I'm just gonna repeat that, like, I just think I love the existation you have there. It's it's just so great to hear someone who who thinks that we can, you know, get down that path and and get to success that way. It's it's it's awesome.
Maybe it's not purely optimism.
I like, at some point, I'm just like this world is a capitalist structure, and like, at some point, with enough capital and enough resources, anything should be possible. And I'm not saying you like bribe, So I'm saying more like, you just put enough lawyers in the room and you try to navigate this like it's a political machine, and eventually you'll get there. And then the question is can we just raise enough money where we have the force projection to do that?
So SoC two for anyone that doesn't have it, ends up being a write out some policies and prove that you're following them where compared to actually putting valid security strategies in place. So it's always going to be a race to the bottom here, and I think we're going to see SoC two getting cheaper and less valued over time as people more people realize that it is a compliance checkbox. It's checkbox bake security or insurance, it really is,
rather than actually providing a real value. And that's a sort of a sad fact there, and there's really no alternative, like maybe that's what we need maybe we need some sort of non regulatory body that can verify companies are compliant in performing actual security. And that's sort of hard because that's driven from like the mindset of the founders and the executive team and the leadership and money Trump's security every time.
See.
I think sock two is actually pretty great from a standpoint of like if you're a saw to all your vendors have to because that just creates this beautiful fact where the entire industry has some baseline of security. I think there's just like one critical flaw of sock two, and that's it's like tax people are like auditors. The auditors are like literal accountants. Those are the people that are setting the policies. I just don't understand how accountants
are setting policies around security. It's like completely different fields, right, Like it'd be like someone who does your taxes is like the one who's saying you should be secure. I'm like, maybe leave it to the security professionals who think about this all day long. If that change, one change happened, I would bet like the world would.
Be a lot safer of a place.
I mean, I'm with you. It evolved from sok one being a CPA auditor of verification that they would take actual liability if your finances weren't in check, and then evolved to actually evaluating different parts of your business reliability, disaster recovery, business continuity in case of the problem, and of course that falls into well how do your I systems actually work as well? So there's a lot there,
but I'm with you. I so to put in perspective of we use not vitamins but pain pills or painkillers. The as the analogy, I think governments would have to pay companies who were secure, Like if you are secure and you get a certification, I think that if you got paid, that would be a really driving good driving factor there.
It would have to be enough to really move the needle, because I could even imagine some companies are like, yeah, even a million year probably.
Wouldn't move the needle from it.
I don't know, like maybe it's a percentage. I really do feel like we don't need to pay them though, Like I think so two is like the the requirement that all your vendors are shocked to your requirement I think is so powerful already that pretty much the entire industry has adopted it, we just need different people at the helm.
Like and I know where it started.
I completely align you there, but I kind of see it like Kubernetes, a little bit like that started within Google and it got so big it got pulled out of Google into its own body that then could manage it from then on. And I'm saying, like, sock choose the same thing. They created something amazing with SoC two, Let's pull it out of the of the accountants and let's have real security people run this thing. And like let's give it a V two or maybe a V three. I think that would do a lot of good.
I love.
Well, it's like, oh, there's so much going on here.
So I heard a lot with security and very much like that's somebody else's job. But you guys have like the nice provided for that kind of thing, which I guess so I am the problem I suppose in this conversation, like in general.
Well maybe that's a good twist though, Like do.
You feel, like Jillian, you have some comp here to cause your company to do something different or you have flexibility to pull in libraries or other providers to help you support better security.
Oh yeah, definitely, Like for the most party, they tend to rely on the you know, like the providers and things that they work with, because I work with primarily data science companies, so they're not like technology companies where they care about the technology in and of itself. So pretty much as little computing as they can do, they will do. Like these guys like if they could analyze the data from their laptop, that's what they would be doing. So it has to be, you know, like Brian was saying,
it has to be a really easy sell. It has to you know, it has to be the candy and not the vegetables. It has to be for the most part, something they don't even notice happening. It just kind of like gets bundled into the background. So pretty much anything on you know, that kind of front, it's it's not even so much a question for me. I don't ask them Like I wouldn't ask my clients like, oh do you want this? I would I would just go do this, right, I wouldn't say like, oh, do you want for me
to keep your credentials off of GitHub? I would just keep their credentials off of GitHub in that scenario. So I do yeah, I do think. So I do think like smaller you know it providers or consultants, are you know, like just engineers in general, especially if you're working for a company where technology is not their focus, you do have a lot of say in the technology stacks that are used. So we just got to sell this to all the developers, right is that? Is that what we're going for?
And then eventually we work away at the compliance bodies and those committees.
I do have a question about Doppler maybe, and that's like, what is the minimum implementation you can have here?
Is there?
Is it just maybe replacing out the cloud SDKs with Doppler SDKs for interacting with Supermanager. Is there something else that has to be done in order to sort of start getting the benefit right away? Or is there like a large upfront integration that has to be done to make it effective?
Yeah?
Great, question usually depends on the complexity but the company that we're working with from their infrastructure standpoint. But I'd say for like a small startup of like series being below, they usually get up and operational in like a couple hours. So like you're usually using some cloud provider like ABSG Spears your secrets manager, we would directly set up a sink or an integration and write directly into that, so you don't need to change your sd case at all.
It's literally just put like a layer on top, which is Doppler, and then they would download our CLI and use that for local development. For much larger companies, it can take in the order of weeks. We've had very few go longer than a week's even like extremely large entities, like we have a one customer that's like on a three year roll out to one hundred and twenty five thousand engineers, and even them, it was like a couple of weeks to get them like integrated in their infrastructure.
And usually it's like just connecting dots. It's okay, you're using a toa secrets manager, you're using GitHub workflows.
Here, we're just gonna connect all.
The dots into Doppler and then from there we're going to add local development through like the vis code extension we have plus the Doppler CLI, and so it's a pretty formulaic approach that that's very quick, I would say. And when you set up those integrations, we'll do bulk imports as well, so we try to streamline a lot
of it. I'd say, where things get a little bit more complex, as if we have customers that like to do everything the terraform way, then we help them kind of like set up all that stuff instead of in the UI, but through terraform, So you can actually manage pretty much every part of Doppler and including all the orchestration and workflows that.
We have in Doppler through Terraform.
And I would say that would slow them, slow them down a little bit and initially, but then speed them up on the long haul when they have are like bringing on like tens of thousands of projects.
I like that that you really gave credence to that that using IIC there does does actually slow you down for development I do thing. It's a lot of truth there that people don't like to listen to.
Yeah, it's just like a high upfront cost, but then it pays difference.
There's something here where like the IC cloud for the cloud providers and whatnot. Don't always optimize for easy interactions right that it's it's to have it be fixed and maybe work and make it easy to make changes, but not really quick and easy. Whereas your your console, your UI, r CLI or optimize for ease of use and getting to the value as quick as possible.
Yeah, I would say that I see it's like I almost see it as like stability insurance, right, like like you're it's there to keep you stable and reliable and very predictable, but it's not there for speed.
Though you can once you have it, once you have.
Achieved stability, it's very easy to boot up new infrastructure with it, which can give you some speed benefits. But sure that's usually come at the cost of a lot of upfront investment, so it's like paying you're paying down that or drawing down all all that initial investment over time.
So I know we opened a huge topic by saying we're going to talk about secrets management, and I think we definitely dove into all the different tangents that that were related to it. Was there anything on this that you feel like we missed that would have you think a huge impact for the audience something maybe some special wisdom there, anything worth sharing.
Yeah, I would say that the only thing that we didn't touch on is it's better to start early. I know, when you're first starting out, you're building a company, you're all about like I need to get to product market fits and then at some point you'll need to think about like, how do I protect the company now that I've achieved product market fit?
And what we found is that it's adding security later on if it's not part of the DNA of the company. Just almost never works.
Like you'll you'll take all you'll feel like you're taking all the right actions, but it won't actually give you the security benefit you're looking for, and thus you'll be vulnerable. And so my strongest suggestion would be to use a secret manager, Doppler or something else day. One does not have to be the best solution, but just use something, get used to it, build it as part of the DNA of your company and of your engineering philosophy, and then grow with it over time.
And at least there you're.
Coming from a stable foundation versus one that's cracky as how that you're trying to lay layer a building on top of.
Because I think it'll save.
You a lot of headaches and time down the line, and also I think the right secrets manager, for what it is worth, will make you feel more productive. So just calling that out there, that's all I got.
Seems fair enough. On that note, should we do some picks, Yeah, let's do it all right?
Cool, Jillian, I'm throwing you under the bus because you've been gone for a while. What did you bring for a pick today? I mean, it's got to be something cool since you've had plenty of time to figure something out.
I mean, that's a lot of pressure for what I was gonna pick. I was just I was gonna like, I'm looking up my window, it's spooky season, it's autumn. It's one of the few live action videos before like cell phones, that my kids will actually watch. And so that was that was it. Hocus Pocus. Maybe I'll throw Halloween in there too.
Just in general, Halloween the movie or the holiday.
No, the holiday. I don't like any weird horror scary movies. Okay, Like hocus Pocus is as scary as it gets for me.
I don't know why you're laughing, will like that.
That Hocus movie for sure traumatized.
Me as a child, like that was not I didn't I didn't appreciate that experience. That was very troubling, especially where the cat. You know, there's an animal death in the end, and that's that's always struggling for me.
Oh, that's true. I was I was okay with hocus Pocus. The never Ending Story for some reason is like the kids movie that really freaked me out, so we can like bond over our shared trauma of nineties movies. Like Another Day.
I actually liked ever I did a story, you know, a different world, was, you know, sufficiently interesting.
I liked back in the day, Halloween Town if you've ever heard of it. It was like a Disney series, a couple of movies. But I would say it's great for kids. That's magic in it, a little scary, but not too scary.
I love all the kids Halloween movies and stuff like that. They're so much fun.
They are, all right, Warren, how about you? What'd you bring for a pick?
You know, I thought for sure you were you were gonna tell me to go first again, which I you know, I've just gotten so used to.
I'm happy to just do it from here on out.
You're gonna follow your sword for us?
Yeah, I'll just I'll just admit that. So what I was when you asked me how I was doing, I had the whole, the whole episode to actually think about that, and what I came to is, so I guess I sort of have two picks today. The first one is I'm today is like one of the first days of my short little intermittent fasting that I do every quarter where I just like don't eat any food for three to seven days and it just makes me feel so
much better. There's a bunch of health benefits associated with taking a break from eating, and I feel better usually by the time I'm done, so like sort of like a full cleanse in a way, I highly recommend there's no negative health impact at all from doing this. I mean, it's sort of psychological. It's nice to think like, oh, I don't have to eat like all the time. So I really appreciate that so great since I started doing it.
And I think my real pick for today is going to be a book, because I always pick a book I guess called Drive by Daniel H. Pink that talks about the truth of what motivates us and how we as humans get motivated and what actually we use to drive our desire, what we work on, what we find enjoyment in. And the one really important learning that I pulled out from the book is that you will always lose happiness in something where you expect a reward for it.
So if you really like doing something, and then you make that your job, and your job pays you to do that thing, you will actually lose motivation to perform that action. Which is sort of a sad story, but I think there's a lot of truth in it. When you start associating money with the thing that you're doing.
Yeah, I've seen that happen in my own life, and it's surprising.
You're like, oh, damn, I used to enjoy this.
What happened in retrospect, You're like, oh, I turned it into a job.
That's my bad.
You should not monetize your hobbies, right, throw that out. There's life advice. Just don't just sit down and crochet your scarps or whatever. It doesn't have to make the money.
Now, I feel like there's a story there that I'm gonna want to have to hear at some point.
You're gonna have to do like a non DevOps episode at one point just to cover some of these topics we keep bringing up. I think, so, Brian, what about you would you bring for a pick?
I got too. The first one is perplexity. It's kind of like the new version of Google, and like imagine you're trying to like answer a question like how do I cook steak with an air fryer? And like instead of googling that where you can get a bunch of links you have to go through, it kind of just gives you the answer. So it's like chatbut but with
like search capabilities and advanced reasoning built in. There pretty much hasn't been a question that I've thrown a where it failed at Like it's it's really good, including like what happened yesterday in the news, like really really recent stuff. It does a great job of analyzing and you can ask you like very complex chain of thought questions where like like I find a lot of times I'm searching for something and then I'll have a follow up question and so now I need to like ask another query
into Google. And this is like you just it's like almost like a thread of questions so you can get like every follow up question has all the context of the first question or the previous questions.
So I really love perplexity. I've completely shifted.
Over to using perplexity for almost any knowledge based question of like how do I do ex er? What do I think about this? Or what happened in the stock market? Why did this price go up?
Whatever? It is.
The second one is pickaball. I love pickaball, love it so much. I try to play like five days a week, two to three hours a day. It's hyper addicting. I burned like thousand to thousand, eight hundred calories a session. It's like a really high mount of calories. And it doesn't feel like a workout at all. Like it's probably the first workout sport that I've played that I genuinely love doing and I don't and I'm not just like
waiting for it to end. So if there's any people like that out there who have, like will always wanted to get into sports or always wanted to get in the gym, but always felt like I never really connected with them, try pick a ball. There's something magical about it. Almost everyone I show two falls.
In love with it.
Yeah, I've never played, but I know people who do, and it like the level of passion amongst the pickleball community is pretty wild.
Isn't like?
And it's very uh, it transfers well, like you you you catch that bug where you're like, I just got to be playing today.
I did not play at all, and I feel guilty. I don't know.
It's it's I The last time I felt this level of passionate and drive for something was like building a company. So let's use like a pretty high bar for me. It's like, uh so strongly recommend.
Right on excellent, So I'm gonna pick because we were talking about this before we started recording the episode. The book by William fortun one second after. It's a science fiction novel that talks.
About the struggles of.
A community after an emp or electromagnetic pulse bomb was detonated over the United States and so that wipes out all of our modern infrastructure, and it's I just found it to be a fascinating book because of the things that happened. It's you know, you don't normally think about, and it was a it was well written and very engaging throughout. So if you're into that kind of stuff, definitely a cool book to read. And I think that brings us to the end of the episode. Brian, thank
you so much. It's been great having you on a show. Very insightful and yeah, crap, now I got work to do, thanks.
Man, right.
Having this episode with a checklist?
Yeah, no kidding for real.
Jillian, it's nice to have you back on the show Warren, as always, thank you for being here and Brian hope to hear from you again.
Best of luck with Doppler and keep in touch. We'll do.
Thank you all right, you bet, And to all our listeners, thank you for listening and we'll see you all next week