Machines made this, mistakes and all:

[00:00:00] Chris: Hello and welcome to the Imposter Syndrome Network Podcast where everyone belongs, especially if you think you don't. My name is Chris Grundemann and I'm here with the Real Reason You All Tune in each week, Zoe Rose. This is the Paul Vixie episode, and we really are in for a treat. I had the great honor of meeting Paul while he was a member of the ARIN Board, and I was on the ARIN AC, and while I was always impressed with Paul, it took me quite a while actually to understand just how important his work has been to the internet and specifically to internet security.

[00:00:42] Chris: His resume is so chock full of amazing achievements that I don't think. I could ever list them off from memory, so we'll just have to spend the rest of our time today talking about as many of them as we can fit into a podcast episode. For now, I'll give you a string of words and letters that may mean something if you're as big of a nerd as I am.

[00:01:01] Chris: AWS Security, FarSight Security, SIE Europe, DEC, PA-IX, MAPS, MIBH, AboveNet, and MFN, ISC, bind, Cron, BSD, DNSDB, DNSCIP. That's probably enough for now. 

[00:01:20] Chris: Hey, Paul. Would you like to introduce yourself a bit further to the uh, imposter network? 

[00:01:25] Paul: Hey, yeah. I'm Paul Vixie and I haven't really felt like an imposter for a while, but I'm sure I'm glad to be here and it's good to see you again.

[00:01:35] Chris: Yeah. Thank you. I'd like to start with what I see as, I guess maybe your personal mission statement, maybe that, I dunno if that's how you see it or not, but it's definitely something you've mentioned in several interviews. And I think it's also your LinkedIn headline right now. You say that you are restoring human security to pre-internet levels, and that's a pretty cool set of words there.

[00:01:56] Chris: So maybe you can explain what that means and how you're taking that to the world briefly. Not the whole thing 

[00:02:01] Paul: As briefly as possible, you know, we are all, if we are technologists, then we have a lot of people in our lives who are not technologists. And you know, as I think about the people who don't study this stuff and don't play with it all the time and don't really go deep, they're just using it.

[00:02:18] Paul: They're counting on being able to, let's say, read their email or go onto a website or something and have it, have that be okay. And it's not because all of this technology was barely working before it went out into the world. And now it's worse cuz there's so many competing solutions that uh, maybe they have more features or they cost less.

[00:02:38] Paul: But they're even sort of less stable, less hardened. It bothers me that, let's say my mother back in the 1980s was safer going to the bank or going to grocery store shopping, or, you know, using telephones or whatever than she would be today because we connected everything, all the information in the world is online somewhere.

[00:03:01] Paul: Most of it is, uh, more reachable than it should be. And that means you can't have a secret, like say your social security number or sort of anything else that might be used to identify you. And, uh, it bothers me, right? I, I had a small role to play in the eighties and nineties, trying to bring the internet out of academia and into the real world.

[00:03:23] Paul: And that means I blame myself for the lack of safety among the less technical people in society. So we've gotta do what we can to, uh, restore the balance.

[00:03:35] Zoe: I really like that point about Chrissy and because I agree, like it took me a, a while in my career to realize that technology isn't intuitive. For most people.

[00:03:47] Zoe: It isn't. Easy to understand. I think I've only recently started to understand why it's not as easy, and I think it was because I was sat in a, um, developer conference presentation and they used a lot of terms that I'd never heard before. And as a security person, I'm used to using lots of like complex terms, compressed, you know, letters that somehow mean something.

[00:04:11] Zoe: And I was sat there like, This is how other people feel. I feel so stupid. So it's, yeah, I like that It's our responsibility essentially to protect the people that don't know what they're doing, but they're just trying to live. How do you get to that point? Like, I mean, looking at your, what are kind of CV for you, if you will?

[00:04:35] Zoe: You built or supported quite a few big parts of the internet before we really knew it as it is today. How do you get started in that? Where's the inspiration for all of these different technologies, these different creative solutions, essentially? 

[00:04:53] Paul: Well, I think it's being a throwback, right? Yesterday was the 50th anniversary of something called ethernet, and I remember 30 years ago when it was the 20th anniversary of ethernet, one of the inventors, uh, Dave Boggs was part of the ceremony.

