Transcript for:
Privacy Preservation in Technology

[MUSIC PLAYING] DAVID J. MALAN: All right. This is CS50's Introduction to Cybersecurity. My name is David Malan. And this week, let's focus on preserving privacy. Indeed, over the past several weeks, we've focused on securing your accounts, your data, your systems, your software. And all of that is really about keeping communications between points A and B, for instance, secure, so that no one in between can actually access the information you're trying to share. But what if you, A, don't even want B to have some of that information? So indeed, today, let's focus on some of the technologies that you and I use every day and some of the technologies that underlie the software, and applications, and more that you and I are going to use tomorrow and beyond and consider exactly what information we're sharing now, perhaps, even without our knowledge and also empower you with certain mechanisms via which you can perhaps restrict all the more of this information if you, indeed, do not want to share it beyond yourself. So let's consider first some of the obvious features that you and I probably use every day, like your web browsing history. Whether you're on a laptop, or desktop, or mobile device, odds are you know by now that your browser tends to keep track of pretty much everywhere you go on the World Wide Web. That is to say, if you click on your URL bar, you can sometimes browse through the past few URLs that you visited. If you go up to your browser's history via some menu, you can probably see everything you've done earlier today, yesterday, last week, last year, or perhaps, even the entirety of your history, particularly, if you're logging into your Google account, Microsoft account, or something else. So the web browsing history is sort of both a concern when it comes to your privacy, but also a feature. Well, let's first consider the feature. Well, why is that useful? Well, one, I mean, even I occasionally go back through my history trying to find some web page that I know I was looking at earlier in the day, or yesterday, or some previous time in the past because it just helps me find information more quickly. And so in that sense, it might solve a problem for me. Moreover, you probably have noticed that your web browsing history is often used for features like autocomplete. So when you start typing a URL or maybe even a keyword that was in the name of a page, your browser might remember much more quickly what it is you're looking for. So you can just hit Enter or click. And voila, you're at that same page. But of course, this is a concern, potentially, for your privacy, whereby, you might not want someone else who has physical access to your device to start poking through where it is you've gone. You might not want someone else to have access if you just so happen to visit that website or those websites on maybe a computer in a lab environment, or an internet cafe, or the like. So you can imagine quite a few scenarios in which this is, yes, a feature, but quite a few other scenarios in which this is not really a desirable feature because it invades your privacy in some sense, or at least, puts it at risk for being invaded by someone else. So we'll consider how we might at least sanitize this history or remove it altogether in ways that you might already know about. For instance, you're probably already familiar with some option in your browser, whereby, you can clear your browser history. And that forgets, therefore, all of the places that you've been, all of the cookies that you might have accumulated, all of the usernames and passwords that might have been remembered by your browser. Although, that tends to be a fairly heavy-handed solution because when you clear your browser history, assuming you check all of those boxes, all of it is gone. And that might mean negatively that you're now logged out of Google, you're now logged out of Outlook, or some other account that you actually still want to use, even if you just wanted to clear your history from something else altogether. So we'll consider then what else might be a concern when it comes to your privacy beyond your own browser. And in fact, it doesn't even matter if you sanitize your own web browsing history and delete the entirety of it because it turns out that typically, any website you visit is, itself, on the server side also keeping track of a lot of that same information. That is to say that servers typically have logs. And these are not only for diagnostic purposes. In case anything goes wrong, the IT staff can use those logs to reconstruct history and figure it out, figure out who was doing what and when and how that might explain some problem. It might be used for auditing purposes if they want to keep track of exactly what was accessed on a system. It might be used for advertising purposes or analytical purposes more generally to mine or analyze that data to figure out how we might monetize it or do something else with that same information. But what do we mean concretely when we say that information is logged on a server? Well, it's very similar to your own web browsing history, but it's even more detailed. So here, for instance, is a representative piece of configuration that captures what is a very common convention for information that servers log, web servers, specifically, when you visit them with a browser. And I'll highlight just a subset thereof. This log format, the so-called combined format, indicates to me that it's very common for a server when you visit some web page on it that the server will log, that is, remember your remote address, otherwise known as your IP address. It will remember the day and time at which you accessed that page. It will remember exactly what you requested, so the name of the file or folder on the server specifically that you sought to download or look at. It'll remember the referrer, that is, the URL from which you came. And it will even remember the user agent that you use, that is to say your browser. So perhaps, unbeknownst to you, every time you use your browser to visit some website, inside of that virtual envelope is quite a bit more than just the request that you're making of the browser-- of the server, rather. It includes, yes, your IP address and on the outside of the envelope, as we've described it in the past. It includes some number of HTTP headers, as we've discussed in the past. But in particular, it includes information that you might not want being stored on servers in perpetuity and you have no control over deleting necessarily. Unless there is some regulatory requirement or law that requires that the server delete it for you on some schedule, you have much, much less control over this information. So let's consider in a bit more technical detail what some of this information is and how you might at least exert some control over just how much of that information is being shared. So let's revisit first this building block of HTTP headers that we keep coming back to if only because in the world of systems and software nowadays, things on the web are just so common. Using HTML, CSS, JavaScript, using web browsers and web servers, that's driving a lot of today's interactions with technology, whether it's in native applications or whether it's with mobile websites, or desktop websites, or the like. So HTTP headers, recall, are just like key value pairs that are inside of those virtual envelopes that indicate some kind of setting or some kind of piece of information that the browser is sending to the server or that the server is sending to the browser. So for instance, if I go on google.com and I search, as I often do, for cats, well, what might be going on underneath the hood? Well, in that web page that Google gives me with 10, or 20, or 30, or six billion, 240 million cats, there might be HTML that looks like this. And recall that this HTML, which I'm proposing exists somewhere in Google search results, is an anchor tag for a link. There's the n tag over there. The hyper-reference for this link, or href attribute has a value of https://example.com, for instance. And the word that the human will see is cats, literally in this case. Now, I'm assuming for the sake of discussion that today, example.com is a website full of cats. And that's why it might be appearing among Google search results when I search for cats as my keyword. But when a user like you or me clicks on that link on google.com, because that is literally where you're looking at the search results in this story, it turns out that your browser not only goes and requests that web page, your browser includes an HTTP header like this in that virtual envelope. That's specifically called referrer-- that's the key in this case-- the value of which is the URL from which you came. So for instance, if I have just gone to google.com, and I've searched for cats, and I've hit Enter, recall, as in past classes, I proposed that the shortest version of the URL that you might see in your browser upon searching for cats is this, https://www.google.com/search?q=cats. Now, that is what you'd see in your URL bar. Below that, you'd see the 10, or the 20, or the 30, or the six billion, 240 million cats, each of which has a link that when clicked, leads you to a search result. But the implication of this HTTP header is that by default, perhaps, unbeknownst to you, indeed, your browser is telling the whole world from which web page you came when you visited some other web page via a link. Now, why in the world is this compelling? Well, it's actually useful for the website at which you end because it might be useful for their analytics. They might want to know, well, how are people finding my website? How are people finding my business on the internet? Oh. It looks like I'm getting a lot of users, a lot of customers, perhaps, from google.com, specifically, when someone searches for cats, not dogs, not something else, but cats. So you can imagine, especially in the world of commerce, that just being useful information to know how people are finding you, or conversely, how people are not apparently finding you. But this is very invasive because now this website, even though it's arguably none of their business, they know I use Google instead of Bing or some other search engine, perhaps. And you can imagine that there could be links on CS50's own website, on any number of other websites in the world. And just because you happened to visit them and you clicked a link, now they're broadcasting your business to whatever website you're ending up on by revealing where you came from, from where you were referred, so to speak. But this is long been a feature of HTTP. And this has long been a feature that's enabled by default, unless the website, or perhaps, you, as the user, turn this off or somehow moderate its response. Now, some of you might be noticing that there's a bit of a typo on the screen. And I promise, this isn't actually mine. In English, at least, this is not typically how you spell the word, referrer. And this is actually a fun fact. In referrer, there should be four R's in total. It should be R-E-F-E-R-R-E-R. However, fun fact, years ago, when the specification for this standard was being written, the poor individual who wrote the specification made a typo that has been immortalized in history for years to come. And so this is what browsers and servers have been using and expecting for years. There are other variants of this header that these typographical error has been fixed in. But it's sort of a fun fact from our internet history. But this is, indeed, what you might see going from your browser to your server. So ideally, we'd send less information, at least. I'd be a little more comfortable if example.com, which is this website for cats, told them, OK, fine. I came from Google. That's not a big deal. But I'd rather you not know what I was looking for if only because that seems unnecessary. It seems invasive. And who knows what kinds of cats I was looking for? Maybe I don't want you to know exactly what my preferences are in cats, or dogs, or whatever types of breeds there might be in this case of searching for animals. So it just feels like it's unnecessary information to share. But better still, I dare say, would not be to even tell example.com where I'm coming from and essentially just get rid of this altogether. So how might a website go about moderating just how much output comes from the browsers at the server's request? Or maybe, how might you with special software suppress some of this information to preserve all the more of your privacy and what it is you're doing online? Well, for instance, this is a common tag that web pages can put in their own HTML code that indicates to the browser that, yes, you may send the referring address, but only send the origin, that is, https://www.google.com/. And that's it, no search, path, no ?q=cats. Tell them the website you came from, but not the specific page or not the specific search query or search results. Notice here in the world of HTML, the typographical error has been fixed. There's two R's in the middle there. But otherwise, this is an HTML solution to the problem. The browser, assuming it respects this HTML, will therefore, send and refer HTTP header, but with less information, not the whole URL, but just the origin, so really, the domain name, itself, and a bit more the protocol. If you don't want any of that to be sent for your users, for your customers you could do this instead. Now, Google does not do this. Google currently actually sends origin, so part of the URL. But if you want to be an even better citizen and not make it easy for browsers to send more information than they need to, you can include this HTML in your page instead, informing the browser that you can send-- don't send a referrer at all because the value of this meta tag, so to speak, is actually none instead of origin. And there are other values as well that allow you a bit of range of opportunities when it comes to these settings. But these are, perhaps, the most common or ones to consider. There's an alternative too. If you happen to be a little more technical and you have control over the web server and not just the HTML on the server, you can actually configure a referrer policy, HTTP header, that goes from the browserver to the browser. So in this case, the referrer policy can indicate that you only want the origin to be sent, for instance, the shorter form of the URL. Or you can actually indicate that no referrer should actually be sent in this particular case, so a second mechanism for actually controlling the same. Let me pause here and see if there's not only some concerns, perhaps, now that you understand better, hopefully, how the web works, at least, by default or how we might mitigate this concern with your privacy. AUDIENCE: Is there a way that is easy enough for us to delete those traces as a client in case that we don't want to be tracked or something like that? DAVID J. MALAN: A really good question. We'll refer you to some URLs outside of the context of class, itself. But yes, there is actually client-side software that you can install on your own Mac or PC, typically, that will scrub some of this information, so that when your HTTP requests you go from your browser to servers, you can ensure that this third-party software removes a lot of that information automatically for you because in that way, you don't have to trust that the website, like the Googles of the world will actually reduce the amount of information for you. You can instead do that for yourself through client-side software. And we'll provide a few links online. Other questions on the same? AUDIENCE: By using a private browser such as Tor, for example, or using a temporary operating system like Tails, does this remove all of our traces on the internet? Or does it leave some on the client side or the server side? DAVID J. MALAN: A good question. Short answer is that it does leave some evidence on both the server side and the client side. But we'll come back to Tor in just a little bit as well. All right. How about one final question? AUDIENCE: You said previously about the third-party software that's supposed to be used in order to scrub the information from being submitted to the server side. What if that program, itself, is used to eavesdrop on what we do on the computer? DAVID J. MALAN: That is a very valid concern. It is absolutely possible. In general, what is working in your favor is either open-source software, where if you're using software that other people can see the source code of, presumably, it's less likely that it's doing something malicious. Capitalism often helps you here too, whereby, it is often not in a company's own interest to be violating the privacy of their users because presumably, that would create some form of backlash, which would not be good for business. But beyond that, there is a lot of trust on your part and my part whenever it comes to installing software. So that is, indeed, very much a risk. Now, it turns out there's other information that your browser might be sharing without your realizing that it's making it available. And that information is enough via which servers can even fingerprint you, so to speak. That is to say there's this technique generally called fingerprinting that in the context of the web means to take as input a whole bunch of characteristics of the request from the internet that's coming in and see if you can use those characteristics to create a profile of sorts for the user via which you can uniquely identify that user. Now, that doesn't mean you'll know specifically that user is David Malan. But you will know, according to this system, if it's the same user today, as you see tomorrow, as you see the next day because you can use this information to infer with high probability that, OK, we saw that exact same browser configuration again, and again, and again. Odds are it's the same person and not some twin on the internet who just happens to have precisely those settings. Now, how might this be implemented or achieved technologically? Well, the simplest mechanism, perhaps, is just to rely on something like your IP address. Recall that any time you're doing something on the internet, those virtual envelopes we keep talking about have your IP address on the outside, so to speak, as well as the IP address of the destination to which you're trying to send information. Your IP, in that case, is the return address, which means you're literally telling the remote server when using certain protocols where you are in the world, or at least, what your IP address is. Now, that IP address might not alone uniquely identify you because it turns out on campuses, in homes, in corporate networks, you might actually share one IP address with many other people, but at least narrows the scope of whose IP it might be, even if it's shared among a few people. But your browser inside of that virtual envelope is sharing other information as well. Another HTTP header that is typically sent by browsers to servers is called user agent. And this is just a unique string of text that uniquely identifies typically the browser that you're using and the version thereof and the operating system that you're using and the version thereof. So for instance, a standard format might look a little something like this. And it's deliberately overwhelming. And it's just meant to capture how much detail might be leaked in this header's value. But within this big string of text that doesn't even fit onto one line-- it's wrapping here under three lines-- is some indication of what browser you're using, be it, Chrome or something else and what operating system you're using, be it, Android or something else on a phone, a laptop, or a desktop. Now, of course, a lot of people in the world presumably have the same browser installed. So that, too, even with IP address, might not be enough information to uniquely identify you, at least, with high probability. So what else can servers do? Well, if the server has the ability to send some code to your computer, for instance, some HTML, some CSS, and some JavaScript, servers can effectively interrogate the browser and ask it certain questions. For instance, a server could figure out what the resolution is of your screen. Now, this might be practically useful, so they know how to render information on the screen. But that alone might be enough. Especially if you're in the habit of full screening your browser and you always use the same resolution on your monitor, that might be another ingredient with which to identify or fingerprint you. The server might be able to figure out what fonts you have installed on your system. The server might be able to figure out what time zone you are in because that's also a value available within the context of a browser. And there's yet other values still that collectively with high probability can be used to fingerprint you and me. So even if you're not even logged in, even if you're using various privacy enhancing software products to try to remove some of these HTTP headers and the like, you're still leaking other information, including the extensions or plug-ins, sometimes, that your browser might have installed. So if you're in the habit of using the same computer again and again and you're in the habit of not changing a lot of these settings, that alone might be enough for a website to effectively track you. Now, it might be innocuous. They might just use this for statistical purposes to get a sense of how many users or customers they have. But it could be for more invasive purposes, like serving you targeted advertising, based on your behavior of these websites, or really, just tracking you, specifically. And the catch is that if you ever log in to this server just once, if the server has been logging all of your traffic based on that fingerprint for days, for months, for years, at that point, retroactively, with high probability, they can infer, oh, wait a minute. If the user on this day was David and we think it was the same user on all of these previous days, now by transitivity, they know a lot more about your browser history as well. So even unbeknownst to you, and even without explicit header values being sent that identify you, the collection of attributes or characteristics that our browsers have and our browsing behavior has can still be enough to uniquely identify most of us quite a bit of the time. Let me pause here and see if there's any questions on fingerprinting or these implications for privacy. AUDIENCE: Will using a VPN prevent browser fingerprinting? DAVID J. MALAN: A good question. And we'll talk about VPNs a bit more soon. Short answer, no. So VPNs will typically mask your IP address, but that's about it. If you still use your browser as usual with your user account as usual, all of that same information is going to be leaked. It's just going to change one piece of it. A good question. Other questions on fingerprinting and privacy? AUDIENCE: Is it possible that a hacker can steal a fingerprint and use it for their own purposes and everything will look like it was my computer that performed certain actions? so it's like stealing an identity. DAVID J. MALAN: A short answer, yes, if the hacker has access to the same information. If though, if we rewind to our focus on encryption a couple of classes ago, if you are accessing websites only via HTTPS and nothing is unencrypted, then it's going to be a lot harder for a hacker in between you and that server to glean any of the same information because almost all of it is encrypted. IP address is not. But anything inside of the envelope is, including these headers, the HTML, the JavaScript, and the CSS. If, though, the hacker has somehow infiltrated your own laptop, or desktop, or phone, or the server, then all bets are off. And they could absolutely identify you, according to these same pieces of information. Other questions? AUDIENCE: I was just curious to understand the difference, perhaps, when you are on mobile. My understanding is that they can even get much more information when you are on mobile. DAVID J. MALAN: That's a fair question. I don't think I would answer yes to that. I'm hard pressed to imagine what more your phone is doing than the browser is doing, except that there are-- I suppose I could argue that your phone tends to have additional features nowadays, like GPS, like accelerometers, gyroscope, perhaps, so other hardware features that theoretically can be interrogated by JavaScript code, typically, on an opt-in basis. So you, the user, could deny access to these pieces of information. But those characteristics, I suspect could be used to identify you a bit more uniquely because laptops, at least, today, have less of that functionality. Other questions? AUDIENCE: When storing and retrieving data on the front end, is it more secure to use cookies, local storage, or another alternative? DAVID J. MALAN: A really good question. And we will come to this subject literally in one slide, cookies. In general, local storage because cookies, by design, are meant to be sent back and forth, back and forth between browser and server. Theoretically, that should not be a concern if everything is encrypted. But we've talked in the past already how mistakes can be made. You might start on HTTP, be redirected to HTTPS. So in general, storing things in local storage, at least, prevent things from accidentally leaking out over the browser connection. That said, if you're storing things in local storage, they are literally available locally. So if you have a colleague, a friend, a sibling who gains physical access to that device, let alone, an adversary, then they could see all of the information and not only your cookies, but also local storage. So at that point, physical access, generally, all bets are off when it comes to your privacy. All right. How about one other question? AUDIENCE: There were calls being made from people's local phone numbers on cell phones to other local numbers. Obviously, the people weren't making the calls. And it had happened to me too. And I was wondering how that kind of works or if it's related to this at all. DAVID J. MALAN: It is. We weren't planning to talk about it today. But in a nutshell, it is very easy to spoof telephone numbers. And this is how a lot of spam calls are sent, particularly, internationally or abroad, where they might not be regulated in the same way as someone's home country. It's very common, too, for if your number starts-- your own phone number starts with 555, for instance, very often, you'll get fake calls from other numbers that also start with 555 because the presumption by the adversary is that, oh, Sabrina's probably more likely to pick this up if she thinks it's a neighbor with a similar looking phone number. But unfortunately, with the phone system, it's all too easy to fake phone numbers. And this is yet another reason why using phones, using SMS, is not a recommended approach for our earlier topic about multi-factor authentication. It's just not a secure network. That's not how Edison and others designed it 100-plus years ago. This is why systems that use cryptography in some form are much safer when it comes to that information. All right. So beyond this user agent header, there's other headers that your browser is often sending back and forth with the server. And one of these we've talked about, and one of these you probably came into the course knowing about, namely, cookies. But there are different types of cookies. But recall that in general, a cookie is a piece of information that a server puts on your computer to help remember who you are. So in the absence of these fingerprints and the absence of specific headers like these, it can just put a small random value with numbers and letters or the like on your computer or maybe even a bigger value if it has lots of users. And it uses that value to uniquely identify you if you return again and again to the website. It doesn't necessarily know that I am David, unless I log in at some point, at which point, then it can realize, oh, wait a minute. David's cookie is this value. Now I know who this user is. But in general, there are different types of cookies and different settings for cookies that are worth knowing a little something about. So we talked previously about what we'd more properly call session cookies. So session cookies are used by servers to maintain state, so to speak, between the server and the browser. That is to say, without getting too technical, HTTP is typically stateless, whereby, when you visit a page, the browser icon might spin for a bit. And then it stops because the transaction between the browser and the server is complete. But if you want to remember who the user is, therefore, the second, the third, the fourth time, the browser contacts the server. The browser had better remind the server who it is. And this is why we use the metaphor of the virtual handstamp, whereby, that handstamp is the browser's way of reminding the server, you've seen me before. Don't make me log in again. I am David. I am David. --even though it's just relying on this virtual handstamp or really some unique identifier that's going in the cookie header from browser to server. So a session cookie allows browsers and servers to maintain sessions, this kind of state. A little more concretely, it allows them to maintain things like shopping carts. So if you're shopping on an amazon.com or the like, the session cookie is what remembers who you are, or at least, that you're the same person, so that every time you poke around on the website, Amazon shows you the same contents of your shopping cart again and again, so that they don't lose your business by accidentally deleting it when you simply change the page. So how do session cookies work? Well, when you first visit a website that wants to plant a cookie on your computer, the response might look a little something like this. HTTP. 200 is the status code, which, recall, means OK. All is well. It's not something like 404, which would mean file not found. So 200 is OK. But the server might also respond with this key value pair, this HTTP header, Set-Cookie:. So that's the key. The value of which is session=1234abcd. And that's the same value we used previously when we talked about cookies in this context. And the point here is that the name of this cookie is Session. And its value equals, in this case, 1234abcd. Now, if you visit the same website and you, and you, and you, we would all have different seemingly random values for those cookies. And so this number, this sequence of letters and numbers, would be different for each of us. That is to say we have different handstamps that we're presenting each time. Now, this is a session cookie. And it's a session cookie in the sense that it is supposed to expire when you close the browser, when you quit for the night, when you reboot or anything else. Now, with that said, that's a bit of an overstatement because browsers nowadays will frequently preserve your tabs for you. They might go to sleep. You might have to wake them back up. But increasingly, sessions are living longer than they once did. But the idea is that this is not meant to last for a year or forever. It has a much shorter lifetime by design. When your browser has received that cookie and you click on some other page, you visit some other product on amazon.com, your browser might say something like this, GET/ and then cookie:, that exact same value. So recall from our previous class, this is how the browser just reminds the server what its handstamp is or what its cookie value is. But again, the idea is that when the browser is closed, you reboot for the night, then you should not have the same session cookie tomorrow, at least, in this model. That's not true for all websites, but according to cookies as we are currently using them. Now, that's pretty good for your privacy because if the cookie is by design meant to be a session cookie and it expires pretty soon when you're done with that browser tab or done using the browser for the day, then that's pretty good because it means if you go back to the same website tomorrow, that cookie might not exist anymore, so you might as well look like or be a brand new user. So they can't correlate, perhaps, by default as much information about you. But these are the cookies that you read about being bad for you and bad for your privacy, tracking cookies, which are the exact same idea, key value pairs that are sent from server to browser to remember who you are, or at least, that you're the same person, even if we don't know that you're David Malan specifically just yet. But as per the name, tracking cookies are really designed to track you and me. Why? Well maybe analytical purposes, maybe debugging purposes, so that they know where users were in case something breaks, maybe advertising purposes, so that you get served different ads from me, so that they can maximize their revenue by clickserving up ads that you and I are each more individually likely to click on. So tracking cookies are the ones that get a bad rep and rightfully so. So let's consider an example of a cookie that's designed to track your behavior on a particular website. Here, for instance, is a set-cookie header that Google, specifically, might send to your browser. In fact, they use a cookie that by convention is called _ga for Google Analytics, which they use for analytical purposes. And its value looks a little something like this. And the point of this value is that it's generated on a per website basis if that website is using Google Analytics. And Google Analytics is a tool that allows website designers to track who is clicking on what, what browsers they're using, what operating systems they're using, and generally giving them a sense of the demographics of their user base. But unlike session cookies, which are meant to expire after a day, after the browser closes or the like, Google's analytical cookie here has a maximum age of this many seconds, which if you do out the math is by default two years, which is to say, if you visit some website that is using Google Analytics by embedding a bit of Google's JavaScript code in their website, whenever that Google code is pulled from Google's website, Google has an opportunity to plant this cookie on your computer. And you'll get a unique ID based on you visiting for the first time, based on the specific website that is embedding Google Analytics. And that cookie is going to live in your computer, according to this HTTP header, for as long as two years. Now, that's useful for Google. It's perhaps, useful for the website. It's perhaps, a little more invasive for me and you. Now, Google has many other cookies that they use too. But this is, perhaps, one that you should keep an eye out for. And indeed, in the coming weeks or months if you poke around some of your own browser settings, you might very well see values like this. But what else might servers use to keep track of us, especially if you and I are in the habit of deleting our cookies or clearing your history, which would be counterproductive for Google or websites that are trying to track you in this way, but a plus for you and for my privacy if you're behaving in this way? But it turns out there's other ways servers can track us, including through HTTP parameters, tracking parameters. So parameters are the key value pairs that often appear in URLs that are sent via GET requests typically. So we've seen one of these. If you recall when we searched for cats on Google before, you might recall that the URL was something like https://www.google.com/search?q=cats. Anything after a question mark in a URL is, indeed, an HTTP parameter. But it could be used not for innocuous helpful purposes, like searching for cats, but also, to track you. And in fact, if you see ampersands in URLs, that might mean that you have a second, or a third, or more parameter up there. And sometimes the purpose of these parameters is simply to track you as some person. So for instance, here is a representative URL. It's a long one. And this is taken from example.com having a path of as_engagement?. And then I'll highlight here click_id= and then this long seemingly random string. But there's a second HTTP parameter in this particular URL. &campaign_id=23. So the campaign ID, certainly with such a small number, is not meant to track you. That's meant to be sufficient input to the website to know what types of ads should be served to you. What campaign should be served up? But this click_id, which is sort of a euphemism for tracking cookie or tracking parameter in this case, is what's actually keeping track of you, specifically, because different users are going to find that whatever link they click on has a slightly different value for click_id. So recall that a tracking cookie is something that's sent via an HTTP header. And so it's harder for you and me to see it, unless we're more comfortable with our browsers and can poke around some underlying settings. But these tracking parameters are right there in front of you, at least, if you click on the URL in your browser and take a look at its entirety. Now, wonderfully, at least for us end users who are concerned about privacy, browsers and even third-party software are increasingly removing values like this for us. As soon as the browser manufacturer or as soon as the third-party software developer knows that, wait a minute, click ID has no good purpose other than tracking our users, they can simply automatically remove it for you. After all, when you visit a web page and you get the HTML that represents that web page, the browser could certainly poke around there before you even have a chance to click on anything. And it could scrub or sanitize these kinds of tracking parameters. Now, to be fair, if the browser manufacturer doesn't necessarily know what the tracking parameter is called or if maybe the website is constantly changing the name or trying to mix things up, this might not work so well. But it's at least an attempt to try to put downward pressure on this very commonplace technique of keeping track of you and me. Now, why is this parameter able to track us? Well, this, too, can end up in those server logs because this would be, for instance, the web page that I am requesting, /ad_engagement?click_id= dot, dot, dot, that could very well be logged by the server, stored in a database, even. And they could use that information to know exactly which pages I have clicked on, because I visited those links, and even what ads I have seen. And maybe that's a good thing commercially because now they know what types of ads I'm clicking on. Now they can serve even more of them to me. And that might be great for them, but probably not so great, if not, annoying or invasive for me and you. So something else to keep an eye out for and something else that might guide your decision making in the days and the years to come when it comes to picking your browser. You don't necessarily have to nowadays use the one that comes with your phone, comes with your laptop or desktop. You can, if more comfortable, install something else. And increasingly, you and I are having more and more options. Questions now on these tracking parameters or anything prior with respect to our privacy? AUDIENCE: Are the cookies the ones that track or are the ones that are being tracked? DAVID J. MALAN: The cookies are values that are being used to track you. So recall that-- a metaphor for the cookies is like that virtual handstamp. And so if all of these web servers are putting ink on your hand and on my hand and because of HTTP, you and I, our browsers are in the habit of presenting these cookies, these handstamps to every website we visit, that value is being used to track us. So cookies in and of themselves are just a technology. It's a very simple idea storing a big random value on your computer and mine just to uniquely identify us. They are necessary to give us features like logging into websites, maintaining shopping carts. But very quickly, especially since the internet from the get go has been largely free to use-- or rather, a lot of the internet has been free to use once you have a connection, at least-- they've been used, or in some views, abused by the advertisers, the Facebooks, and the others of the world. So another way to think about tracking cookies is to consider them to be third-party cookies because, indeed, even in the Google example, that's how they're being used. If a website like example.com is embedding Google Analytics, and therefore, some kind of HTML tag that mentions google.com, well then, example.com is the first-party in that story, so to speak. And google.com is the third party in that story. What that means is that your browser might get cookies from both example.com and google.com. But the most important ones, presumably, are the first-party ones from example.com because that is the website you chose to go to and whose functionality you want to use. The third-party functionality, like tracking your clicks and your internet behavior on that site via Google, that's third party. And so very commonly do browsers nowadays certainly offer options via which you can disable third-party cookies. And that tends to be good for privacy sake because it means you're blocking third parties like Google from keeping track of you via cookies. But, but, but that doesn't necessarily mean the website isn't still using tracking parameters in some way. And you would only know that by actually looking more closely at the URLs you're clicking on or that are embedded in the web page itself. And that's where now browsers and third-party software are additionally helping by helping us remove not only those cookies, but even those parameters. But let's consider a more concrete scenario of what third-party cookies are and why they allow companies not only like Google to track your behavior on one website, but even companies like Google or other advertisers to track your behavior on multiple websites. And in this sense, third parties have increasingly been more powerful, more omniscient, for instance, than the first-party websites that you and I are actually visiting. Why? Well, if there's a lot of popular third parties out there, Google being one of them for advertisements and for analytics, well, if lots of different websites are using them-- maybe Harvard's using them. Yale's using them. Stanford's using them-- then that third party very quickly becomes more powerful than even any of those individual parties alone. Why? Because that third party, if it is being embedded at Harvard, Yale, and Stanford, that third party Google, for instance, kind of has eyes into all three websites. And if it sends the same cookie to you on all three websites, Google might actually know that you're poking around Harvard's, and Yale's and Stanford's website when Harvard might have no idea you're checking out Yale and Stanford. And Stanford might have no idea you're checking out Yale and Harvard. So what does this mean concretely? Well, consider some HTML here, such as we've seen before. And I've highlighted a couple of salient characteristics in this particular example. Notice that I've given in this web page not only a body, which contains the body, the bulk of the web page. I've also included a head for the web page, inside of which is another tag called Title. And I'm doing this just to, one, demonstrate there are more tags than we have seen in this language thus far. And specifically, this I claim is meant to represent harvard.edu's own website, the title of which would be Harvard, like in the tab along the top of the screen. And inside of the body of this page for simplicity, let's assume that for now, there's just one big advertisement. There's no content for the sake of discussion. There's just one advertisement. Well, where is that advertisement coming from? It's coming from, in this case, example.com, or our friends at Google, specifically, a file called ad.gif. And this particular URL is being used as the value of the source attribute of an image tag. So what do I mean by this? Well, if you visit harvard.edu in the story, what you are seeing is a big advertisement, a big GIF, a graphic that is coming from example.com. Now, what is the implication of that? Well, suppose that Yale is doing the same thing. So here now, for the sake of discussion, is the exact same HTML, except it lives at yale.edu. So the title of the page has now changed to Yale. And moreover, just to make things really interesting, let's add Stanford to the mix. Same exact page. So the point of this story is that Harvard, and Yale, and Stanford are all using the same third party, example.com in this case or maybe someone like Google in the real world. And they're requesting moreover the same GIF. And so the same file is being accessed. But that even alone isn't a strict requirement. The same website is being accessed by all three of these first parties. So what does that mean? Suppose that you open up your browser and you first visit harvard.edu, your browser is going to download the HTML for Harvard's website. It's going to see that, oh, there's an image tag in there. And that image tag wants to show this ad.gif from example.com. So your browser is automatically, by nature of how browsers work, going to send a second HTTP request, this time requesting ad.gif from the host, example.com. And just to tie today's stories together, it's going to include, probably, a referrer, HTTP header that specifies where I'm coming from. And that's useful for our purposes because it puts these requests into context. Now that server, example.com, or Google, in the case of the real world, is going to probably respond with 200 OK like, OK, here is the advertisement. And it's going to include not only the image, but also an HTTP header of its own. And this is our old friend set-cookie, where in this case, for the sake of discussion, I'm going to propose that it's setting a cookie on my computer called ID because this is going to be my unique identifier for example.com. Its value is going to be the one I keep using for discussion's sake, 1234abcd. But that would be some big random value for each of us. And my gosh. This thing is going to last a year. That's the number of seconds in 365 days. So this cookie is being planted on my computer by example.com because I visited harvard.edu. So Harvard is the first party. Example.com is the third party in this case. But here now is the concern. When I visit yale.edu with that same browser, my hand has been stamped by example.com already. And so what happens is that my browser now presents that handstamp to example.com, sending the same ID and the same value, that is, the same handstamp. The host is as before example.com. But this time, the referrer happens to be Yale. So in other words, after I visited Harvard and my hand has been stamped with this tracking cookie, this third-party cookie from example.com, my browser, when I visit yale.edu, is going to present that same handstamp again, this time, to example.com with this referrer. The next time I use my browser to visit stanford.edu, the same message is going to be sent from my browser to example.com to request that same ad, this time now from stanford.edu's website. Now, what's the implication? Via these three HTTP requests, example.com knows that I'm visiting Stanford, and before that, Yale and before that, Harvard. And none of Harvard, or Yale, or Stanford necessarily know that I'm visiting any of those other websites. The third party is the more powerful. It's the more all seeing, simply because example.com, or in the real world, Google, is just so darn popular, that it's embedded in so many darn websites, Google and others almost everything, dare say, about what you and I are doing on the web because these ads are all over the place in this way. So we've seen a very simple example. But it's simple because cookies and HTTP really are relatively. It's once you realize how they work, that you can use them not only to solve compelling problems for all of us, sessions, and shopping carts, and the like, but also can be used to monetize the internet and has been used historically to monetize the internet, or even worse, perhaps, for us, to track our individual clicks and behavior. So let me pause here and see if there's any questions now on third-party cookies and why, therefore, it's perhaps so compelling for you or me to opt in to disabling them, or better yet, to use browsers that are starting to block them for us. AUDIENCE: What browsers are more secure among others considering tracking parameters? DAVID J. MALAN: Sure. A quick tweak. I wouldn't say that some browsers are more secure than others in this context. I would say that want browsers that are more privacy conscious or privacy preserving because that's what we're talking about today. Hopefully, all of them are just as secure when it comes to HTTPS and the encryption that's just keeping our data protected between points A and B. So generally, Safari has been pretty good when it comes to privacy. And they are the ones that very recently that you're using now announced that they're going to start giving people the feature of removing tracking parameters from URLs. In fact, the sample URL I gave was actually from Apple's recent announcement about exactly that. DuckDuckGo is probably the most popular third-party browser that is very privacy conscious and tries to disable a lot of these tracking behaviors. Another one is Brave. Perhaps, the worst offender is probably Chrome, even though I, myself, am guilty of using it myself because it's so integrated into Google's ecosystem. But Google, of course, has made their business on monetizing your behavior and mine. So that is, perhaps, one to put toward the bottom of the list if you're concerned about this. So that's kind of how I would rank things. And there's yet others. But I think those are some of the most popular. And then, of course, in the Microsoft ecosystem, there is Edge and Firefox too. I should have put them higher on the list. They are more privacy conscious, I do believe, than Google. So with all of these mechanisms for tracking in mind, what can we do to protect all the more of our privacy? Well, you might already know of this feature, private browsing. So you don't necessarily have to delete all of your browser history and delete all of your cookies. You can instead, on occasion, open up a special type of window, which most of today's browsers support that puts you into private mode or incognito mode. And you can think of this as giving you just a different chunk of memory in the computer that doesn't know any of your past browser history, that doesn't have any of your past cookies, that doesn't remember any of your past usernames and passwords. You're sort of starting fresh, so that everything you do in that window is brand new. The catch, though, is that everything you do in that window still works exactly as the web works as we have been describing. So you're still might have tracking parameters. You still might have tracking cookies. You still might have server logs. But when you close that private window or you close that incognito mode, at least, the information is discarded from your computer, so that if tomorrow, you do the exact same thing and open up an incognito window again, then it's as though you're starting fresh with that server, except for the reality, as per our past discussion, that fingerprinting is still a possibility. Your IP address can still be factored in as can be other information that your browser might still be leaking. But what you're not doing is contaminating, so to speak, your general browsing history with specifically what you're using that window for. What you should realize, too, that private browsing or incognito mode is entirely client side. So particularly, those logs that we have mentioned are still being stored by the server. They might be storing, perhaps, a different tracking cookie or parameter for you because it doesn't necessarily recognize you when you're in private or incognito mode. But it doesn't mean that your tracks are completely absent from the internet. Rather, it's really just scrubbing them from your local computer and decreasing the probability, but not eliminating the probability that a server still knows that it's you. So I would use with care. But with that said, if you take a course in web development or you already design your own websites, using private browsing or incognito mode can also be useful for development purposes because it's a way of opening a brand new window that has no recollection of maybe past bugs that you had or past web pages that you clicked on. And it's very commonly used as part of development tools to actually facilitate and mimic the idea of starting fresh with some site. Super cookies, though, these sound delicious, but these two are kind of the worst of cookies that we've discussed already. We saw session cookies for maintaining state. We saw tracking cookies for tracking you. Super cookies are not so super, really. These are cookies that are typically injected by a third party, like your company, your university, or your internet service provider into your HTTP request, which is to say, if you, from your browser, visit some website, that traffic, of course, goes from your laptop or phone through some internet service provider, whether it's on campus, or home, or wirelessly in the real world. And if whoever is providing you with that internet service can see the contents of that virtual envelope, there's technically nothing stopping them from opening up the envelope, so to speak, and adding one or more HTTP headers of their own. And so mobile phone carriers, for instance, in the past have been known to do this, whereby, if you are just requesting a website, like example.com from your phone, they might-- halfway between you and that server, they might inject a cookie of their own. For the sake of discussion, I'm going to use the same name and value as before. id=1234abcd. But what's noteworthy here is that that value is not coming from your phone. It is not coming from your browser. You can clear all of your cookies. You can clear all of your history. You can use incognito or private mode on your phone. You're not going to see any trace of that client side because the darn thing is being injected into your traffic between you, point A, and the server, point B. So this is sort of a canonical example of a machine in the middle attack. But your internet service provider in this telling of the story is doing it because they want to track you. Or they want-- because of advertising relationships they might have with some websites, they want to make sure that you can be tracked by that website, even if you have opted out or have been clearing proactively your very own cookies. So suffice it to say, these have been particularly controversial. And thankfully, you and I do have a pretty good defense here. Just never use HTTP without encryption. If URLs are always https:// and then something, theoretically, this attack or this "feature" of your mobile phone carrier should not be possible. Why? Because if the contents of the envelope are encrypted, not only can't they see what's actually inside, they can't add anything to the mix because they don't have the key that's being used to encrypt that information. So simply using always HTTPS is one solution to this problem. And also, at least, in the US, some of the mobile phone carriers got a lot of backlash for this. But so, you can occasionally log into your cell phone provider's website, go through a bunch of menus, find an option to opt out of this feature. But I will say from experience, that they typically bury these options too. And so it's not necessarily even the iciest thing to find. But again, this is just a natural result of the underlying technology that we're being used, or if you prefer, abused, for alternative purposes. All right. Let me pause here and see if there's any questions now on these super cookies, which indeed, are not so super or anything prior. AUDIENCE: Given that cookies store passwords and emails, can the adversary impersonate another person by copying that cookie and pasting it into his own computer and visiting that website? DAVID J. MALAN: A good question. So cookies can be used to store user names, email addresses, even passwords, though, I would generally not recommend doing this. But they theoretically should be secure, even if you're storing those values in cookies because they're going back and forth between the browser and the server using encryption if HTTPS is, indeed, in use. A danger, though, is that if someone has physical access to your computer, it's very easy to poke around your own browser's cookies, at which point, they're going to see your password, which is probably not a good thing. So on an alternative would be, for instance, for a browser to encrypt the cookie or minimally digitally sign it, so that it can be identified as belonging to that same server. But even better, I dare say, would be for servers to only plant big random values as cookies on your computer, like this virtual handstamp, and then store recollection of your username, email, and/or password on the server. So stamp my hand to remember who I am and that I'm logged in, but don't bother expecting my browser to send my username, my email address, my password again and again. It should suffice to send that just once. Other questions here? AUDIENCE: I've heard that it's possible-- for example, if I'm writing a text to someone, it's possible to intercept, to alter my text and send it on my behalf. So it's going to be a different message, so it's possible to ask, maybe, for sensitive information. So I was wondering, don't those messengers use something like cookies? How can this be possible? DAVID J. MALAN: A good question. So SMS, or traditional texting, is generally insecure. It is very easy for someone to forge your phone number. And in fact, if you've gotten a lot of spam via text, that might be exactly what is happening. Or worse, it's also possible, recall, to steal your SIM card essentially or port it to another carrier, so that someone can intercept all of your actual texts. So in general, nowadays, you should be reducing, if not, eliminating your usage of SMS, at least, for anything important or anything you want to keep private. When it comes to other messaging tools, like iMessage, like WhatsApp, Signal, Telegram, there's a lot of products nowadays, third-party or otherwise, that use end-to-end encryption, which recall, we discussed a couple of classes ago. And in that case, even though the data is going through a company like Facebook, theoretically, assuming they're behaving honorably and have implemented end-to-end encryption properly, then even they cannot see the message going between their servers. And that is independent of cookies. Cookies have no part of that solution. That solution is entirely thanks to cryptography and encryption with digital signatures. All right. So let's consider one other threat to your privacy that you might not necessarily have thought about that isn't relate just to the web, but really, your use of the internet more generally, namely, DNS, the Domain Name System. Thankfully, even though computers on the internet all have IP addresses, these unique numeric addresses that we've discussed, you and I don't have to remember what server's IP addresses are because servers typically have domain names, something like harvard.edu, yale.edu, stanford.edu, google.com, amazon.com, and others. But how then-- when you type in any of those domain names into your browser or into any piece of software on the internet, how does your browser or your computer know what IP address to contact? Well, it turns out that there's a domain name system in the world. And this is a system deployed throughout the world on the internet whose purpose in life is to translate domain names to IP addresses, so that on the outside of those envelopes can, indeed, go the IP addresses of source and destination. But you and I, as humans, don't need to know or remember exactly what those IP addresses are. You can think about this back in the day of when we were in the habit of typing in phone numbers to actual analog landline telephones. It was actually pretty hard to remember lots of people's numbers. And you might even have had an address book that you looked up people's numbers in. Or there were certain mnemonics. For instance, in the United States, there was a number, 1-800-COLLECT, C-O-L-L-E-C-T, which was just much easier to remember than the actual numbers for making a collect call. The equivalent on the internet is DNS, which just automates this process for us, so that every website, every service can have its own unique name, but it's translated automatically for us via DNS servers throughout the world to the corresponding IP address. But why is this problematic? Well, it turns out that DNS servers are typically in a few different places. One, you probably have one in your home, or your company, or your university. And it probably is built into, if in your home, the router, the device that you're using just to connect to the internet. But your internet service provider also tends to have a DNS server. And that DNS server probably knows about way more IP addresses than your own home does because why would your own home network know about all of the IP addresses in the world? But with that said, why would your internet service provider know about all of the possible IP addresses and domain names in the world? Well, suffice it to say for our purposes, there's a hierarchical system. So even if your home router doesn't know, even if your internet service provider doesn't know, there's some other server on the internet that can eventually give you the answer to a question like, what is harvard.edu's IP address? What is yale.edu's IP address and so forth? And for efficiency, once that answer has been figured out somewhere, then your internet service provider might remember, or cache, the answer. And even your home router, and heck, even your device or your browser might remember the same answer for efficiency, so we don't have to keep asking the same question. And it turns out by convention, DNS uses port 53, if you recall our discussion, of also using unique numbers to identify things like HTTP, or 80, HTTPS, or 443, or 22 for SSH. DNS tends to use 53. But the catch is that the traffic used for DNS is typically unencrypted, which means that when your phone, or your laptop, or your desktop is asking your home device, or maybe your internet service provider, or someone else, what is the IP address for harvard.edu, or yale.edu, or the like, you're actually announcing to the world what website you are about to visit. Why? Because you're waiting for a response from the DNS server to actually tell you the corresponding IP address. So this isn't great. And moreover, your internet service provider, therefore, knows all of this information about you because every time you ask for a new website that you've never been to before, your home network probably doesn't know the IP address, so you have to ask your internet service provider. And again, they might ask someone else. But the internet service provider is going to know now that you asked. So your internet service provider, be it for your home network or for your cellular phone, pretty much knows every website you've ever been to, assuming they're logging this information, which they probably are, unless there are regulatory or legal requirements that say they can't or they can't for very long. Now, why is this the case? Well, the domain name system essentially requires that we ask these very questions. And if the internet service providers remember these answers, well, they can keep track of everywhere we've been, at least, at a high level. DNS only gives them back a translation from the domain name to the IP address. What it does not include is the specific page that you're looking at, the specific URL, the folder, the file that you're looking at. So your internet service provider might know you're visiting somewhere on harvard.edu because you asked, of course, for its IP address. But they don't know what department you were looking for or what course you were looking at or the like. But there's still a decent amount of invasion, therefore, of your privacy if you'd rather that ISP or someone else just not know that information. So increasingly, there are alternatives to the standard DNS functionality, one of which is called DNS over HTTPS, or DoH for short. This means exactly that. Instead of just sending out DNS requests unencrypted on port 53 to the local DNS server, now they're sent, potentially if you enable this, over HTTPS. And what this means is that they will be sent using the HTTP protocol, which we've talked about endlessly in these virtual envelopes, but securely using TLS, which is the encryption protocol that ensures that no one else can see what's going on inside of that envelope, including your internet service provider. Now, someone is going to still know what domain name you're looking up because after all, to whom are you sending this request? Maybe you're sending it to Google. Maybe you're sending it to some third party. But you are sending it to someone. But at least, goes the thinking, it's not your internet service provider, who really doesn't need to know this information. So that's one way of thinking about it. And there's alternatives to this. There's actually something called DNS over TLS, DoT, which is very similar in spirit, but it doesn't even bother using HTTP. But it is still using encryption. So this is something that's increasingly common. It's not necessarily the default on a lot of systems. But it's yet another feature of today's technology that you can increasingly look for, seek out, enable proactively if this, too, is a concern that you don't necessarily want a third party, like your ISP to know what it is you're accessing. And it might not even be your own ISP. If you're on the road, in a coffee shop that gives Wi-Fi, or an airport that gives Wi-Fi, at that point, your internet service provider is effectively that coffee shop or that airport. And do you really want them knowing everywhere you're going? You might be, depending on your comfort level, prefer-- you might be preferring that, at least, all of your DNS requests go to some other central party that you do trust for whatever reason, so you're not just informing every different Wi-Fi hotspot that you might be using around the world. Let me pause here and see if there's any questions now about DNS and this concern with respect to your privacy or these solutions there to. AUDIENCE: Can DND [INAUDIBLE] used to deceive users and steal information, which is sensitive? DAVID J. MALAN: Absolutely. So DNS, itself, can also be used for evil purposes. If you control the DNS server, you don't have to give an honest answer. If someone asks you for the IP address of harvard.edu, you could give them the IP address of some completely malicious server that you control. However, if the user, like Ryan, in this case, is using HTTPS, the whole point of HTTPS is to encrypt the data between browser and server. And presumably, the browser is going to try to request the TLS certificate of harvard.edu in this case. But if the IP address returns the wrong certificate that wasn't signed by the right website, then the connection might fail. And you'll be given a warning that you can typically ignore in your browser. But this should be preventable because you should at least be warned that that is not working correctly. And ISPs actually do this quite often. If you make a typographical error sometimes on home networks, or coffee shops, or airports, you might actually still see a website of search results, or worse, advertisements. And that's because even if you made a typo in the domain name, the coffee shop's or the airport's DNS server is still going to return to you an IP address of their server, so they can at least push some content at you. So let's consider some of the mechanisms via which we can push back on some of these more invasive privacy practices. And one is something we've talked about before, namely, a virtual private network, or VPN, which is a increasingly familiar technology. But it's worth knowing exactly what problems it is solving for you and exactly which problems it is not, particularly, if you're using such a service to protect your own privacy. Well, what is a VPN? It allows us, recall, to connect from point A to another point B using a completely encrypted tunnel. So it doesn't matter if there are machines in the middle, as indeed, there will be on the internet. All of the traffic between A and B on a VPN is encrypted or scrambled. So what does this do? This allows you to access sometimes a corporate network or a university network that might have servers or services that are only accessible if you are on physically or if you are on virtually that particular network. This ensures that even if you're at home, or in a cafe, or an airport, at least, you have an encrypted, more secure connection to the campus or the corporate network, at which point, the campus or company might be more comfortable with you accessing those services. Now, this does not prevent you still from being hacked because if you're running malware on your own computer accidentally, it doesn't matter if you have an encrypted connection to the company or campus. You might very well have an infected connection now to the company or campus if you, yourselves, are infected. VPNs can also be used to create the illusion that you're actually in one country and not another. Why? Well, if point A is where you are and point B is somewhere abroad, well, to the rest of the world, if you start using this VPN, this virtual private network, you will appear to have an IP address that is in that foreign country because all of your internet traffic for chatting, video conferencing, the web will be sent through that VPN by design. That's what a VPN is for. And it will come out the other end in that foreign country and then continue on its way to the chat service, the email service, the web service, or the like. So each of those services will think that you live or are physically in that foreign country, even if you are not actually. So what's the implication of this? A virtual private network only guarantees that the connection between you and that point B is encrypted. It doesn't necessarily mean that once you're out of that VPN, it's going to stay encrypted, especially if you're using still HTTP and not HTTPS. But it does, at least, encrypt everything between points A and B. It also does change what your IP address appears to be, so that you will, indeed, appear to have an IP address that's from that foreign country and not your domestic IP address, which might have some value in covering your tracks or decreasing the probability that you'll be identified. But again, we've seen so many other mechanisms today, whereby, your browser can be fingerprinted in the context of the web, that someone might still be able to realize that, OK, your IP is different today, but this still looks like you, even if they don't necessarily know that you are David Malan or you, yourself. But it, at least, does solve at least one problem, which is encrypting end to end all of your traffic. Well, there's another piece of software that's been popular for some time called Tor, The Onion Router. So this is a piece of software that you can install on your own Mac, or PC, or other device. And this uses encryption to solve the problem a different way using additional encryption to try to give you a higher probability of privacy. And here's a picture that Tor, themselves, puts on their website. And it has depicting here you on a very old school PC connecting to a whole bunch of nodes inside of this Tor network connected to ultimately maybe the websites that you're visiting. And what happens here is that when your computer is running the Tor software, the Tor software first figures out, OK, who else in the world is using the Tor software? Because it's going to use those other computers to route your traffic, up, down, left, and right and kind of like the movies or TV, where you see a map of the world and the traffic is bouncing back and forth and back and forth. That's kind of the spirit of Tor. And what happens is if your computer here wants to send a request to a website that's maybe over here and it decides, for instance, to route it through one, two, three computers, what the Tor software will do is encrypt the request at least three different times. Whatever web request you are sending, whatever email you are sending, whatever chat message you're sending, whatever service you are using between point A on the left and point B on the right is going to be encrypted with this node's public key, with this node's public key, with this node's public key. And so here's the onion in Tor, The Onion Router. You are encrypting layer, upon layer, upon layer of data, so that mathematically, recall per our discussion of public key cryptography, only this node can peel off one layer, only this node can peel off one layer, only this node can peel off one layer using their own respective private keys, which undoes the effect of your having encrypted your traffic. So what you're really doing here by choosing, perhaps, a different path, every request, a different path every day is you are with Tor effectively covering your tracks in some sense. And by design, the Tor software doesn't remember much information at all, so it doesn't have the sorts of logs that I propose can be worrisome, at least, in the context of web servers. By design, Tor is meant to preserve your privacy with higher probability. And so by design, it just doesn't keep nearly as much information around. Now, this isn't to say that if you're doing this for malicious purposes, trying to evade the authorities, this isn't to say that this computer, this computer, this computer couldn't be subpoenaed, so to speak, by some government entity and they could reconstruct the path that your data took. But the point is that it's generally quite laborious. By this time, all of that data has disappeared from those interior nodes. And so they don't have much information to share. And so increasingly, it does provide you with some higher probability of privacy by layering your requests with encryption, encryption, encryption and sort of trusting that these interior nodes are going to relay it to the final endpoint, so something to consider if of interest. But realize, too, that because of how the internet works with IP addresses, because of how the internet works with port numbers, it's still possible on a network to know who is using Tor, for instance. So if you happen to be the only person at home, the only person on a company or on a university network who's using Tor at the moment, it's being used for malicious purposes, odds are, you could be targeted as the source of that attack. And so realize, in particular, that this just raises the bar to detection. It raises the bar to your privacy being invaded. But it does not, as do none of the technologies we've discussed, give you an absolute protection of these same properties. So there's one final mechanism when it comes to preserving one's privacy that's thankfully increasingly available to us on devices, on desktops and laptops, and especially, on phones. And that's this notion of permissions, which isn't anything new. But as iOS, and Android, and other operating systems have evolved, increasingly, you and I are being asked by our operating systems, do you want to allow this? Not only do you want to allow this program to run, but do you want to allow this program to access your camera, for instance? Do you want this program to access your microphone, for instance? Do you want this application to access your contacts, for instance? So on the one hand, we're being given much more fine-grained control, which is a good thing, presumably. At the same, time, it's also just pushing the decision onto you and me. And very often, with these applications, as you've probably found, well, if you don't enable the camera and give access to the app, it just might not work because they have some code in their application that says if camera's not on, then do not do anything useful. So there's this tension between usability and privacy in this case. But thankfully, there's finer-grained controls too. On iOS, for instance, you might be prompted, do you want to give this app access to this feature always, or only while using the application, or never? And that's certainly a good thing for something like the camera or the microphone, where it would be nice to trust that when you close the app and put your phone in your pocket, that it's not still listening to or trying to watch you from this built-in hardware. Now, there is some feature that might need to run all of the time, which includes location-based services, which is to say that our phones, especially nowadays, can pretty effectively track our location using GPS, or Wi-Fi, or some other technology. Now, that's of course, useful, if not, necessary for using mapping applications, like Maps, or Google Maps, or the like that help us get physically from point A to point B. But very commonly, these applications, at least, by default, ask for access to your geographic location always, which means just by walking down the street, even if you're not following a map on your phone, means that the app can still be tracking where you're going. And certainly, among the Googles and the Apples of the world nowadays or other manufacturers, they certainly know pretty much everywhere you and I are going if we leave these location-based services on by default. So this is an example of something of which you should be mindful if only because here is yet another example of information that logically, when you think about it, OK, obviously, that makes sense. They must be keeping track of my location, otherwise, how could they provide me with mapping services? But pause and think now, perhaps, exactly what the implications are for you, for your privacy, and just walking around 24/7 with these radios now in our pockets. So even though there are quite a few threats to our privacy, online especially, at least, there are these mechanisms that you and I can enable to at least preserve some of the same. Well, what have we done over the past few weeks? We began with a look at how we can secure our accounts, then our data, then our systems, then our software, and today, of course, focusing on preserving our privacy. And by way of the various technologies we've looked at, the stories we've told, the principles that we've introduced, we hope that in the days, the weeks, and the years to come, you can use all of these first principles, and these ideas, and these building blocks to extrapolate to how new technologies work, to how new threats might affect you, and to what questions you should be asking of either the software you use or the software you develop to ensure that not only your communications are secure, but also, that it has these privacy-preserving properties that you, and your users, and your customers might want. This then was CS50's Introduction to Cyber Security. And this was CS50.