This is CS50. 

DAVID MALAN: Hello, world. This is the CS50 podcast, and my name is David Malan. 

COLTON OGDEN: And my name is Colton Ogden. 

DAVID MALAN: And so glad to have everyone back with us today for our second ever episode of the CS50 podcast. 

COLTON OGDEN: Yeah, super excited. So curious, before we start. I walked in to your office just before this podcast started, and you were on the phone. Who were you on the phone with? 

DAVID MALAN: You couldn't have asked that before we started rolling? 

COLTON OGDEN: You seemed a little bit disgruntled. 

DAVID MALAN: No, if you can believe it. It was a robocall. And in fact, ever since our discussion thereof, and since the last week's Tonight Show with John Oliver started focusing on this topic, I have legitimately started getting more and more of these calls. Where they're just spam calls. And then you pick up and there's a very cheery computer voice on the other end of the line. 

COLTON OGDEN: You know, actually, I had to block a number, because I was actually getting called consistently. I got called-- 

DAVID MALAN: I'm sorry I'll call you less. 

COLTON OGDEN: I got called everywhere every five to 10 seconds. The same phone number was calling me after I called. It must've been on a loop or something. 

DAVID MALAN: That's awful. Well, I mean the nice thing about iPhone is that you can actually block calls pretty easily. And I'm guessing you can do the same on Android. But landlines from yesteryear, you're pretty much out of luck unless you punch in some code with your phone provider to do it as well. 

COLTON OGDEN: Yeah you can bet that actor got blocked. 

DAVID MALAN: You know it's really obnoxious too. And they think they're being clever. Because most of the spam calls I get nowadays, like in the past week are 617- 555- something, something, something, something. Where 617- 555- matches my own phone number's prefix. And I think the presumption is, and I think John Oliver might have pointed this out, that they're trying to trick you sort of social engineering-wise into thinking like, oh, this must be a neighbor down the road because their phone number is so similar. And it's really frustrating now. This really has peaked. 

COLTON OGDEN: I don't think I ever got a call from anybody in my life who is a legitimate actor who had the same prefix to my phone number. 

DAVID MALAN: Yeah that's a good point actually. I don't even notice, frankly, because it comes up sometimes with my contact information. And, anyhow. Thanks for that. Well, sort of a tie back into actually the last podcast episode, where we talked about Facebook. And they're sort of storing unhashed passwords out in the clear. 

It looks like recently they committed another sort of offense where they were actually asking people for their email passwords. Not a Facebook password, but their actual external email passwords through Facebook. 

COLTON OGDEN: Yeah. I read this, and I think they were trying to do this for well-intentioned, at least we can perhaps give them the benefit of the doubt, in that they wanted people to be able to confirm that some email address was in fact their own. And I presume some developer thought, well, it'll be easy if we just ask them for their username, their password, pretend to log into that actual system on the user's behalf, and if they get in successfully, hopefully just disconnect without poking around. And just assume that the address is indeed theirs. 

But this is just so unnecessary and so wrong on multiple levels. I mean this is why companies actually instead send you an email, usually with a special number, or word in it, or URL that you can then click. Because the presumption there is that. Well if we send you an email, and you are able to click on that email within 15 minutes, presumably you do indeed know the username and password to that email. And so therefore you are indeed who you say you are. 

That's sort of the right, or at least the industry standard way of doing this. Even though it does add some friction. You have to go check your mail. You might have to hit refresh a few times. So there's some UX downsides. User experience downsides. But that's secure, because you're not asking the user to divulge private information. This is just reckless, especially for a company as big as Facebook to be conditioning people into thinking this is OK. 

DAVID MALAN: I think letting big entities like this act on our behalf in the security realm. I mean, especially Facebook given that they've recently been caught storing plain text passwords. Putting my email password in Facebook's hands, I don't know where that's going to end up at the end of the day. 

COLTON OGDEN: No. And honestly, even if it's not malicious, and it is just foolish or accidental. The reality is that servers log input or log transactions in their databases. And so the data may end up just sticking around unintentionally so. So it doesn't matter even that the intentions are good. This is just bad practice. 

And again to my point earlier, if you see this behavior being normalized on very popular websites like Facebook. Well what's to stop a user, especially a less technically proficient user from thinking, oh, I guess that's OK. That's the norm. That's how this is done. If they see it on some random adversaries website that they get socially engineered into clicking on. 

DAVID MALAN: It was kind of entertaining when it was sort of brought to their Facebook attention that this was a bad idea. In the Daily Beast article that I actually read about this, someone actually brought this to Facebook's attention. And Facebook came out, and to the world said, you know, this probably wasn't the best way to approach solving this problem. Because they had been caught doing [INAUDIBLE]. 