[00:05:10] Paul: At the, uh, tech museum, and, and it was, it was a great thing. And he has since passed, but I remember in my years with him back at DEC, and that's a mini computer company, they made VAX' that, uh, he was part of the slide rule, pocket protector crowd. You know, he would've been at home on the, uh, Apollo team trying to, you know, put things in orbit.

[00:05:35] Paul: He used every bit of knowledge that he had about the pre ethernet world. In order to figure out how to make the best ethernet that could be made. And I think that's what I did too, right? I, I come from a pre-internet world and so I could see where it was going and I had the opportunity to, to sort of do the obvious thing that eventually somebody would've done, but I saw it first, or I was in the right place, I had the right opportunities or whatever.

[00:06:03] Paul: And so today, I think the same is true when somebody comes up with a. Say some new framework for, uh, some computer language or operating system or whatever. It's because they've used a lot of them. They didn't just use what is currently popular and they just, they think they have a better idea that happens.

[00:06:21] Paul: The ones that take off are the ones that, uh, refer back decades, maybe even to some pre-web ideas, and they will be done by people who are from another era. That's how to be part of an inflection point. 

[00:06:35] Zoe: Yeah, it's like learning from history and also combining lessons from other areas, not just, you know, historic, but also I think one thing I find very interesting is people that have had different careers or different hobbies and then they apply it to their day job, even though this doesn't seem like it's directly related, I feel like that's the way that they can be quite, um, creative, creative.

[00:07:00] Paul: Yes. Well, um, it's worth remembering that there was a time that every United States astronaut that had ever been in the program was also an Eagle Scout from the Boy Scouts of America or Girl Scouts of America. You know, by some reason, and, you know, learning how to start fires in the woods using your sticks doesn't seem like you should need to be that in order to be an astronaut.

[00:07:28] Paul: Turns out you do. 

[00:07:30] Chris: Is it that self-reliance and, and kind of industriousness bit that comes of that, right? It's almost that I think there's a, there's a spirit or a spark there that I think you're right is, is really crucial to not just innovation, but kind of forward progress in general, which is that, you know, if you hit a roadblock, you run outta food, you don't ha you know, you're cold, whatever, whatever that roadblock might be, you've got this attitude of solving for that.

[00:07:54] Chris: And I think, yeah, camping is interesting, right? Because. Usually the stakes aren't quite this high, but you're solving for survival, which I think definitely drives humans a little bit more deeply than, than some other challenges we might run into. Right? You can walk away from the latte, but maybe not, you know, the steak after three days.

[00:08:10] Chris: I dunno. 

[00:08:11] Paul: I think there is some truth to that. Normally the thing that is the inflection point came about because somebody had to do something the hard way and they had a lifetime of doing that kind of thing the hard way, and they wanted it to become easier. And if you don't have that perspective, very difficult to know sort of what should the next thing even be.

[00:08:35] Zoe: One thing that really stuck out to me in your list of achievements was primary author and technical architect of bind eight. That's me. It's when I went into tech, I was an IT manager and I was not technical, probably a mistake, but whatever. I ended up going back to college cuz I had no confidence and the first thing that really stood out to me and made me have some confidence was actually learning bind.

[00:09:02] Zoe: I think that's, it's so silly, but it was like, I don't know, it was like this turning point where I'm like, I can understand this and it's easy. You know, so for me that's like, yeah, that's a little, I'm a little bit fan-girling, but yeah, that was a big turning point in my career actually.

[00:09:20] Paul: Let me say that, you know, I didn't know you at the time, but I hoped there were people like the way you describe yourself.

[00:09:27] Paul: So you were the audience that I was, uh, aiming for. I wanted people to find this approachable way into something that was pretty monolithic, pretty difficult. And yeah, you know, there were bugs and. Documentation wasn't all it could be, but it, it was approachable in a way that previous versions of BIND were not.

[00:09:48] Paul: So I was quite jazzed in a way. I, for a long time, I worked on Bind as an employee of DEC, that mini computer company I told you about. And then when I left DEC I took it with me. I kept working on it and, uh, eventually I figured out how to get paid for it. But I, I would do it for nothing, just to have the experience of.

[00:10:11] Paul: Building roads for other people to, to tread. 

[00:10:14] Zoe: Yeah, definitely. 

