[MUSIC PLAYING] SPEAKER 1: One year ago, in this quiet library, in this cozy studio, something happened, something so frightening-- SPEAKER 2: Ah. SPEAKER 1: Something so deadly-- something so evil-- we prayed it would never happen again. SPEAKER 3: Ah. SPEAKER 1: Now from the creators of CS50 Live comes CS50 Live. DAVID J. MALAN: Hello, world. This is CS50 Live, season one, zero indexed. That's right. We've been picked up by Harvard for another season. And boy do we have an amazing episode for you today. First we'll take a look back at the most popular passwords of this past year, we'll look at a nasty bug in a popular gaming platform, we'll give you a new definition of the word evil, and we'll pay a visit to our friends at Google. No relation. But first, let's take a look back at season one. [MUSIC PLAYING] Hello, world. This is-- SPEAKER 5: CS-- RAMON GALVAN: 50 Live. I'm Ramon Galvan, filling in today for David-- DAVID J. MALAN: Who's lost his voice. RAMON GALVAN: Today, he'll be the Andy Richter to my Conan O'Brien. [MUSIC PLAYING] DAVID J. MALAN: And now for our first bug fix. This is of course season zero's look back and not season one. But what else is new? Well, it turns out not much in the world of passwords. In fact, the most popular password of this past year was as before 123456 followed closely in second place by old school, password. However, in third place this year, up 17 places, is our old favorite 12345, which you may remember from such films as this one here. Now in 17th-- in 25th place, meanwhile, is a newcomer, dragon, perhaps because of such films as this one. Now in 25th place-- and now for our second bug fix of the season. Whereas that was in ninth place, dragon, we're now going to take a look at 25th place, trustno1. Now if you think you've been oh so clever by using one, the number, instead of one the word in your password, well, rest assured that so have millions of other people. Now you may recall this expression from such films as this one here. And speaking of Scully, we'd like to welcome aboard to CS50-- CS50's newest team member, Scully, pictured here at a recent field trip to a CS50 ice skating rink. In fact, can we enhance? No. Can we enhance? Yes, indeed. That is our Scully. Welcome aboard. And now a nasty bug in a popular software from our friends at Valve Software called Steam, which is a platform for downloading and then playing popular video games. Well, turns out that a user recently reported to the Linux community for Steam's client the following bug. He moved his local share Steam directory, he ran Steam, and it deleted everything on the system owned by user. In other words, simply by moving one of his folders for this game, Steam-- for this platform gaming-- for this gaming platform Steam, he ended up deleting all of the files on his hard drive. Now what's fascinating, if you take a look at this thread on github.com is you'll see that the community chased down the bug to this line here, which declares a so-called environment variable on the left, assigns it the value here on the right. But unfortunately, it turns out if you do move a certain directory, this value you can evaluate to just quote unquote, or the so-called empty string. Now unfortunately, later in the file was this very dangerous line here. rm-rf and then STEAMROOT slash star. Unfortunately, if STEAMROOT is itself the empty string, this becomes just slash star, which of course, has the effect of saying, remove recursively and forcibly everything in the root of my hard drive. Now thankfully, this particular fellow had backups of all of his data. So not all was lost. But if you'd like to take a closer look at this bug and the resulting fix therefore, go ahead to GitHub's URL here. And now a word from our old friend Cookie Monster, who's holding in his hands here Verizon, who gives us today our new definition of the word evil. You may recall a few months back that Verizon, as well as another popular cell phone company in the US, AT&T, were injecting so-called super cookies into the mobile HTTP traffic from folks like me who are using phones to access the internet. Specifically, they were introducing into our HTTP traffic a header called UIDH, which essentially inserted a unique value associated somehow to my cell phone and perhaps your cell phone so that any website that receives that value can know that this is me again, and again, and again. Of course, this effectively allows websites to track me under the premise of serving up more effective advertising, but nonetheless maliciously potentially, keeping track of who I am. Because in fact, even if I delete all of my phone's cookies and even if I use my browser's Incognito Mode, this UIDH header is still being injected by a company like Verizon. Now thankfully, Verizon recently announced that they're going to let us finally opt out of this horrible, horrible practice. And yet all along, they've been assuring us the UIDH was designed with privacy protections in place. It changes automatically and frequently and does not contain any customer information. Now the last of those claims might be true. But this is ridiculous to claim that by changing it periodically and automatically, you're actually protecting us users. Consider after all how a malicious website can figure out who we still are. If this is me here on the left trying to visit a website like this on the right, and suppose for the sake of discussion that this website on the right happens to be running PHP, and therefore uses session cookies, and gives me a value called PHPSESSID to remember who I am as with one of those digital hand stamps. Well, the next time I make an HTTP request to the server, I'm going to present that hand stamp, PHPSESSID, and it might equal ABCD. But meanwhile, Verizon, as a so-called man in the middle, is going to be injecting a little something like this, UIDH:1234, which is my unique identifier so long as Verizon is concerned. Now so long as this website remembers that, he can correlate of course ABCD with 1234. But suppose the next time I visit the website, I again send that same cookie, ABCD. But Verizon is now claiming that they're protecting me by changing my value to say 5678. Well, it doesn't take a particularly sophisticated line of code to realize ABCD used to be 1234. Now ABCD is 5678. Let me update my own database so that I realize that 1234 and 5678 are and have always been the same person. It's not much protection indeed. Now for more details and to learn more about these kinds of threats, head to this URL here. And if you'd like to be paranoid, and you should now be, head to amibeingtracked.com. And now for a new segment altogether. You know that depictions of technology are quite popular in today's films and TV. But they're not necessarily always accurate. In fact, let's take a look at a popular film from yesteryear, Weird Science, and pass a little CS50 judgment. Let's roll film. [VIDEO PLAYBACK] Here we have two fellas trying to hack into a computer system using an age old modem by putting the phone on top of the computer. This man is now defending himself against the attack. If you've ever wondered what it means to hack, this of course, is what it truly is. Those are some backup tapes. Yeah, access. That's what happens when access is denied. Now wait for it. Wait for it. Bowling alley effect. And now we have to choose. How are we going to hack this? We're going to hack to the left. Yeah, no. That was the wrong choice. Let's try again. Back up. Let's go down the middle. Here we go. All right. Wait for it. Wait for it. I wonder what time it is. Oh. Oh, and physics, of course, is relevant. SPEAKER 6: We're in. [END PLAYBACK] DAVID J. MALAN: No. No. No. We're not in. That's enough of that. But if you'd like to learn a bit more about this, Google Weird Science. And in fact, speaking of Google, we recently headed out to Mountain View, California to meet with two of our friends from Google to talk with them about what it's like to develop software in the real world. In fact, we met with them outside of the actual building in which Android software is developed. Let's take a look. ANDREW SELLERGREN: My story starts senior year of college in 2007. I was a chemistry major and planning to go to medical school. I signed up for CS50. This was the first year that David was teaching. I loved it. I loved every minute of it. David was nice enough to invite me back the next year to be a TF for CS50. I bounced around a little bit after college. I didn't end up going to medical school. And I decided to teach myself more about computer science. And I ended up getting a job at Google. And I'm now on the Android team. JOHN NICKERSON: Here at Google, I work in the Anti-Abuse engineering department and our product quality operations group, specifically fighting click fraud on our ad networks. ANDREW SELLERGREN: Recently, I've been working on a website. And of course, at Google, developing a website means you want to be able to serve millions of users. So we have to get things like load balancing in place. We have to make sure that the static content gets served very quickly and is optimized for all of our users. And in order to test this, one of the things we do is we write integration tests. So we have to bring up all of our servers, including the login servers, the static content servers, bring those all up, and then test that our website loads. So we use a framework called Selenium, which is open source. And it allows you to fire up a browser and actually load your website in it, and then perform actions on it. The interesting challenges are digging into those logs, figuring out what's going on. And that's what I've been wrestling with the last week or so actually. JOHN NICKERSON: Ran into an interesting problem where we were dependent on date and time. And when you think about date and time, you usually only think about your local system because you're coding on it, and you compile on it, and you run on it. But what happens is when you're in a global-- you have a global footprint with data centers all over the world, local time doesn't really mean anything anymore. So we realize that local time was actually causing problems because the database that all of our data was stored in had a timestamp. And so timestamps now were very timezone dependent, which none of the code accounted for. And so what we ended up realizing was that all of a sudden, jobs were running that they thought were running eight hours in the future were actually running presently. The end result was to just normalize any time we're using date times to make sure they're in either UTC timestamp so that we normalize the time, or just double check to make sure that we're running in an environment that is known at the time so that we don't run into these sorts of weird math time calculation problems that we did. ANDREW SELLERGREN: Hello, world. I'm Andrew Sellergren. JOHN NICKERSON: And this is CS50. DAVID J. MALAN: And now for a special treat. At Harvard, there's a tradition of shopping for courses whereby students can take a look at classes for the week at the start of the semester before actually enrolling in those classes. We thought we'd honor this tradition by producing CS50's first ever music video toward an end of getting students and hopefully you excited about what awaits in CS50. This is "Funk 50". SPEAKER 7: Do. Do, do, do, do, do, do. Do, do. Do, do, do, do, do, do, do, do. Do, do, do, do, do, do, do, do. Do, do, do, do, do. SPEAKER 8: Learn C that good code, JavaScript for that net gold. This one for them undergrads, them hackers, straight coding beasts. Typing, while I'm compiling it on stage. Got hoodies on with Rob Bowden. Got to go with CS50. We can't stop. SPEAKER 9: Oh yeah. SPEAKER 8: Called a crimson and a bulldog. Code a lot. SPEAKER 9: Oh yeah. SPEAKER 8: Make Zuck want to come back again. We can't stop. SPEAKER 9: Oh yeah. SPEAKER 8: What a name, that Harvard man. Why not? SPEAKER 9: Oh yeah. Am I good about that fair. Break it down. Course is your hallelujah. Puzzles be coming to you. Course is your hallelujah. Because these Malan going to teach it to you. Because your TF going to teach it to you. Because you for sure going to learn it to you. Thursday night and we in the Berg. Don't believe me, just shop. Don't believe me, just shop. Don't believe me, just shop. Don't believe me, just shop. Don't believe me just shop. Don't believe me just shop. Hey, hey, hey, oh. CS50 what? Come on, code it up. CS50, what? Come on, code it up. CS50, what? Come on, code it up. CS50 what? DAVID J. MALAN: That's it for CS50 Live. Thanks so much to Oleg, and Joe, and Patrick, and to Dan, Shelly, Colton, Ramon, and our newest team member, Scully. This was CS50. [MUSIC PLAYING]