COLTON OGDEN: To say the least. You know, and it's interesting because big companies, Facebook among them, presumably do have code review processes in place. Involving multiple humans and design reviews. And so what's especially worrisome here, or certainly surprising, is how did this even ship? Right. At no point did some human presumably object to doing this. 

And so that's I think the sort of fundamental flaw or the fundamental concern is that how did something like this even happen? Because students coming out of CS50 might certainly be inclined to implement things in this way and frankly, if you don't really think about it adversary, or if you haven't been taught to think about things defensively, you might make this mistake too. But that's what mentorship is there for, more experienced personnel or older folks are there for. To actually catch these kinds of things. And so that's the sort of process flaw that's of concern too. 

DAVID MALAN: I'm certainly grateful that we have so many folks online who are getting more technically literate in this domain and are bringing this to everyone's attention. Looking for these kinds of patterns and catching Facebook red-handed when they do these types of things. Not necessarily just Facebook, I'm sure this happens at scale with many companies. But it's nice to know that people are actually on the lookout for this. 

COLTON OGDEN: Yeah. And you know I should disclaim too, because I'm sure we have students out there who will remember this. Some 10 or so years ago, even CS50 actually did foolishly use this technique on one or more of our web apps. Because at the time there actually was no, I believe, sort of standard that we could have used to authenticate users in a better way. OAuth, for instance has come onto the scene since. And maybe even if it existed then, it wasn't nearly as omnipresent as it is now. 

So in short, there are technical solutions to this problem. Whereby, the right way to do this is you don't ask the user for their username and password. You redirect them to Yahoo or Gmail or whatever the account owner's website is. Have them log in and then be redirected back to you. 

Essentially with some kind of cryptographic token. Something that's mathematically significant and very hard to forge that proves, yes. Colton did in fact just log into his actual Yahoo email account. You can trust that he is who he say says he is. 

That mechanism either didn't exist, or wasn't familiar even to me back in the day. And so we would just have a web form on CS50 site to log in with their Harvard email address and their password. And again, we were not intending this to be malicious. We certainly didn't log anything deliberately, or thankfully, accidentally. But we could have. And I think the fact that even we, as a course, conveyed the message that, oh, this is OK, was a very bad message to send. 

And so thankfully, some years ago we actually transitioned to using more industry standard approaches like OAuth, again this mechanism where you bounce the user to their Harvard Law login then back to CS50 as just a sample client, or an application. That's a much better way of doing this. 

DAVID MALAN: Yeah. Because in that scenario, you're actually allowing a third party to let you perform this handshake I think more securely than just having one entity perform all the security for you. 

COLTON OGDEN: Yeah. No, and if you look closely, there might actually be examples of this elsewhere. For instance, and it's been a few months since I looked. In Gmail, I believe under your settings you can actually add accounts to your account so that you can retrieve mail from another account via POP. Post Office Protocol. Which is a way of downloading email. There too, you're doing exactly the same thing. You are trusting Google with your username and password to some other email account. 

The design there, though, is to enable Google to import that email for you into this account. And so as such, there's really no other way to do that unless there is some other process involved where, via OAuth, they can do that. But that's actually not how POP works. And so there, it's too is a technical constraint. And that's kind of an artifact of yesteryear's designs with a lot of these systems. 

But it's worth keeping in mind that these things still happen. And I think even when you log into sites for the first time you're sometimes prompted for a username and password. Maybe it's LinkedIn I'm thinking of, or Yahoo. Because they want to make it easy to import your contacts. So what better way than to just access your outright account. 

But there, too. You're trusting someone. You are normalizing a behavior that's probably not best. And so I think we as a society should really start to resist this and distrust this. Just don't do that. 

DAVID MALAN: I feel like distrust is a very common theme in the world of higher CS. What was the article? The very famous article on trust? 

COLTON OGDEN: Oh, Trusting Trust. 

DAVID MALAN: Yeah. Yeah, indeed. It was actually a Turning Award acceptance speech that was then put into paper form. If you really get into the weeds here, nothing is really trustable. Right. In CS50, we talk about compilers, which are programs that, of course, convert one language into another. Usually source code into machine code, at least in our case of C. 

And who's to say that Clang, the compiler we happen to use in CS50, doesn't have some malicious lines of code in there. Such that if you're implementing any program that does use usernames and passwords, what if the author of the compiler is inserting his or her user name automatically always into your code? Even unbeknownst to you. 