[00:10:15] Chris: So does that tie in, I mean, cause obviously I think you started actually maintaining bind back at like bind four years before you kind of, you know, I don't wanna, you know, rewrote it and kinda re-architected it and in into bind eight, which is kind of, you know, I think there was a big inflection point there and then like you said, right, that really took bind from.

[00:10:33] Chris: One world to another and, and really kinda opened up this, this internet world in a lot of ways is that, you know, referring back to what you were talking about earlier, about seeing these inflection points and stuff, I mean, is that, was this kind of, um, a looking backwards to be able to look forward moment, or.

[00:10:46] Chris: Was it just, oh, I'm familiar with, you know, I've been working on bind for the last three revisions and so now I know what needs to be done or you know, what kind of culminated in that. Cause I think it was kinda a big shift to bind eight. Right. And you know what drove that?

[00:10:58] Paul: Well, it certainly was a big shift and most of it was just in the configuration file format, but there was a lot of other stuff that that went in.

[00:11:06] Paul: It was not fundamentally a different program. Right. We didn't rewrite the whole thing until Bind version nine. In Bind version eight, we just kind of made correctness preserving transformations until we had something that was sufficiently distant from the previous version that we said we need a new version number.

[00:11:24] Paul: But I remember when I first got started, uh, looking at this, it was cuz I was an operator. That mini computer company was where BSD Unix kind of resided in a lot of ways cuz the VAX was the first BSD Uni or PDP 11, which is another DEC machine. So this is, this is where the internet and Unix and sort of so forth had all been made possible by this company.

[00:11:47] Paul: And so I wanted to work there. And then I took over their internet gateway, and we had probably the largest internet connected population, 130,000 employees in 1988. They were all able to use, you know, internet email at least, and I was responsible for the gateway for that. And so I was responsible for dns.

[00:12:05] Paul: And at that time, bind was a crock of, well, I can't say it on, on the podcast. And um, I got into it because it was failing. I was operating the big DNS infrastructure and it was failing. And so I started looking into it and I said, my goodness, this is horrible code. And it turned out it was written by really smart undergrads with a little help, some from some grad students.

[00:12:32] Paul: They didn't have commercial programming experience. They were very much academics. They understood the protocol, which at first I did not, but they did not understand how to write hardened software. And so a lot of what I was doing was just self-defense and I worked on it for years just fixing the stupid stuff before I ever got to the point of understanding what a DNS message was or you know, how the DNS protocol itself would work.

[00:12:59] Paul: But you're right, it took all of my previous experience as a programmer. To understand how to fix just the software level badness. And then as a result of that immersion, I understood DNS well enough to begin figuring out, you know, how can we do this better? Or eventually by writing some RFCs, what could we do that would be better?

[00:13:21] Paul: So in every case, I was using my experience to date in order to figure out where to focus. 

[00:13:28] Zoe: These are pretty big, uh, looking at the list of things, these are quite, quite big achievements. And I think one thing I would be curious about is, it sounds like your motivation is, you know, opening it up to the world, kind of making it easier for other people to do and more intuitive, which is wonderful, but also like where do you get your inspiration?

[00:13:51] Zoe: Like why did you go and, you know, work on bind? Why did you. Get the inspiration for a note. Chris had his, uh, patented the idea of CDNs back in 96, which I was a child at that time, so that's quite cool. Like where, where does the inspiration come from? Where did you go? I wanna do this next. 

[00:14:12] Paul: So it's not a secret, but I will say a few things that are not well understood about me.

[00:14:18] Paul: I wake up on any given morning already angry about something. You know, and when I was the founder and CEO of technology company or did that five times, you know, I'd wake up and I'd say, look, I got shareholders, I got customers, I got employee families. I gotta move the ball down field for at least one of those constituencies before lunch.

[00:14:43] Paul: You know, what am I gonna do? And so there's just that feeling of impetus that I'm being pushed. And you know, the result of that is that psychologically speaking, I rarely experience free will in my own life. The next thing I have to do is blindingly obvious, and so I can backtrack and tell you, yeah, suppose that when I did a certain thing, I had been inspired by this other thing.

[00:15:10] Paul: But that's not how it felt to the moment, right? At the moment. I just, I had to do something. I had to build something, I had to fix something, had to prevent something. And you know, if you do that over and over again and you drink a great deal of coffee, uh, then it adds up. And I'll give you sort of a summary that came out of my remarks when I was inducted into the Internet Hall of Fame in 2014.

[00:15:33] Paul: And, you know, keep in mind, I dropped outta high school in 1980. In order to start work as a programmer, I was a terrible student, so it was the right thing, but so that meant that I had, by this time, about 30 years of experience. And to go from high school dropout to Internet Hall of Fame and also, you know, PhD in computer science from KO University, which is older than Japan itself.

[00:16:01] Paul: It is a very tough outfit. That's an odd story. And so what I said when I was inducted into the Internet Hall of Fame is, you know, I've spent about 30 years working on internet stuff and pre-internet stuff, and I'll tell you that the first half. Of that 30 years, uh, had been spent trying to make communication easier possible, more accessible and so forth.

[00:16:26] Paul: And the second half had been spent trying to make it harder because it turned out that moving information without permission was big business. And you know, that's where the anti-spam company came from and everything else. So to spend the first half trying to open the world to the internet and then the second half at that time, trying to make control the Internet's impact on, on the world, uh, was a real juxtaposition.

[00:16:53] Paul: But for that whole 30 year period, I woke up every day angry about something, feeling that I had to do the thing that was blindingly obvious that day. So there was no conscious inspiration or even, uh, free will. 

[00:17:07] Chris: That's a really interesting set of feelings or, or, or, or self-perception of, of how that works.

[00:17:11] Chris: I mean, I've definitely, obviously, not to the same degree, but, but definitely have felt very similar ways in, in, in my life in that a lot of the things I've done have just been obvious that I had to do them. Which of course, I mean, we see this, this is a trope in, you know, entertainment and things too, right?

[00:17:25] Chris: Where, you know, when good guys do great things, it's, it's usually because they felt like they had no choice. You know, nobody goes up and says, oh, I'm gonna be a hero today and puts on a cape and, and jumps off buildings. I don't, at least, you know, in my experience, it's not what, it's not how it happens. It's just you see a problem that you have to solve and, and you solve it. I love that. 

[00:17:40] Chris: Now, we've mentioned a lot of these things already, right? And not everything, and mean we won't be able to, we don't have enough time, but. As you said, right? You've got a PhD from KA University in Japan, amazing. Inducted into the Internet Hall of Fame in 2014, which is already almost 10 years ago, and you have not been, you know, resting since then.

[00:17:57] Chris: So just, you know, loads and loads of achievements and, and huge impact on the world. And what I wanna know in the context of that, I know you said that you don't feel like an imposter very much anymore, but do you ever feel like you're not smart enough? Does that, does that still creep in? Or when, you know, when's the last time you felt like, ah, man, maybe I'm not the right person to be doing this.

[00:18:14] Paul: Probably writing and defending my PhD was filled with the feeling that I'm not smart enough and I'm, I'm not the guy they think I am, and, and so forth. But it's also inevitable if you work around technical people, that you're gonna eventually meet people who were, you know, as good as you were at their age, or maybe better than you were at their age.

[00:18:36] Paul: And it's like, you gotta be very respectful because you know if, if you're not. Uh, sort of in it, in the trenches every day, honing your skills, learning the new thing. Then you can easily, uh, hear a proposal that makes no sense to you, but is the right one. And so, you know, I'll tell you, at FarSight Security, we had a lot of really smart people come through there and at the Internet Systems Consortium, which is where bind is, same deal.

[00:19:04] Paul: We had a lot of really smart people come in and you know, there would be things that I could say, well, let me explain how I think this is, and I could add a little bit of value here and there, but you're not gonna be able to keep up. Trying to do too many things. You've also got various non-technical responsibilities.

[00:19:25] Paul: So I've always been A CEO who codes, but like, uh, I stopped learning new programming languages for a long time after C and Pearl and that's just, there's not a lot of currency there. I've learned Go Lang, I'm feeling some desire to go study Rust but I am no longer part of the group of people who can tell.

[00:19:46] Paul: The world. Yeah. The next thing we need is gonna look like, whatever, like Rust or like Golang or whatever. There are people better than me at all of that. And to the extent that I still have a contribution to make, it is as a generalist with deep perspective rather than as, uh, an expert on enough different technologies that I can get down into the trenches with people.