So there too, unless you actually built the hardware yourself and wrote the software that's running it. At some point, you either need to just curl up into a ball, terrified that you can't trust anyone, or you have to trust some of those lower lying building blocks. 

COLTON OGDEN: It's kind of a testament to just how pivotal trust is to where we are with technology. Where we are with computers today. I don't think any of this would be possible if we were on the far end of the paranoid spectrum. I think there is definitely pragmatically an inflection point at which we do need to actually trust people. Most definitely. 

DAVID MALAN: No, I'm guessing that this is why some people, not that many, live off the grid, so to speak. Or in a cabin somewhere, disconnected from all of this, because they don't trust. And honestly, we've seen enough articles, and revelations, and news lately that, they're kind of right. All of these big companies, too, that you would have thought were adhering to best practices aren't. So there's something to that. 

COLTON OGDEN: There has to be a certain, I guess, maybe based comfort level folks have to have with at least some of their information being publicly accessible. 

DAVID MALAN: Yeah. No, and I think you have to make an individual decision as to whether, does the convenience you derive from some tool, or the pleasure you derive from some game, or whatever the application is, outweigh the price that you're paying? And that certainly is a theme in computer science, in CS50 specifically, making a reasoned choice based on the pluses and minuses. 

But I think the concern here, as with sort of liberties more generally in a republic or in a government, is that it's very easy incrementally to say, oh, I'll give up a little bit of my privacy for this additional convenience or this feature. OK, I'll give you a little bit more. OK, I'll give you a little bit more. 

And then when you actually turn around and look at the trail of things you've given up can actually start to add up quite a bit. And then some other party or company or government has much more control, or access, than you might have originally had agreed to. 

COLTON OGDEN: Sure. All makes sense. I guess maybe to sort of pivot away from the trust discussion. Back into it maybe something little more technical. It looks like this last week Apache actually patched a bug that granted folks root access on shared hosting environments. The Apache web server, which is such a ubiquitous web server, there were malicious CGI scripts that were capable of actually running on a shared hosting environment. Which I think CS50 is even used Apache for shared hosting. 

DAVID MALAN: Yeah many years. 

COLTON OGDEN: At least in the V host. Is V host the technically shared hosting? 

DAVID MALAN: V host is a technical term saying virtual hosting. Which generally means hosting multiple domains on the same physical server. And Apache makes that very easy. Yeah. No, we used Apache for years. It's free open source software, it's very highly performing, can handle lots and lots of requests. It's a competitor, essentially to Engine X, which then swept onto the scene and took sort of a different technical approach to the same problem of scaling web services. 

And Yeah. This was an example of a bug whereby if you have an account on a server that's running the Apache web server. As you would if you were running yourself, or if you're paying someone a few dollars a month for shared web hosting. Which is still very common, especially for languages like PHP. 

You have typically a shell account. A username and password and therefore home directory. And the ability, sometimes, to run programs. Otherwise known in the web as CGI scripts. Common Gateway Interface. Which is a way of running languages like Python. You can do it with Python, but more commonly PHP, or Perl, or other languages as well. 

And in short, if you have the ability to install these CGI scripts on a server, you can write a program in such a way that it actually gives you, as you know, root access, or administrator access to the whole darn server. Which is horrible if you're not on your own server, but you are on someone else's shared host. Because now you have access to all the other customers or users accounts potentially. 

COLTON OGDEN: Yeah. Nick and I, on the stream, this was part of one of the CTF, Capture the Flag, challenges we did. Where we had to sort of finagle our way into getting privilege escalation from several user groups up until a root access by exploiting these kinds of vulnerabilities. 

DAVID MALAN: Yeah. No, the threat, of course, is that if somehow you have a bad actor on your staff, or in your course, or really just on your server, he or she can, of course, install something like this. And then gain or grant root access to someone else too. 

So even if it's your own server, you certainly don't want your own code to accidentally be able to slip into route mode. Because that means any commands that are executed thereafter could damage anything on the system. You can add files, remove files, send files elsewhere. Once you have route, the front door is wide open. 

COLTON OGDEN: Yeah. Delete databases. Delete users. 

DAVID MALAN: Yeah everything. So this is a very serious threat. And it's a simple fix to just run the update and actually a patch the software, so to speak. But these are the kinds of things that you want to be cognizant of. And frankly, I think far too many system administrators and people running web servers don't necessarily pay attention to these kinds of alerts. 