[00:20:08] Zoe: I like that generalist with deep perspective. I think that's, that should be a t-shirt. I think one question I had was, I am not a developer. I can code, but it's quite rubbish, so I would never say that I'm good. But, um, one thing I did know is when I did have to do it, I would make some really silly mistakes that, uh, I realized after, but they could have been if I had.

[00:20:36] Zoe: Put that into a production that could have been quite devastating. Have you ever had a situation where it was quite a big mistake that either you learnt a lot from or you had to deal with, well, how do we overcome this problem? 

[00:20:52] Paul: So, yes. You know, when you wake up angry and you want to, you know, fix something, you're often ready to ship a tarball or shell archive, whatever.

[00:21:05] Paul: Before you've had a chance to really think about, well, how could this go wrong? And so there have been some terrible permission problems in Cron, been some buffer overrun problems in bind some buffer, overrun problems in the uh, university of Washington F T P demon that I had adopted and. Enhance for a while and send mail.

[00:21:30] Paul: I had my own version of send mail during the time that Eric Allman was off. And you know, you look at that and you say, how could I have let that out into the world? Because it's real obvious once, you know, once you see how it was abused. And now as I'm writing code, I can see that coming outta my fingers. I don't have to ship it and let it get abused and then have come back to me and then, oh, well look what I did.

[00:21:56] Paul: Now I can see it. Decades ago I couldn't, uh, until after the fact. So, The rule that this has led to in the dev teams that I've had influence over is that nothing gets out without at least a second pair of eyes. You know? Cause just the, uh, difference in perspective of the person who didn't write that code is often all you need to, to do, to say, look, if that goes to zero, we're gonna dump core.

[00:22:22] Paul: You know? Oh yeah. I see that you. But that's just, it's never obvious when it's your own work that you're struggling with. Well, I don't wanna say never. It's not as obvious when it's your own work. 

[00:22:32] Chris: Well, yeah. It's really hard, right? Because you, it, it's, it's almost this unknown unknowns because if, if it was obvious, you would've already fixed it.

[00:22:39] Chris: Right? Or you wouldn't have written it that way, maybe. 

[00:22:41] Paul: Yeah. But, you know, sometimes it's, you don't understand the side effect of various system calls. Right. I, I remember the, when I first shipped Cron to an audience who wasn't me, somebody like within a day said, look, The crontab utility that you included for managing cron tables has got this thing where it's trying to set, its UID to the owner of the, of, of the file so that it doesn't have root privileges when it's doing that, but you're not checking for the error result.

[00:23:14] Paul: And there can be an error result and you know, look, this is me. Editing somebody else's crontab just by changing my environment to something you didn't expect. Ah, yes. So sometimes there are just too many moving parts and the problem that you need to see isn't on the screen. It isn't all on the screen, all the parts of it that are necessary to make it go.

[00:23:35] Paul: And you know, so that perspective informed me when Microsoft came out with a print driver bug that then allowed what is now known as the Conficker virus to get into millions of Windows machines. They had the same bug in two parts. And the, if you just looked at the object code, you know, cuz that's all we, we, we didn't have the source code.

[00:23:58] Paul: We were just dissembling stuff. But the addresses of the two places that had the identical buffer overrun problem were so close together that there was no possibility that the source code to both parts wasn't on the dev screen at the same time. Right. They had to be able to see, I'm fixing this here.

[00:24:16] Paul: The identical code occurs there. And at that point you look at 'em and you say you were an idiot. You didn't see what was right in front of you. But when it's complicated stuff, you gotta go, you know, read RFCs and test stuff and you know, look at this, the stack frame above you and figure out how you were called and how things are organized.

[00:24:35] Paul: You know, that's, uh, it can be forgiven. You know the thing that gets me still about C, is that it's, uh, deliberately memory unsafe, right? It was written as a better macro assembler for the PDP 11, and it is that, but it's, you know, that was not a safe environment either. And so you look at, there's a library called, called Gdes, which was used to make the Morris worm back in the late eighties.

[00:25:01] Paul: And you know, when you call Gdes, you're saying, Hey, I want you to read from standard input, read some characters, and then when you. When you get a new line or an end of file, then you can return and just put all whatever you find, put it here. But there's no indication to get us how long that place is. So if you send, if you receive more input than you have room for, it just cheerfully overwrites the stack frame of the person who called you and that can be abused.