And so, making sure you're keeping an eye on Apache's own mailing list or Twitter account these days, or Tech Crunch, or other such sites that tends to propagate announcements of security flaws. You really do want to keep an eye out. Because you're going to be regretting it, I think, otherwise, if the fix were available and you just didn't realize you need to apply it to defend yourself. 

COLTON OGDEN: Sure. So unrelated to that. An interesting thing that we saw in the last week was that Office Depot recently was accused of forging computer scan results. Folks would bring their computers in, and Office Depot would just flat out lie about the computer's safety of the folks that brought their computers in. What do you have to say about that? What do you think about that? 

DAVID MALAN: Well, today's podcast is brought to you by Office Depot. 

[LAUGHTER] 

DAVID MALAN: No. No one actually. No, this is horrible thing. This isn't even necessarily related to technology. This seems to be, and I presume this is true. I'm reading the same thing you are off the FTC website in the US here. That it was just outright deception. 

And the software was configured, or designed, or the humans chose to give misleading information. Incorrect information to people just to trick them, presumably, into upselling them to have their computer disinfected from some virus. Or some malware when it wasn't actually there. 

COLTON OGDEN: And this is horrible. But how do we fix this problem? How do we protect the folks that don't necessarily know any better, that the computer is infected? 

DAVID MALAN: Yeah I mean you'd like to think that these are anomalous situations. Where, at least if you're going to brand name places, you would like to think that you can trust them with higher probability than say some random person you find on Craigslist to disinfect your computer for you. 

But case in point, even the big fish company like Office Depot. For those unfamiliar, is a pretty big company in the US that sells office furniture and apparently will steal money from you and pretend your hard drive is infected with malware when it's not. 

So, as we've seen with Facebook and other companies, these mea culpas, big companies are doing this too. And maybe it's not systematically across the company, maybe it's some bad actor, or management, or one or few stores. But I think the nice thing about the software world, and the nice thing about the open source world is, that there's a lot of free products and tools that you can actually download at home. And while you might need a bit more technical savvy, it's definitely more convenient to be able to do it yourself. 

You can perhaps trust the process a bit more. At least if you have identified a good, compelling product or open source tool. Not some random thing that you were tricked into downloading, and that's a whole other can of worms there. But there tend to be popular programs that, frankly, I used to use when I used PCs more frequently. I would run them myself. And then when they did detect something, I would have it clean my own computer. 

It's definitely not something have to pay someone else for. But even for those least comfortable, honestly, invite someone over that you trust. Whether it's a colleague a friend or family member, have him or her run such software for you. And then trust their judgment, not necessarily a random third party. 

COLTON OGDEN: Back to the theme, of course, of trust. 

DAVID MALAN: Yeah. You have to trust, too, that your niece or nephew isn't coming over just trying to cheat you out of 20 bucks to scan your computer. But you can also just pay them to show you how to run the software, and then do this perhaps yourself. 

COLTON OGDEN: Always, always gets into somewhat of a dark realm when we talk about trust. In the context of, I think, general trust. But in the context of CS, especially. I think going down that rabbit hole can often be somewhat depressing. 

DAVID MALAN: Yeah. But I think this is true if we really want to depress ourselves in the real world too. Like driving a car, you generally need to trust that the other humans are going to obey the traffic laws, the traffic lights, so that you can behave in a logical way without actually hitting or being hit from someone else. So I think that's kind of omnipresent. 

And when you go out to a restaurant, you'd like to assume that everything is sanitary. And unfortunately I've watched far too many Gordon Ramsay shows and Kitchen Nightmares to know that I shouldn't be trusting all restaurants, actually. So I think this is not necessarily unique to technology, but I think it's all the more present lately. This concern. Or these threats. 

COLTON OGDEN: Yeah, certainly. Back more to the technical side of our discussion, and sort of related to the Apache thing. The other actor that you mentioned, Engine X. There was a vulnerability with some Cisco routers recently. The RV 320, and I think another series. 

And there was the RedTeam pen testing group that, I guess, ended up doing some tests on those routers. And found a config file in which it specified that one of the fixes for a vulnerability that they found was actually just a banned Curl. The program Curl. What are your thoughts on that as an approach? 

DAVID MALAN: Yeah, I think we have such a knack in this podcast already. Anything we have to say is not going to be positive when we point out that something was in the news it seems here. Technologically so-- 

COLTON OGDEN: I need to do some more research on positive, friendly topics. 

DAVID MALAN: We do. Well, what are some websites where you can see some puppies? Wholesome-- 

COLTON OGDEN: Well, this is the podcast, so people can't see anything. 

DAVID MALAN: That's true, so we need some-- 

COLTON OGDEN: We need audio clips of puppies. 

DAVID MALAN: There we go. Next time, next time in episode two. So Curl, for those unfamiliar, allows you to connect to a URL generally with a command line client. Or there's actually a library version where you can write code that connects to a URL. And you can use Curl therefore to download content or download HTTP headers. It essentially pretends to be a browser in a headless way. Without a GUI. It just does everything textually. 

And so in the case of this Cisco router, it seems as though there was indeed a vulnerability in their code, on the routers themselves. Such that you could trick. These devices into executing code that they were not supposed to execute. And that, in general, is a bad thing. You don't want a piece of hardware able to execute code that you did not intend. Because, of course, it can maybe do things malicious. It can steal data, write data, read data, delete data, any number of things could be possible. 

And it indeed seems that this penetration testing team noticed that, well, gee. It seems that Cisco's fix for this problem is just to blacklist a certain user agent, so to speak. And a user agent is a term of our, in HTTP, that refers to a string. A unique string that's passed from client to browser that says I am Chrome. Or I am Safari. Or I am Firefox. Or in this case, I am Curl. 

And this is useful just statistically so that servers can actually keep track of who's using which operating system, which browser, which piece of software, and so forth. But this is entirely the honor system, right. Every HTTP header in a packet from client to server could be forged. 

You can write code to do this, or you can even run Curl to do this using a command line argument. And so with dash capital A can you change your user agent string. And so with the RedTeam actually did, with the proof of concept here, is if you read the advisory, you'll see that they just changed it from Curl with a C. To Kurl with a K. Just to be cute. With a c. 

[LAUGHTER] 

That demonstrated that, essentially, the regular expression that Cisco had built into the server software, Engine X was just checking for C-U-R-L. So if you literally pass in anything other than C-U-R-L, for instance K-U-R-L, that request actually gets through. They didn't actually fix the underlying bug. 

COLTON OGDEN: Yeah. Such heavy-handed, but also such a simple, naive approach too. 

DAVID MALAN: It really is. In here too. Yeah, I don't necessarily fault the developer, because this is a mistake I might have made. I might still make perhaps. CS50 student might make, certainly shortly after graduating from the course. You need to be taught these things. You need to realize these things from news articles, or discussions thereof, but someone should have caught this. 

This also, not only being a technical mistake, is a procedural mistake. How did this slip through? Someone hopefully, and yet tragically, reviewed this code and said, yes. Ship it. This is OK. And that seems to be where the threat really is. 

COLTON OGDEN: Yeah it's almost operating under the assumption that user agents are baked permanently. They're immutable by default. Which clearly is not the case. 

DAVID MALAN: Well, to be honest. Not to get all lofty, but I'd like to think that in CS50, this is one of the things we do try to do. Not just with this topic, but many others. Where we really try to introduce students to low-level primitives. Case in point, we use C. Which is about as close to the hardware as you can get before you drop down into assembly code and actual machine instructions. 

And I think via that bottom up exploration, do you begin with higher probability, hopefully, than otherwise. To think about what threats might be, right. Even if you don't necessarily know that much about HTTP. You just know that there are these text based messages going back and forth from client to server. At some point, it probably starts to dawn on you. Well, wait a minute. If I can write software that generates requests, maybe I can just forge these requests. And indeed, all I have to do is print out this string instead of this other one. 

So we can't possibly in CS50, or any course, teach everyone something about everything. So if you instead focus more on the primitives the underlying building blocks. What is HTTP. What is a header. What is a TCP client. Can they begin to assemble for themselves critically what is actually possible and what those threats actually are. 

COLTON OGDEN: Yeah. Pretty amusing. Pretty depressing altogether. Seeing all of this things. 

DAVID MALAN: And these are the things we're seeing. Right. This is thanks to companies and people, like RedTeam, which actually noticed something like this. Can you even imagine how omnipresent these mistakes are that we just haven't discovered yet. 

COLTON OGDEN: Yeah. Thank goodness for folks like RedTeam and folks that are paying attention to the validity of things like the Office Depot scans. And question why Facebook is asking for their email, password, and bring it to the public conscious. Because otherwise this would be a little bit trickier. A lot of bad things might be happening underneath us, and we would be none the wiser about it. 

DAVID MALAN: Yeah. Well, and there's a term of art in tech. White hats, or ethical hackers, so to speak. People whose job it is, or mission in life, is to actually think like an adversary. Or sort of pretend to be the bad guy, at least in your mind, but to use those powers for good. And to actually build a business around or reputation around. Discovering these kinds of things. And honestly, it's taken the industry some time to get comfortable with this idea. Especially with outsiders. 