[00:25:29] Paul: And so in that case, the problem was not calling. Get us. The problem was that get us existed in the first place. Because when a program reaches an undefined state, then you should abort. And when you call, get us and you have just reached an undefined state cuz you don't know how long the input's gonna be.

[00:25:47] Paul: So the right way to implement get USS is as abort, just dump core you. They called, they called get us. That means it's no longer defined. And that's still in some parts of the C standard. And there are some, like even in free bsd, you can still call that thing, you'll get a, a link time error or warning.

[00:26:06] Paul: It'll say, Hey, you're calling, get us. That's not safe, but it, it'll still try and do it. That's not the right thing, and so there's a unpleasant tolerance for that kind of danger and sloppiness that has not gone away. Right. I know Rust makes a name for itself with a lot of memory safety things that are really good.

[00:26:27] Paul: And a lot of people that are gonna use it are gonna write better programs, but first they're gonna struggle as they try to write the unsafe way of doing it. And Rust, you know, complains and says, I'm not doing that. And they will struggle for a long time until the compiler has forced them to write better code.

[00:26:44] Paul: And what that means is there's a lot of tension there. People would rather write horrible code, you know, in PHP or C or whatever it's gonna be. And, uh, they shouldn't, people should wanna write good code. They should be looking for help rather than resenting the help, but we're human. 

[00:27:02] Zoe: I think also, uh, it does go back to how developers are taught.

[00:27:06] Zoe: Like some are self-taught and that's great. But for the people that aren't, they still traditionally in school, most developers I've spoken to, they're not taught how to do it securely. They're taught how to functionally, you know, so the functional, has it happened, what's the easiest way? Maybe what's to do it in a nice, clear way, but not necessarily how to do it in a safe way?

[00:27:30] Zoe: And so a lot of times my job is simply advising them on, well, this is why we have to care about security. I think there's a big gap in the way that we educate developers as well.

[00:27:45] Paul: I, I know that that is so, but I also know that a lot of us are dropout self-taught, and so we're not having a chance to be, you know, mis trained.

[00:27:54] Paul: What we're doing is we're looking at the open source world. For me, that was before the word open source. The term open source even existed. You know, we had this thing called Usenet and it had a thing called mod.sources, and that's how you got a lot of the software that you would run on your Unix system.

[00:28:09] Paul: Back in the days we didn't have package managers. All of us only had modems. We didn't even have internet connections. And so reading bad code turns out to be as bad as, uh, being instructed without, uh, regard to security. And I've also seen some changes recently cause I'm sometimes asked to go lecture somewhere.

[00:28:30] Paul: And I've done this both at, uh, Sonoma State, uh, university and. Berkeley, uc, Berkeley in the last few years where, you know, I'm addressing a class that is in the security segment of some course, out of some larger portfolio of courses, and students are being taught how to reverse malware. They're being taught.

[00:28:52] Paul: How to violate security and, and so forth. And it's not so that they can be better bad guys, um, that inevitably that will happen. It's so that they can say, yeah, I've seen how usable this is gonna be. I gotta make sure I don't do the thing that I've been taught how to break into. And I'm starting to see that change, uh, not fast enough, but it is changing.

[00:29:17] Zoe: Yeah, no. That's how I approach awareness is I change the mindset essentially and educate people on how easy it is to do not so ethical, not so positive things. Um, and therefore it helps them do it in a more secure way. My last point that I was gonna ask is, you mentioned earlier you've been a founder and CEO of a company five separate times.

[00:29:42] Zoe: Curious on why. Why you did that? Like I've, I have started a company as well, previously, once, not since, um, I'd like to, but Visa restrictions. But I am curious on, um, why the different, uh, companies and maybe which one has been 

[00:29:59] Chris: that? Why do yourself do that to yourself? Is that what you're asking Zoe? Why do that to yourself?

[00:30:02] Zoe: Well, I mean, it's a lot of work. I mean, I, I've owned my own company. It's a, it's a bloody lot of work. You know, people say, oh, well then you can work your own hours, which is true, but your hours become every hour. So I, I'm just curious maybe what was the most exciting or most rewarding opportunity and yeah.