There's another term, bounties, for instance. And some companies, not all, will actually offer you a few hundred dollars, few thousand dollars, if you identify in a responsible way some security hole in their software. Report it via the appropriate channels. Not Twitter, but via email or some web form. And allow them a reasonable amount of time to fix the problem. 

And I think a lot of companies might be scared to invite that kind of attention on their code. But it probably is a net positive, and you get a lot of smart people trying to help you help yourself. The worrisome part is that if you just leave it to the bad guys, they're not going to be telling you when they find these mistakes. They're just going to be attacking your systems and your product. 

COLTON OGDEN: And it's going to be hard and this is something that I know you've mentioned many times. But it is practically infinitely easier being an attacker than it is being a defender in the computer science realm. 

DAVID MALAN: Yeah. We are on the losing end of this against the adversaries. We, if I may be so bold and to call us the good guys, we have to be perfect. We have to find and fix every possible mistake in our code. Every possible exploit. Fix every possible bug. But all the adversaries need to find is just one oversight, one mistake. 

It's like leaving, in your house, if you've got all the doors locked and dead bolted, and you've got the alarm system on. But you have got one window open already that the person can slip through. It doesn't matter, any of the other stuff. It all reduces to the weakest link, so to speak. 

COLTON OGDEN: It's so brutally unfair. 

DAVID MALAN: Yeah. But I think that's why talking about this and emphasizing themes in computer science classes, like that of trade offs and that of security itself, just gets people thinking more consciously. Because at the end of the day, it's just a cost, right. You could put bars on your windows, which would partly mitigate that threat, but there's a physical cost there. There's an aesthetic cost, and so at some point you just have to draw the line. 

But security really is all about raising the cost to the adversary. Either financially or time-wise, resource-wise. And just making it worth their while no longer to attack you. I think there's an expression along the lines of, security is all about getting the adversary to attack someone else. Right. Because if the price they must pay to attack you is too high, they're indeed going to turn their attention elsewhere. 

And so that's perhaps a bit of a perverse way of thinking about it, but that's how a logical adversary would presumably think about it. 

COLTON OGDEN: Yeah, even Nick and I were talking when we did a steam Kali Linux recently. Which Kali Linux is a version of Linux that has some tools built into it to help folks get into penetration testing. And he was saying that one of the biggest ways, easiest ways, to get adversaries to stop messing with you is just choose extremely secure passwords. And along those lines, generally speaking, just adopt as secure things as you can. Don't do a lot of things that are very easy to guess, basically. 

DAVID MALAN: Yeah. No, absolutely. Right. Because if you're running an attack script on your server and my server, and I have the longer more secure password. The adversary is going to get into your server and not mine, and then start focusing on you. So, woof! I escaped detection there. 

COLTON OGDEN: You've deflected the burden. And then ideally, in a world where your neighbor also does the same thing and so on and so forth. In a theoretical model, you don't have attackers at least doing as much damage nearly as they aren't now. Because they just can't find anybody to attack. 

DAVID MALAN: Right. No. So I think, ideally, you want societally to sort of raise the cost all around. And help each other patch these holes, because it does no one any good if attacks are being waged from other people's servers. Case in point, worse than a denial of service attack, or DOS, is typically a DDOS, a distributed denial of service attack, which is the act of an adversary taking over somehow multiple machines and using those multiple machines to attack one or some number of other parties. 

So it does not behoove me to allow your house to be broken into, so to speak, or your server to be compromised, because I could then be the next victim. Because your machine is now part of the threat. 

COLTON OGDEN: And you did a lot of this new PHD, right, with botnets. Right? 

DAVID MALAN: Yeah. A botnet is a collection of servers that has somehow been taken over by an adversary. By some virus or worm running on those systems. And a botnet is really just a silly term describing a whole collection of servers that have been commandeered by some adversary via some software. And it's among the scarier threats because via software commands, can that botnet do anything that a piece of software can do, including attack other systems. 

COLTON OGDEN: Yeah. It's pretty frightening. We will try and maybe segue into something slightly less frightening. 

DAVID MALAN: How can we play the puppy sound now? 

COLTON OGDEN: This could still have a slightly negative connotation depending on how you look at it. But I was doing a little bit of research within the last couple of weeks. Google has launched a sort of announcement, or preview for, a feature called AMP. Accelerated Mobile Pages for Gmail. Whereby, within an email, you can sort of embed these cool web page looking functionality driven mini pages I guess. 

DAVID MALAN: Yeah. Much more interactive snippets of HTML-like code in emails, especially, that make them, indeed, more interactive, clickable, more visually interesting. You know, I kind of have mixed feelings on this. Because on the one hand, you're just describing the web. And we can certainly just have users click on a link in an email and open up a full fledged web browser. 

And with it all of the protections that are in place from the browsers as to what JavaScript, for instance, can and cannot do. What HTML and CSS can and cannot do. And AMP is proposing to add some additional features, essentially by way of additional HTML attributes, and properties, and so forth. Other features into products like Gmail. And so, it's still kind of appealing to me. You even use the word cool, because it does make a static tool, that's been static for a very long time, a little more interactive. 

And I kind of am willing to accept that, because of the coolness, as you say. But really the additional features you can get. You can get carousels of images within an email so that you can stay in the email. See a bunch of images. Maybe it's an album that someone posted. Maybe worse. It's a series of ads or products that you want to flip through, but it makes them more interactive. Which keeping me in SITU, in the same place, is probably a compelling thing. 

We use Slack, for instance, within CS50 to communicate. Which is a chat based mechanism. And Slack has done an amazing job at adding integrations, or supporting integrations, via their API. Where you can have other products tap into Slack. So that you can stay in the Slack environment and execute commands that somehow influence those other products. 

And it's really convenient, honestly, to for instance, get a Slack message and be able to respond in that chat window, but have it posted to some other web server or some other tool. And so even I appreciate it. It's such a marginal difference. I can absolutely just click a link, go to a web page, and do the same thing. But I'm doing a lot per day. We're not getting any younger. There's only a finite number of seconds in the day. Every few seconds I can spend doing tedious work is probably some compelling time saved. 

COLTON OGDEN: Yeah. I think altogether I do agree that it is a cool, dynamic addition to Gmail. The one thing that I was thinking about as I looked at it was, would this make it easier for phishing attacks? 

DAVID MALAN: Yeah. Probably. Let's just assume, yes. With every good thing comes some bad. And, yeah. Because one of the features, too, besides carousels of images, you can actually embed forms, for instance, in the email. And allow the user to submit those forms within the email itself. And, yeah. I'm guessing that's going to be the first threat we see is someone tricking users into actually typing information into those websites. 

COLTON OGDEN: Yeah. I would just visualizing in my head an email from some malicious actor. But it's the Twitter login page. Oh, log into your Twitter to verify your account or whatnot. And that leading to some bad guy dot com or whatever. It seems like now it's all the easier for this because of that embedded form functionality. 

DAVID MALAN: Absolutely. No, I agree. No, and I think they could easily pretend to be some bank that they aren't, and actually then trick you into typing in your credentials, your account number, or some information like that. 

COLTON OGDEN: Sure. One of the last things that I think we might want to talk about before we wrap up is within the last few years it's been common, I think, to start see the big fish open source a lot of the technologies. Facebook open sourced React. Microsoft has open sourced VS code which is now arguably the top, I think, per number of stars, it's actually the top text editor on GitHub. 

And now Uber recently open sourced their resource scheduler, Peloton. And we won't go necessarily into the specifics on Peloton. But I wanted to get your thoughts on, are these big companies necessarily obligated to do this? Is this a good move on their part? how do you feel about this? 

DAVID MALAN: Open sourcing their software? 

COLTON OGDEN: Open sourcing some of their tools at least. 

DAVID MALAN: I am a fan of open source software. It is a wonderful entry point for aspiring programmers to cut their teeth on a product to which they have access. They can contribute back and kind of put a toe in the water. And learn more about real world software, especially if they're not quite ready or don't yet have access to like a full fledged developer job. Free, I think is a very compelling things and allows so many more people to solve problems using some common functionality. Libraries, frameworks, and so forth. 

You mentioned React, for instance. It's a wonderful set of shoulders you can stand on to do something even cooler and more impactful yourself. And I think too it's a shame that we have so many companies out there, in general, writing software that isn't necessarily juicy, intellectual property. It's not the core of their business, but it's a commodity type problem that others might benefit from. For instance, mapping tools from someone like Google. And some of the work, certainly, that Uber is now doing when it comes to their services. 

And so there's sort of a social good to open sourcing that. Because we humans have a finite amount of time on this earth. We might as well stand on each other's shoulders as best we can. And move ourselves forward and hope via karma, and sort of collaboration, will that benefit us in turn too. By our having initiated the same. So I think in principle it's a good thing. With that said, I think there are some costs. 

Even you and I, when we've written code, were embarrassed by it sometimes, if I might say. And I've written things that I don't really want open source, because it's going to take me a non-trivial amount of time to go clean it up, and comment it, and really feel proud of it. Such that I'd be comfy saying, hello, world I wrote this code. So there's that price. 