[00:30:21] Zoe: Why five times. 

[00:30:22] Paul: Well, again, I didn't experience choice most of those five times. The first one was a security consultancy and you know, software and security consultancy. That I started after I left DEC, that mini computer company again. And the reason I did was that I was angry and it was because when I got there in 1988, they had a 100% market share of Unix and then NSF net computers.

[00:30:54] Paul: So the, the whole network was them. And the trouble is they weren't able to make the kind of money they wanted to make from that kind of stuff. And so they hated the internet. And they wanted everybody to use DECNET and they hated Unix. They wanted everybody to use VAX VMS and they really didn't want to be the market leader in the two technologies that we, in the research lab that had hired me.

[00:31:18] Paul: Could see the future is this, and DEC doesn't want to be part of that future. They believe that they can somehow do what then Microsoft has done with windows and kind of force people into a different mold. But they didn't have the, the go to market, uh, chops that Microsoft had. So anyway, by the time I left in 1993, the internet was starting to take off the, um, I gave on my last day of employment in May of 93, I gave the whole research lab a demonstration of NCSA Mosaic, and I said, I'm leaving to go work on this.

[00:31:53] Paul: In case some of you were wondering why after five years I'm leaving. And that was partly true. What I was, what was also true is, They had fumbled the future, even worse than Xerox had done with the, the various park technologies. And I was angry. I was just mad, and I said, I am not gonna take the risk of some management team screwing up so badly that a bunch of my software ends up locked in a lawyer's safe, never to see the light of day.

[00:32:19] Paul: This is, this is crap. We're not gonna do that. So the only way I could be sure that wasn't gonna happen is if I was the boss and I was not particularly qualified to be the boss. But I put in the time and I learned as quick as I could from my mistakes. And when it became time to incorporate, separately incorporate the anti-spam thing, the real-time black hole list, the RBL. I started that company and you know, did a much better job there, but still learned a lot.

[00:32:49] Paul: And you know, we, we eventually decided that having my little technology company own the copyright to bind was stupid. And so we started the ISC so that it could own that copyright, but it had no employees at that at first. You know, it's just something, and it does now, it's a vibrant company now, but every time I did it, it was because something, there was some requirement that a new company be created.

[00:33:13] Paul: And I either knew that I was the only one who could do it, like with my last company, FarSight Security, or I knew that no one else would be willing to do it, as with most of the others. And so in each case it was just the circumstances of the moment 

[00:33:29] Zoe: motivated by anger. That's, that's a new one. I like it.

[00:33:33] Paul: Well, you know, I happen to be talking to you on my 60th birthday and I look back on the, uh, 44 years, 45 or about 44 years since leaving high school, unceremoniously without a, a diploma. And, you know, sometimes being angry has been the bad thing. I, I was quite the flamer back in Usenet days. I was hard to make friends with.

[00:34:01] Paul: And so, you know, if you're motivated by anger, you're gonna learn different lessons, but you're gonna learn them the hard way, which is, that's what I do. So I'm proud of what's been accomplished. I have, uh, been on the apology tour to go to people that I've offended and say, look, you know, I was young. I'm sorry.

[00:34:20] Paul: Um, so it adds up well. But in the moment, you know, you just said that starting a company is hard. It really is, right? The, especially during the process of trying to raise money or negotiating to do a, a to be acquired or whatever, it's like you don't, it's not just that you don't have a day off, you don't have an hour off, and it's, uh, just terrible.

[00:34:45] Paul: At my age, I now know that I no longer have the energy that it would take to start a company, and I'm strangely okay with that. 

[00:34:55] Chris: Definitely have done, uh, quite enough in that regard I think at this point. And, uh, happy birthday Paul. I had no idea this was your birthday. That's, that's fantastic. Thanks for spending some time with us today.

[00:35:04] Chris: That's really cool. Unfortunately, I think that is all the time we have for today, Paul. Is there any current projects, something we haven't talked about that you'd like the Imposter Network to know about? Anything we should mention there? If not, obviously we've got a bunch of links in the show notes so folks wanna learn more.

[00:35:18] Chris: They can do that and reach out and that kind of stuff. But, uh, I dunno if there's anything active or anything you wanna point toward folks towards, 