And a lot of companies might think. That's not our business. That doesn't generate revenue. That's not a good use of our limited human time. So I can appreciate the tension, but I think finding that balance is pretty compelling. 

COLTON OGDEN: Yeah, I agree. I think so. And given that so many large actors have been open sourcing. I guess maybe companies may start to get a little bit of pressure to think, oh all these other companies have all these awesome projects out there that people are using, and seeing, and contributing to, but we don't have anything. Do you think that's something that companies should, and will, worry about? 

DAVID MALAN: I don't know, to be honest. It's a worthy experiment to see. I think that it's a potential recruiting tool, right. If you gain exposure to some company because you are using, or looking at, or contributing to their software. It feels like a very natural next step to aspire to have a part time or full time job with them. 

And so honestly, strategically, it might help you identify amazing developers, because you have these volunteers essentially initially contributing freely to your product via open source. Whether it's on GitHub or somewhere else. Submitting pull requests, and participating in issues, and reporting bugs. And you kind of get to know someone and then can very comfortably say, you know what. Why don't you come onto our side of the fence and do this full time? So I don't know if that's a theoretical upside, or an actual one, but it certainly feels worth trying on some scale. 

COLTON OGDEN: And that's been actually achieved at CS50 too, right. Folks like Kareem, and Chad, and other folks that have worked with us. 

DAVID MALAN: Yeah. To be honest, and that was actually very organic. It wasn't part of some overall clever strategy, I'll admit. We discovered Chad Sharp because he was submitting pull requests and opening issues on some of our open source libraries. And Kareem, of course, was contributing so actively in CS50's Facebook group and later to software development. 

And it's a great way to get to know someone in a way that's not a more traditional 30 minute interview where everyone's trying to impress the other person. You don't really have a sense of what's it going to be like to work with this person on a project. Open source software makes it very easy to get to know, and become friendly with people, and technically collaborate with people in a way that a whiteboard and a conference room don't really allow. 

COLTON OGDEN: Yeah. It's much more organic. 

DAVID MALAN: Yeah. Hey, case in point, Colton and I met primarily by playing Scramble with Friends as I recall to-- 

COLTON OGDEN: That's a very professional way to get acquainted. 

DAVID MALAN: I noticed you're very good with words, and here we are talking. 

COLTON OGDEN: I don't even know if that's true. 

DAVID MALAN: OK. Well, I'm trying to say something nice. 

COLTON OGDEN: I appreciate it. I have fond memories of losing almost every single match of that actually. 

DAVID MALAN: But you kept trying. And that was what we were looking. 

COLTON OGDEN: I think it was the banter. It was the friendly banter. 

DAVID MALAN: Well, and to be fair too, we got to chatting early on with CS50 because you offered to get involved with the transcriptions. And helping us actually caption things for folks for whom English is a second language, or who would need it for accessibility sake. So that was a very worthy contribution as well early on. 

COLTON OGDEN: It's been fun. It's been good. And we've only done more and more in that domain. Which is great. 

DAVID MALAN: Case in point. I have not played Scramble with Friends for years. 

COLTON OGDEN: We haven't had time. Well, I think that's a good amount of topics to cover, actually. Are there any takeaways that you'd like to say for the folks listening in? 

DAVID MALAN: Be afraid. Be very afraid. 

COLTON OGDEN: People are going to stop tuning in. They're going to get too depressed. 

DAVID MALAN: That is true. Go Google some puppies right now if you could. But no, I think the real takeaway is to just be more thoughtful and deliberate about choices you make. And yes, there is the theoretical risk that data you're inputting into a website like Facebook might be misused. But does the value of your gaining by using that tool perhaps outweigh that? 

And as we discussed earlier, you want to make sure that you're not making all of those locally optimal decisions again, and again, and again. Such that weeks or months later, you look back and realize, wow, I globally made a very poor decision, because now this website knows everything about me. So I think just making very conscious choices along the way and realizing what prices you're paying, and what benefits you're getting, is the real takeaway. 

Because these threats have been omnipresent. Not just in tech, but in the physical real world as well. And so I think being sensitized to them is the real takeaway. 

COLTON OGDEN: Getting sensitized and getting educated too, probably. 

DAVID MALAN: Absolutely. 

COLTON OGDEN: Tune into places like Hacker News. Tune into the CS50 podcast. This was episode 1. It was a pleasure. And I look forward to doing the next episode with you. 

DAVID MALAN: Chat with you all soon.