[00:35:24] Paul: well, I feel like I would be missing an opportunity if I didn't say something that is hard to understand, but really important. The internet is moving in the direction of, uh, civil society.

[00:35:38] Paul: Uh, it is trying to protect individual privacy, which sounds compatible with my mission to restore human security to pre-internet levels, but in some cases it's not right. The internet was originally a network of networks. In other words, you would build your own network, which I guess would be like a wifi at your house or something, and then you would look for a way to connect that to the rest of the world.

[00:36:01] Paul: But the understanding was that you were responsible for every bit of traffic that came outta your network and you had, you know, enough visibility into that traffic to decide, Hey, look, my thermostat is spamming somebody, or whatever the. The, the camera in the baby's room is spamming, is, is DDoSing somebody?

[00:36:20] Paul: And you would have enough insight to be able to say, I see what's happening. I don't like it. I'm gonna go unplug that thing. And whatever. Maybe it needs a software update. Maybe it needs to be thrown away. All of that's going away. What's happening now is that the end user is, uh, supposed to be totally autonomous, and that means that not even their local network operator can see what they're doing.

[00:36:43] Paul: And that in turn means that if you were, uh, something on your network is DDoSing somebody and they complain, all you can really say is, I'm sorry. I have no insight. I have no visibility. There's no more transparency of any kind. The internet is no longer a network of networks. It is a network of human eyeballs connected to a network of advertisers.

[00:37:03] Paul: So that's happening. It happened with DNS over http. It's about to happen with something called HTTP three, which is sometimes called quic or q-u-i-c. And the people that are doing this are very angry and I, I know the feeling, but they're misinterpreting what they saw. They need to be slightly different in their anger and they need to not disintermediate.

[00:37:28] Paul: The people who own and operate and pay for the end the Edge networks. You know, we as Edge network operators need to be responsible for what comes out of our, our homes and businesses. And then once it reaches the ISP, yeah, it needs to be, you know, imperturbable. But they didn't try and solve that problem.

[00:37:48] Paul: They just made the whole thing imperturbable. So that's something that I'm getting a little bit concerned about. Given a lot of talks about this, you can find them on YouTube. But I would just say, uh, try to, try to see things through more than one lens. And you know, don't just listen to somebody who thinks Edward Snowden was a hero for what he disclosed back in 2013.

[00:38:12] Paul: And that, uh, that sort of thing is an abuse of power by the NSA and must never be permitted. You know, cuz that may be true, but that doesn't mean we need to. To disintermediate edge network operators in the way that is now happening.

[00:38:27] Chris: I love it. Yeah. But to me it plays into the whole, you know, just questioning authority idea because while there is one source of authority being questioned in that conversation, as you said, you know, that the folks asking those questions are also a, a different form of authority in a lot of ways.

[00:38:41] Chris: And uh, yeah, I like that a lot. Thanks again for sharing your story with the Imposter syndrome network. And thank you to all of our listeners for your attention and your support. Uh, we have a LinkedIn group for the Imposter syndrome Network that we'd love for you to join to get or give career advice, mentorship or just general community support between the shows.

[00:38:59] Chris: And don't forget to pay it forward by sharing this podcast with others who may find it insightful, informative, or just plain interesting. But Paul, I am curious, before we totally shut the lights off here, I'd love to know. What you think the most valuable lesson you've learned across this career we've described in, in some detail today?

[00:39:19] Chris: Uh, what is that lesson that you've learned that maybe we could share with other folks?

[00:39:23] Paul: It's two, you know, one is that either by making choices or failing to make a choice, every one of us creates our own future operating conditions. You, you cannot escape that that's happening even if you're sitting on your butt.

[00:39:37] Paul: That's happening. The second is that if you do that consciously and you start thinking, yeah, if I, if I start building things, maybe I'll have more money or you know, whatever that, so there'll be some change to my operating conditions. Maybe the world, the privacy on the internet will improve because of something I did.

[00:39:54] Paul: Whatever it is. And as you think about how to be conscious about creating, inevitably, creating your own future operating conditions and influencing everybody else's build roads, not walls. Road builders always beat wall builders in the long game. 

[00:40:13] Chris: Thank you. I love that advice. That's a great way to close it out and we will be back next week.

[00:40:18] Paul: Thanks a lot.