Lecture 18: Private Browsing

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

PROFESSOR: All right, let's get started. So welcome to another exciting lecture about security and why the world is so terrible. So today we're going to talk about private browsing modes, something that a lot of you probably have a lot of personal experience with. At a high level, what is the goal of privacy? When security researchers talk about privacy, what are they talking about?

Well at a high level, they're talking about the following goal. So any particular user should be indistinguishable from a bunch of other users. In particular, the activity of a given user should be non-incriminating when viewed in light of activity from a bunch of other different users. And so, as I mentioned, today we're going to talk about privacy in the specific context of private web browsing.

And so there's actually no formal definition for what private web browsing means. There's a couple different reasons for that. So one reason is that web applications are very, very complicated. And they're adding new features all the time like audio and video capabilities and things like this. As a result, there's this moving target in terms of what browsers can do. And as a result, what information they might be able to leak about a particular user.

And so what ends up happening is that in practice, like with many things involving browsers, there's this living standard. So different browser vendors will implement different features, particularly with respect to private browsing. Other vendors will look and see what vendor X is doing. They will update their own browser. So it's like a moving target.

And as users grow to rely on private browsing more and more, they end up a lot of times actually finding bugs in private browsing mode, as I'll discuss a couple minutes later in the lecture. And so private browsing at a high level you can think of as an aspirational goal. But we as society are continually refining what it means to do private browsing and getting better in some aspects-- worse in some aspects-- as we'll see a little bit later.

So what exactly do we mean by private browsing? It's tough. But the paper tries to formalize it in two specific ways. So first of all, the paper talks about a local attacker on private web browsing. This is someone who is going to possess your machine after you've finished a private browsing session. And it wants to figure out what sites you looked at in private browsing mode.

And the paper also talks about web attackers. The web attacker is someone who controls the websites that you visit. And this web attacker might want to try to figure out that you are some particular person John or Jane as opposed to some amorphous user that the website can't tell who they are. And so we'll look at each one of these attacks in detail. But for now, suffice it to say that if the attacker can launch both of these attacks-- both a local and a web attack-- that actually really strengthens their ability to try to dearm us.

So, for example, a local attacker who, for example, maybe knows your IP address can actually talk to the website and say, hey, have you seen this particular IP address in your logs. If so, aha! You're looking at the user whose machine I control right now. So it's actually pretty useful from a security perspective to consider these local and web attacks. So they are separate things and then to see how they can possibly compose.

So let's look at this first type of attacker, which is the local attacker. So as I mentioned, we assume that this attacker is going to control the user's machine post-session. And so by post-session, I mean that the private browsing activity has already finished-- the user has perhaps gone off and done something else.

It's not at the computer. And then the attacker takes control of that issue and wants to figure out what's going on. And so the security goal is that well we don't the attacker be able to figure out any of the websites that the user visited during this private browsing activity. Now, the reason why the post is actually important there is because if we assume that the attacker can control the machine before the users private browsing, then basically it's game over, right, because the attacker can install a keystroke logger-- the attacker can subvert the binary that [INAUDIBLE] the browser. The attacker can subert the OS.

So we don't really care about this pre-session attacker. And also note that we're not trying to provide privacy for the user after the attacker has controlled the machine. And that's for the same reason. Once the attacker gets to the machine, he or she can do the same thing that is mentioned-- key logger.

So, basically, once the user leaves the machine, we don't assume any forward notions of privacy. Does that make sense? It's pretty straightforward. And so you can imagine that another goal that you might want to try to satisfy here is you might want to try to hide from the attacker that the user was employing private browsing mode at all.

Now the paper actually said that's very difficult. This property is often called plausible deniability. So your boss comes up to you after you use private browsing, and says were you looking at mylittlepony.com? No, no, I certainly wasn't. And I certainly wasn't using private browsing mode to hide the fact that I was looking at mylittlepony.com. So as I said, the paper said it's difficult to provide this property of plausible deniability. I'll give you some concrete reasons why this might be the case a little bit later on in the lecture. But that basically is an overview of the local attacker.

So one question we might want to think about is what kinds of persistent client-side state can be leaked by a private browsing session? And by persistent, I just mean stuff that will end up getting stored on the local hard disk, the local SSD or whatever. So what kinds of state might be leaked if we weren't careful when someone is doing this type of private browsing?

So one thing you might be worried about is JavaScript accessible states. So examplees of this includes things like cookies and DOM storage. Another thing you might be worried about-- and this is what most people think about when they think about what they want to say in private browsing-- is maybe the browser cache. So you don't want someone to look in the inner cache and figure out here are some images or HTML files from websites you prefer people didn't know that you visited.

Another important thing is your history of visited sites. So many of your relationships have been broken when the other goes to the browser-- start typing something into to the address bar and all of a sudden it auto-completes to something very embarrassing. So this is one thing definitely you don't want to leak outside the private browsing session.

You can also think about configuration states with the browsing. And so here you could think about things like client certificates. You could also think about stuff like bookmarks. Maybe if you logged into a particular site and the browser offers to store your passwords in another type of configuration state that you might not want leaking from private browsing mode.

Downloaded files-- as we'll discuss, this one's a little bit interesting because downloading a file actually requires explicit user action to download that file. Maybe we do actually want this stuff to leak outside of private browsing mode. Maybe if you download something in private browsing mode, it should actually be accessible when you open the browser or use the machine after that session. So we'll talk about this a little bit in a second.

And then, finally, during private browsing mode, you might install new plug-ins or browser sessions. That's another type of state that you might imagine you don't want to leak outside of private browsing mode. So, basically, current browsing modes typically try to prevent one, two, and three from leaking outside of private browser sessions. Right? So there shouldn't be any cookies or DOM stores to get out of there.

Anything you put in a cache during a private browsing session should be deleted. And you shouldn't have any history of the URLs that you're using. Typically, four, five, and six private browsing modes allow to leak outside of a session. And there's some good and some bad reasons why this might be the case.

And as we'll discuss later, we'll see if you allow anything to leak from the private browsing session, that actually radically increases the threat surface of private leaks. So it becomes much more difficult to reason about what the security properties are for private browsing mode. Does that all make sense? Anyone have any questions? It's pretty straightforward.

So the next thing we're going to talk about very briefly is network activity during private browsing mode. And what's interesting about this is that even if we cover all this stuff-- we don't allow private browsing to leak anything from there-- the mere fact that you're issuing network packet connections leave evidence of what you were doing.

So imagine when you want to go to foo.com, the website, your machine actually has to issue a DNS resolution request for foo.com. So even if you don't leave any of this type of persistent state up there, there may be records in your local DNS cache that you, in fact, tried to resolve the hostname foo.com.

That's very interesting. So you can imagine that browsers could try to flush the DNS cache somehow after the private session was over. Now, in practice, that's actually tricky to do because on many systems, you require administrator privileges to do that. So it's not clear if you want the browser running as root because browsers, as we've seen, are somewhat untrustworthy individuals. And also too-- a lot of DNS flush commands-- they don't actually act per user.

They flush the entire cache, which is typically not what you would want if you're implementing private browsing mode. You'd want to use a type of surgical thing where I only want to get rid of foo.com and things that were visited during this private browsing sessions, but not delete other things. So in practice, that's kind of a tricky thing to handle.

And another tricky thing to handle, which the paper mentions-- are these things that I'll call RAM artifacts. So the basic idea here is that during private browsing mode, that private browser has to be keeping some stuff in memory. And so even if the private browsing mode doesn't issue any direct I/Os to disk-- user rights. The RAM that belongs to that private browsing tab can still be reflected into the page file, for example. It can still be reflected into the hibernation file, for example, the laptop.

And so if that state gets reflected into persistent storage, then what may end up happening is that after your private browsing session is over, the attacker can look in your page file, for example, and find, for example, JavaScript code that was reflected to disk or find HTML that was reflected to disk.

So we're going to have a little demonstration of how this might work. So if you see up here on the screen, I basically loaded up private browsing tabs. And so what I'm going to do is I'm going to go to some website. So this is for the PDOS group here at CSAIL.

I've loaded up that page. And then what I'm going to do is use this fun command called gcore. So, basically, I'm going to take a memory snapshot of this running page. And so I will do the following magic. So basically there's going to be some work that my terminal is doing to generate that memory snapshot.

So this takes a little bit of time sometimes. Now, what's happening here. So now we've basically generated the core file for that private browsing image. So what we're going to do now is we're going to look inside of that image and see if we can find any mentions of PDOS.

And so what's interesting is we see a ton of instances of the string PDOS in that memory image for the private browsing mode. And so what is interesting is we actually see various prefixes for things. If we look further up, we can see things like there's full URLs here and things like this. You also find HTML code in there.

So the point here is that if we found all this in the memory of that page, then if this-- if any of those pages got put to disk in the page file, then he attacker could basically just run strings. So they could do what I just did over the page file and try to find out what sites that you visited in private browsing mode. So does that make sense?

Basically, the problem here is that private browsing modes don't try to obfuscate RAM basically or encrypt it in any way. And that seems like a pretty fundamental thing because at a certain point, the processor has to execute on clear text data. And so this is actually a pretty big challenge.

So does anyone have any questions? Yeah?

AUDIENCE: So one thing is I don't expect my browser to do that. One thing is that these browsers-- the guarantee that they give you through private browsing-- the example they give is if you're shopping for something, your layman friend can't go on the computer and see the things. So can you talk a little bit about what guarantees they give and if they had to change anything as a consequence of this paper?

PROFESSOR: Yeah, it's very interesting. One thing you can look at is when you open up a private browsing tab, typically there will be a little blurb that says, hey, welcome to incognito mode. Here's where we'll help you against. We won't help you if someone is standing behind you with a rubber hose about to beat you. And so the browser vendors themselves area little bit cagey about what guarantees they provide.

And in fact, after the Snowden incident, a lot of the browsers actually changed that splash page because they wanted to actually make it clear that we're not actually protecting from strong ways with the NSA or something like that. So long story short, what guarantees are they providing you? In practice, they're providing that weak thing that you mention there.

It's like a lay person who wanted to see what you were doing afterwards couldn't figure out what you were doing. And we're assuming the lay person can't run strings on the page file or things like that. Now, the problem-- there's actually two problems though. One problem is that first of all, because browsers are so complicated, they often don't even protect against the layperson.

I can give you a personal example. So a lot of times when you see those ridiculous ads from "Huffington Post," like, oh, my gosh. It's like puppies trying to help small puppies go down stairs and things like that. Right? Because I'm weak, I will sometimes hook on those things. But because I don't know want people to know that, I'll sometimes do that in private browsing mode.

So what will happen sometimes is that sometimes I'll see those URLs will leak into my URL history like my regular, public mode browser, which is precisely what this stuff is designed not to do. So one problem is that sometimes these browsers don't provide protection against the layperson attackers.

The second thing is I think that there are actually a lot of people who would like for private browsing mode to provide something stronger, particularly with the whole Snowden thing. I think there is a lot of people increasingly who would like private browsing mode to protect, for example, against these RAM artifact attacks, even though they may not be able to technically articulate that goal.

And so actually one of the things I've done while I was here, I got to do some research in a stronger private browsing mode protection. So we can chat about that after all. One of the things we learn about all professors is that we will talk about our research endlessly. So if you want to talk about that for three hours just send me a calendar request. And we can do that.

So, anyway, this is basically a demonstration. Oh, you had a question?

AUDIENCE: Yeah, about the RAM. So I'm not familiar with how it works exactly. How come a browser can't at the end of a session, just ask the OS to flush those parts around that he was using?

PROFESSOR: So we're actually going to get to that topic in a couple of minutes. But you are correct. At a high level, what you can imagine is that maybe the OS when it, for example, killed a process, would actually go through all those numbered pages and write zeros to all those pages. Or you could also imagine that maybe the browser tried to pin all the pages in memory to prevent anything from getting flushed out at all.

So there are some solutions that can do that. So hold onto that question for one second. This is basically an example of how data from RAM can leak onto disk through paging activity. But note that data lifetime is a bigger problem than just in the context of private browsing.

You can imagine that any programs that deals with, let's say, cryptographic keys or user passwords will have this problem. Anytime you type in your password to a a program, the memory page which holds that password can always get reflected to disk.

So let me show you another example of this. So let's say that we looked at the following program, which is pretty simple. It's called memclear. So you see here at the bottom and main, we're just going to read in some secret text file here. And then we're just going to sleep forever. So what is that Read Secret do? Basically, it reasons from file.

It's going to print out the contents of that file. And then it's actually going to clear out the buffer that was used to store that secret information. So getting back to your issue. So one can imagine the browser, for example, would try to just memset to zero all the secrets that it encountered when it's just in private browser.

So if we look at the secret files, it's not very fun. It just says, my secrets of in a file. And then if we run this program, in the background-- so what did it do? So like I said, it just printed it out. It read that file in, printed out the secret value-- cleared the memory buffer that it used to print that stuff out. Now it's just sleeping in the background.

So once again, if we use this fun gcore command, we can take a memory dump of the memclear program that's running in memory right now. OK, and then if we do-- let's see which ones we're going to look at. So then if we look at-- this guy is the one we want. And then we do a grep for a secret.

So once again, we see that if look in the RAM image of that running program, we found instances of both the file name that was read in and also some prefixes of the string contents of that file, even though we wiped the buffer in the C program itself. So you might say why did this happen? This seems very, very strange.

And the reason is that if you think about the way that I/O works, it's like a layer type thing. So by the time that the contents of that file get to the program, it's already gone through, let's say, the kernel memory. It's already gone through maybe like the C Standard Library to do I/O because that library does buffering and stuff like that.

And so what ends up happening is that even if you memset the application visible buffer, there are still instances of secret data lying in many different places throughout the system. And this is looking at the user mode portion of this application. So there's probably still data sitting around in maybe like the kernel I/O buffers or things like that.

So getting back to your question, if you want to do what they call security allocation, you can't just rely on mechanisms at the application level because there may be other places where that data lives. So what are some examples of other places where this data might live? So, for example, it might live in a process memory.

So these are things like the heap and the stack. So when we did that memset inside of memclear.c, we were basically trying to address this. But what we found out is that that is necessary, but insufficient to actually clear all instances of that secret from memory. So where else my RAM artifacts live or secret data persists-- so all kinds of files-- backups-- SQL write databases.

If at any point, an application takes something in RAM and writes it to one of these things, then once again, the attacker may be able to recover that after the attacker controls the disk . As I mentioned, a kernel memory is another common place where RAM secrets may live because, once again, applications typically do layered I/O in which each piece of data goes through multiple parts of the stack.

Think of like network transmission, for example. First, the data has to come to some network buffer that's probably inside the kernel. Then once again, it probably goes through some buffers inside the C Standard Library. And then finally it will go to the user mode-- the part of the application that the developer wrote him or herself.

So that can actually be a big problem. You can also think too of freed memory pages as being a place where data can leak. So imagine that your application allocates a bunch of memory using whatever [INAUDIBLE] or whatnot. And then that process dies. And the kernel sends out another process but hasn't actually zeroed out all the physical RAM page.

So what could happen is that when that new process spins up, it could just do a walk through all this physical RAM pages and use a bunch of memory and just do the same thing-- do the strange thing-- see if there's anything interesting there. And then they might be able to get secrets that way.

So there's a lot of ways information is leaked from the kernel. You could also think about I/O buffers and things like a keyboard from things like the mouse. There's just a bunch of different factors that data can leak through the kernel.

How might an attacker try to get some of this information? Well, in some cases, it's just as simple as reading the files-- so just read the page file. Read the hibernation file and just see what's in there. Some file formats actually embed different versions within themselves. For example, the way that Microsoft Word used to work is that a single Word file would actually contain versions for old pieces of data.

So if you could get access to that Word file, you could just sit there through either format and so step through all the old versions. And so as we have been discussing in the last couple minutes, security allocation is also a problem. It cannot supported a full stack. So for example, an older Linux kernel-- when you would create a directory, end directory, you could leak up to four kilobytes of kernel memory.

Only Zeus knows what's inside that memory. And that's because Linux wasn't actually zeroing out kernel memory that had been allocated, deallocated, and then allocated to something else. So as I mentioned before too-- if the kernel doesn't zero out pages that are given to user mode processes, you can also have user mode secret leaks through those types of menu pages as well.

Another thing is that-- SSDs-- many of them implement logging. And so in other words, when you send a write to an SSD, oftentimes you are not directly overwriting data, you're actually writing to a log. And when a piece of data becomes invalid, it lays away your claim.

So what that means is that if you as the user get unlucky. And you've written a bunch of data that hasn't been reclaimed by the SSD, then maybe the attacker can look at that hardware and say, oh, OK, I understand the log format. And even though technically speaking, this data may be invalid, I can still recover because I understand how the Flash translation layer works or something like that.

And at a high level, you can also have this problem with stolen or discarded hardware as well. If you don't use encryption, then a lot of times, you can just take some disk that you found in a dumpster somewhere-- you understand what the physical layout is and recover data like that.

So anyway, there's a lot of problems with these RAM artifacts getting stuck in persistent storage somehow and then being available for an attacker later on. So how can we fix these data lifetime problems?

So we've already discussed one solution, which is to basically zero out memory when you're done with it. So whenever you deallocate something, you just go through. You write a bunch of zeros or some random thing and then essentially hide the old data from someone else who might come along later.

So does anyone see potential any potential problem with that? One problem you might imagine is that as with all things in security, people always complain about performance. And so when you say that you zero out memory, maybe this isn't a problem if your program is I/O bound. So you're waiting on some slow, mechanical part of the hard disk or whatnot.

But imagine if your program is CPU bound. And maybe it's very memory intensive too. So it's always allocating and deallocating data. So maybe zeroing out memory might be performance cost that you don't want to pay. Typically this isn't a problem in practice. But as we all know, people love performance. This is sometimes an objection that you'll have with this approach. Another thing you can imagine doing is that instead of zeroing out memory, you always encrypt data as it goes to stable storage.

So in a system like this, basically, before the application ever writes anything to disk, it's actually going to encrypt it before it actually hits that SSD or that hard disk. Similarly, when the data comes back in from stable storage, you're going to decrypt it dynamically before you put it into RAM. And so what's interesting about this approach is that if the key that you use to decrypt and encrypt data-- if you throw it away, then once you throw it away, you've effectively made that data on disk unrecoverable by the attacker, assuming that you believe in cryptography.

So this is very, very nice because it gives us this nice property that we don't have to remember per se all places where you've written this encrypted data. We can just say why drop the keys? And I'll just treat all that encrypted data as it's something that I can allocate again. So, for example, if you look at Open BSD, they have this option where you can do swap encryption.

So you can basically associate keys with various sections of the page file. So it does this very thing I mentioned. So every time you group the machine, it'll generate a bunch of new keys. And then when your machine goes down because you shut it down or you reboot it or whatever, it will basically forget all the keys that it used to encrypt that swap space.

And then it can basically say now all that swap is available to be used again. And so because those keys are forgotten, one can assume that the attacker can't look at the stuff that is in there.

AUDIENCE: What is the [INAUDIBLE]?

PROFESSOR: Ah, yeah, that's a good question. I'm actually not sure what sources of entropy it uses. Open BSD is pretty paranoid about security. So I imagine it does things like it looks at let's say the entropy pool gathered from user keyboard input, for example, and other things like that. Yeah, I'm not actually sure how it drives those keys.

But you're exactly right that if these sources of entropy that it uses are predictable, then that basically shrinks the entropy space of the key itself, which then makes the key more vulnerable.

AUDIENCE: So with the memory it's capturing [INAUDIBLE].

PROFESSOR: Yeah, so basically, what this model assumes if all we are doing is looking at the swap encryption, It assumes that the RAM pages for the keys, for example, are never swapped out. And that's actually pretty easy to do if you're the OS of if you just pin that page to memory. And this also doesn't help you with someone whose got pins with the memory bus or someone who can walk the kernel memory page or stuff like that. So you're right.

AUDIENCE: In terms of browsing, it helps of attackers that come after the fact because if you have to throw away the key, then after the fact, there is no key to memory.

PROFESSOR: Yeah, that's exactly right. So what's nice about this is that it essentially doesn't require modifications to applications. Like you said, you can just put any old thing atop this and get this property for free.

AUDIENCE: Going back a bit-- if you look at the data before [INAUDIBLE] to RAM. How does that avoid the RAM artifacts [INAUDIBLE]?

PROFESSOR: OK, so if I understand your question correctly, I think you're worried about the fact that, sure, data is encrypted when it's on disk, but then it actually can sit in clear text forms somehow in the actual memory itself. So this gets back to the discussion that we had here. So ensuring that data hit the disk encrypted doesn't actually protect against an attacker who can look at RAM in real time.

So basically what we're saying is that if you're only worried about this post-session attacker who can't, for example, look at your RAM views in real time, this works fine. But you're exactly right that this does not provide, for lack of a better term, encrypted RAM. And there actually are some research systems that try to do something like that. It gets a little bit tricky because at some point when you look at your hardware, your processor, it has to actually do something on real data like if you want to do an ad and you have to pass a clear text operands perhaps.

There are also some interesting research systems which actually try to do computation on encrypted data. This is mind blowing like "The Matrix." But suffice it to say that protections that people have for in RAM data are typically much weaker than what they have for data that lives on stable storage. You got a question?

AUDIENCE: Yeah, but does that [INAUDIBLE] because even though the attacker has post-session access, that's just post-private mode access. So there could this could still be a public mode session going on. And the attacker would have access to the machine, right?

PROFESSOR: So you're worried about if a concurrent--

AUDIENCE: So if you have a public mode tab and you have a private mode tab. You close the private tab and the public mode tab stays on-- the attacker could still dump the memory. And the RAM artifacts would be problematic. Is that right?

PROFESSOR: Yeah, interesting-- so we will talk at the end of lecture about an attack which is somewhat similar. So most of the threat models of private browsing due not assume a current attacker at all. In other words, they assume that when you're doing private browsing, there is no other person who have a public mode tab open or anything like that.

But you are in fact correct that the way that private browsing modes are often implemented-- let's say you open up a private browsing tab, you close that tab. You immediately run to go get a cup of coffee. So one attack I will describe is that Firefox, for example, still keeps statistics about, let's say, memory allocation.

So if the memory for your private tab is actually laid with the garbage collected and I can basically go to about.memory or whatever and actually see URLs and stuff in your tab. But yeah, but the long story short, most of these attacker models do not assume a concurrent attacker at the same time that you're privately browsing. Make sense?

So this is one that you do-- do swap encryption like I mentioned. This is nice because this gives you some pretty cool security properties without having to change the browser at all or any of applications running on top of this. And in practice, the CPU cost of doing this kind of thing is much, much lower than the actual cost of doing I/O in general, particularly if you have a disk because with disk you're particularly paying C cost. That's a mechanical cost. This is all processing cost-- pure computational stuff. So typically this not that big of a performance hit.

Oh, god there's physics here. This is always an adventure. So the next attacker that we're going to look at is this web attacker that I mentioned at the beginning of lecture. So the assumption here are that the attacker who controls the website that the user is going to visit in private browsing mode-- how the attacker does not control the user's local machine.

And so the security goals that we want to have against the web attackers are two fold. So first, we don't want the attacker to be able to identify the users. And by identify with, we just mean we don't want the attacker to be able to distinguish the user from any other user that happens to be visiting the site.

And you also might imagine that perhaps we don't want the attacker to tell whether or not we're using private browsing mode. So the attacker can't tell the user employees private browsing. And so as the paper discusses, defending against the web attacker is actually pretty tricky.

So what does it mean, for example, to identify different users. Like I said, at a high level, as you could imagine, the user looks no different than any other users that visits this site. So you can imagine a web attacker might want to do one of two specific things. It might want to say, OK, I see multiple people who were visiting my site in private browsing mode.

You were visitor five, seven, and eight. So in other words, identifying a particular user within the context of multiple private browsing sessions. The second the attacker might want to do is actually try to link a user across public and private mode browsing sessions. So I go to Amazon.com once in public browsing mode. I then go to it again in private browsing mode. Can the attacker actually figure out that I'm actually the same person through those two visits. Yes?

AUDIENCE: This is all a module of the IP address.

PROFESSOR: Ah, yes, that's exactly right. That is excellent foreshadowing. So right now I'm assuming that either user employs Tor or uses something like this. So yeah, we're punting on this whole issue of IP admittedly for now. That's right. So yeah, this segues very well. So what's an easy way to identify the user, as you suggested, the IP address.

So it's a pretty high likelihood if you see two visits that are sort of close in time relatively speaking with the same IP with high likelihood that's probably the same user. And this in fact the motivation-- one of the motivations for stuff like Tor. And so we're actually willing to discuss Tor next lecture. So in case you haven't heard of Tor, it's basically a tool which tries to obscure things like your IP address.

And you could actually imagine layering Tor-- having Tor be the foundation. And then you put private browsing modes atop that. And that might give you some stronger properties then you would if you used private browsing modes at all. But, anyway, so the thing to mention about Tor though is that Tor does provide some sense of IP anonymity. But it doesn't actually address things like the data secrecy lifetime issues or things like that. So Tor-- perhaps you can think of it as maybe necessary, but insufficient for a full implementation of private browsing mode.

And so what's interesting too is that even if a user employees Tor, there are still ways that a web server can identify the user by looking at the unique characteristics of that user's browser. So this is our final demo for today. So let's see here. So going to get rid of this guy. And then let's see. I am going to go to this site called Panopticlick.

Some of so you heard of this. It's run the EFF. The basic idea is it is going to try to identify you the user by looking at various characteristics of your web browser. So I'll show you exactly what I mean. So I want to go-- the URL is very long. This is very stressful for me to type in. So please don't just if it doesn't go through. Let's see. Panopticlick-- did it work? Yes, OK.

So I am going to go to this website. And it's run by the folks at EFF. And I say, OK, test me. So what this is doing is it's basically running a bunch of JavaScript code, maybe an applet-- maybe some Java. And it's trying to fingerprint my browser. And it's trying to figure out how much unique information does it have.

And so-- let me increase the font here. So, for example, one thing it looks at is it looks at you see here what are all the details of the browser plugins that I'm running. So basically it'll run code in it's web page that looks and sees do I have Flash installed? What version of Flash? Do I have Java installed? What version of Java?

So you can see that these are all-- they can't even fit on the tree at one time. These are like all the various plugins and ridiculous formats that my browser supports. Now, the high level-- this should be troubling to you if you're a security person. Am I actually actively using all of these things at a given time? This gives me nightmares.

So what ends up happening is that web servers-- this web attacker-- they can hunt code like this. And they can figure out what are all the plugins that you're looking at. Now if you look at these two columns to the left, what are they? So you see up here. It says bits of identifying information. And then one in x browsers has this value.

So, for example, if we look at a plugin, it's saying there is basically-- it's probably this is the number that's more interesting. It's no longer right. It's saying that 1 in approximately 280,000 browsers has this exact set of plugins. So that's actually a pretty specific way to fingerprint me. It's saying very, very few people who have this exact set of plugins and configurations.

So as it turns out, they're right. I am quite unique. But this a problem from the security perspective. So look at this. The screen size and the color depths for my machine-- 1 in-- what is this? 1.5 million. That's actually pretty shocking. So there's only one person in a sample of 1.5 million people who have this particular screen image.

So these things-- they are additive in some sense. So the more fingerprints you have, the more easy it is for the attacker to figure out exactly who you are. And so note this was done purely from the server side. I just went to this web page. And I just did this. And this is what it got to. One second-- I want to show one more thing. This was done in private browsing mode.

And let's see here. I will open up a regular version of Firefox. Then I run this up again. So note that now I'm in a public mode browser. Before I was in private mode. Now I am public mode. So what you'll see is that when we look at the browser plugins, the extent to which I can be fingerprinted is essentially the same.

So it's going to be a few plugins that may or may not load depending on the vagaries of how privacy mode is implemented. But still, look at that. I'm still very easy to fingerprint. And in fact, if you look back at this guy again-- that screen size and color depth. I didn't change that actually between the two-- between public and private browsing mode.

So that ability to fingerprint there is basically the same. This is one reason why it's so difficult to protect yourself against this web attack because browsers themselves reveal so much information about you just from their configuration.

AUDIENCE: I am curious the screen size and color depth thing. How does it do that? How is that unique? How many screen sizes and color depths are there?

PROFESSOR: Well, I think it's actually hiding some of the magic that it's using to figure out what that is. So at a high level, how do a lot of these tests work? So there's some parts of your browser environment that are testable purely by JavaScript code. So you can imagine that you can essentially have JavaScript code, which looks over the properties of the window object, which is like a global JavaScript manuscript and sees how do you define this weird widget? How do you define this weird widget?

And if so, that my count your plug-ins, lets say. Pages like this also typically take advantage of the fact that Java applets and Flash objects can look at all kinds of more interesting stuff like the fonts that are available on your machine and things like that. So as to the particular screen size and color depth thing-- I think-- don't quote me on that. But I think what ends up happening is it will try to run an applet, let's say, that will actually try to query your graphics card or whatever are the graphics interfaces in Java and poke for different aspects of it.

So I think it's actually more than just screen size and depth. They condense it for size as that. So at a high level, that's how all these tricks work. So you see a bunch of information-- you can snarf up through JavaScript. Then you run a bunch of plugins, which can typically access more stuff and see what they can snarf up. And then you see what's going on.

Does it all make sense? Yeah, this is basically why it's very difficult to protect against a web attacker. And in particular, getting back to the discussion we had about Tor, right, even if I had gone through Tor-- so you'll note the IP address-- you don't see it up here. And so you can imagine that yeah, maybe this thing would actually look at your IP address.

But the thing is like even if I didn't know what IP you were coming from at all, I can do all these things. It's pretty maddening. It's pretty insane. So there are some products out there that tried to do things like imagine that you had a proxy out in the cloud that all your web traffic went through. And then imagine that proxy tried to present a canonical version of a browser runtime.

And imagine that it would always try to emulate, let's say, Firefox v 10.7. Then it would try to send back the data that it rendered as Firefox v 10.7. So some people would try to attack this. It's sort of tricky.

AUDIENCE: [INAUDIBLE].

PROFESSOR: I am not--

AUDIENCE: Is that Tor distributions? Is that paired with virtual machines? [INAUDIBLE].

PROFESSOR: I see-- so the basic idea-- is it a similar idea to what we were just talking about?

AUDIENCE: Yes, [INAUDIBLE].

PROFESSOR: Yeah, so I never heard of that one. I have heard of some of these other projects. I'm imagining there's actually some trickiness in getting systems like this to be efficient a lot of times because particularly imagine if you have something that's interactive. It's like you want to play a game or something like that. It's a little bit awkward to send my mouse click to some proxy. That proxy is then somehow going to [INAUDIBLE].

AUDIENCE: Let me clarify the first station virtual machine actually runs [INAUDIBLE] Firefox. In the proxy it's known as a Tor.

PROFESSOR: Ah, it's just a Tor proxy. So if it's a Tor proxy, sure, that's one thing. Then the only overhead there you have to pay is the regular Tor overhead of going through all the onion route. Yeah, so I was talking there are systems-- let's ignore the IP anonymity for a second because they basically try to say you have your own very fingerprintable browser on your own machine. You don't want to expose that to the web server.

So essentially you go through a proxy, which you think of it all the time like a headless Firefox let's say of some canonical version. The web server thinks it is interacting with this thing. So if I go load this site, I am perceived by the web server as Firefox 10.7 or whatever. If you go there, you are also perceived as Firefox 10.7. Then behind the scenes its' spitting out HTML and stuff like that it collected from the proxy. So those two things are orthogonal.

AUDIENCE: But it seems like you don't need a proxy for this. You could have browser support for this, right? Meaning the Tor browser does this already by trying to appear as the most generic version of Firefox.

PROFESSOR: Yeah, so this is true. Although, I think a problem with a lot of those things that even if you try to lock yourself into one version, there's still a lot of things that can fingerprint it. So I think with the Tor distribution, what they often do is they say, we control what's in the Tor distribution. So if we all go down to the Tor distribution, then forshizzle, we're both going to get Firefox with the same Java version-- the same so on and so forth.

AUDIENCE: Well, it's more than that though. They return screen sizes that are the most common screen sizes whenever you clear the screen.

PROFESSOR: That's all true. Yeah, so one thing that's interesting to look at though-- the Tor team that also put out-- the people who do the bundle-- they'll often put out reports about what data still gets leaked. So stuff does still get leaked out. But you're right. If you could-- the high level of that goal is very reasonable.

It's saying that if we all agreed to download the same distribution and to then not trick it out by adding plugins or stuff like, then you're exactly right. That'd work great. Any other questions? Yeah, so that is it for demo time. And there's more physics. This must have been a riveting previous class. So we will ignore that for the moment. Let's see here.

So where were we? So what is the high-level goal of privacy? And you can think of it as what's your anonymity set if you're a user? So in other words, how many-- what's the size of people-- the number of people that you could be confused for-- you could be mistaken for by an attacker. And so what the browser fingerprinting stuff shows is that oftentimes a web attacker can narrow you down to a very, very tight demographic without controlling anything on your local machine whatsoever.

So that's actually little bit frightening to know. So you might want to think about how can a web attacker determine if you're using private browsing mode? Maybe that's [INAUDIBLE] for some reason. So in the paper they actually describe an attack that uses link colors. So remember, in private browsing mode, the browsers isn't supposed to keep track of the history of the sites that you visit.

And so in the paper, the authors describe an attack in which essentially the attacker-controlled page creates an iframe to some URL that the attacker controls and loads that inside the attacker page. And then it basically looks at the link colors. It creates a link to that page-- that iframe it just created-- and then sees that the link color for that link is the visited color.

So see it as purple versus blue. And the idea that if you do this test in private browsing mode, then presumably the link colors should stay like the unvisited color because the browser is supposed to be forgetting about all this kinds of stuff. So that's the attack they describe in the paper. What's interesting is that this attack actually doesn't work anymore.

So we actually discussed this a couple of lectures back. So this attack that the paper describes is the browser history sniffing attack. So as we discussed a couple of lectures ago, JavaScript code now does not expose correct link colors basically to JavaScript . And it's precisely to prevent these types of attacks. So that particular part of the paper is outdated.

AUDIENCE: What does it point to that browsers now also show links as purple in private browsing mode and turn blue again when you exit.

PROFESSOR: Yeah, it's a bit weird, yeah. They implemented that attack-- the defense-- I think before a lot of the private browsers like a popware. So now they do this additional thing too. The long story short, the attack they describe in the paper doesn't work because of some of these browsers sniffing defenses. But you can still imagine that there may be ways for the web attacker to figure out if you are using private browsing mode.

So for example, when you do private browsing mode, any cookies that you got from public mode should not be sent during private mode. So in other words, if I go to Amazon.com in public mode, I generate some cookies. Then I go to Amazon.com in private browsing mode. When I contact Amazon.com in private mode, those public mode cookies should not be sent. That can actually act as the sign to the web attacker that you actually are using private mode.

AUDIENCE: This is also now you're using the canvass in both of these events, right? So you need to know the IP address.

PROFESSOR: Yeah, that's right.

AUDIENCE: So that link that you were targeting with the link color would be on a per IP basis. And you would have to rely that the user first visited it as a public mode, and you protect it.

PROFESSOR: Ah, so the link-- so the link attack you can actually do in the context of a single page. So imagine that I, the web attacker, construct single page. I, the attacker, have JavaScript that creates an iframe to foo.com like this. So that iframe will load the contents of that page. And then I, the attacker, in the parent frame can then create a link element and then try to look at the color. This worked four years ago.

So in that case, it doesn't rely on the user having explicitly visited that iframe page at all because I, the attacker, can create that in the context of the page. I have gotten [INAUDIBLE]. Any other questions? So yeah, so you can maybe think about how cookies can reveal public and private browsing modes and things like that.

So one thing we might think about is how we can provide a stronger privacy guarantee for private browsers? And for the sake of this discussion, let's just ignore IP addresses for now because as we'll discuss next lecture, we can used Tor to maybe help with some of the privacy of IP addresses. So one thing you can imagine doing is you can imagine using VMs in some way to help provide stronger private browsing guaranteed-- so VM level privacy.

And so the basic idea is that you want to run each private session inside of a separate VM. And then when the user is done with that-- so is finished with the private browsing session, you basically delete VM after that session is done. So what's the advantage of this?

Well, what's nice about this is presumably you can get some stronger guarantees about what privacy properties you can provide to the user because, presumably, the VM has a pretty clean interface to the I/O path of the underlying post-OS. So you can imagine that maybe you combine this VMs into let's say some type of a secure swap solution like Open BSD has-- give us another encrypted disk type thing.

So you can imagine, OK, we have a very clean separation of VM up here and all the I/Os that are generated down here. And so that gives you stronger guarantees than what you can get from the browser, which wasn't designed from the ground up to think very carefully about all the I/O paths and what secrets might leak when it was in storage.

So yes, this provides what's nice about this-- strong guarantees. And, also, what's nice is it doesn't require any changes to your applications-- that is to say to the browser. You take your browser, put it inside one of these VMs-- then everything gets better all magically. It's not location change. So what's bad about this-- I'll use an unhappy face to demonstrate that. So what's bad is first of all, it's heavyweight.

And by heavyweight, I mean that time you want to spin up one of these private browsing sessions, you have to spin up a whole VM. And that can actually be pretty painful. So perhaps users are going to get upset because it's going to take them long time now to launch these private browsing sessions.

And the other problems to is this solution actually has bad usability. And the reason I say that is because now it's actually difficult for users to do things like take files that they've saved in private browsing mode and then take them to the rest of their computer-- any bookmarks that they generate during private browsing mode that who they actually do want to persist will be difficult to get those at the end. It can be done. But there's a lot of friction here. So that's the bummer.

So another thing that you might imagine doing is something that looks like approach number one. But we actually implement it inside of the OS themselves instead of in a virtual machine. So the basic idea here is that you can imagine that each process could potentially run in a privacy domain.

So basically, the privacy domain access the collection of OS global resources that process uses. And so the OS tracks all that kind of stuff. And then once the process dies, essentially the OS goes through and looks at all the things that are in that privacy domain set. And then purely deallocate all those resources. And so the advantage of this over the VM is that it is lighter weight because if you think about it, the VM is essentially agnostic to all the OS state and all the application state that is actually being used to run.

So the result-- it probably does more work than the OS would have to do because the OS presumably knows all the points at which the private browser would be touching I/O, and talk to the network, and stuff like that. So maybe it even knows things like you can actually clear the DNS cache selectively, for example.

So you can imagine that it's much easier to spin these things up-- these privacy domains-- then to tear them down. However, the sad thing, at least with respect to the virtual machine solution, is that it's harder to get this right. So I just described the VM approach as being headway because it's essentially agnostic to everything that's running inside the container.

But what's nice about that is that allows the VM approach to only focus on a few low-level interfaces. And it can focus on those things. For example, the interface the VM uses to write to disk, then you can have high confidence that it's actually managed to contain everything.

Whereas with the OS-- if you think the OS is going to interpose on individual files with system interfaces-- perhaps individual network interfaces and stuff like that-- it's much more complicated to find all of those points at which data can leak if you're going to do that at the OS level. So does that all make sense? Why is this physics everywhere? Ah, god, I'm being tested.

Those are basically some approaches we can use to provide potentially stronger privacy guarantees than what's implemented in private browsers right now. So one question you might have is can we still be an anonymized user if the browser-- sorry, if the user is employing one of these more powerful solutions-- if the user is surfing through VM or surfing one of these privacy domains in the OS-- can we still figure out who they are? And the answer is, yes.

So maybe the VM is unique for some reason. And so similar to how we were able to fingerprint browsers using that Panopticlick website, maybe there's something unique about the way that the VM would be set up that allows to fingerprint it. And it may in fact be the case that maybe the virtual machine monitor or the OS itself is unique in some ways. That would allow a web attacker to figure out who the user was.

And so one cute example of this is TCP fingerprinting. So what's the big idea behind this. So as it turns out, the specification for the TCP protocol actually allows some of the parameters for the protocol to be set by the implementation of the protocol. So, for example, TCP allows implementers to choose things like initial packet size-- the things that are sent out the first part of the TCP connection-- it allows implementers to choose things like that initial time to live in those packets.

And so you can imagine, and in fact, you don't have to imagine that this is actually the truth. You can get off-the shelf tools like InMap, for example, that they actually can tell what operating system you're running with high probability just by sending you packets. They'll send these very carefully crafted packets. And they will look and see things like here's what the TTL was or here's what the packet size distribution was-- here's what the TTP sequence number was. And they basically have a database to fingerprint.

And they say, OK, if the return packet has this, this, and this characteristic, then the table says that you're probably running for some reason Solaris. You're running Mac. You're running Windows or whatever. So even if we use one of these stronger approaches for private browsing with a VM or an OS, you still may be able to run one of those TCP fingerprinting attacks and learn a lot about a particular user.

And one thing that's also interesting to note is that even if we use one of these more powerful techniques to try to protect the user, the user is still shared across both the public and the private browsing session. Still uses-- visibly using the machine. So why is it interesting? Well, it's interesting because you yourself by way that you use computers, may leak information about yourself.

So, for example, as it turns out, users have unique keystroke timing. So if I look at-- if I give everyone in this class the same thing to type in -- the quick, brown fox-- whatever that nonsense is-- and I actually look at the inter-key press timing, we'll all have these unique distributions that can potentially be used to fingerprint us.

Another thing that's interesting is that users have unique writing styles. So there's this branch of security that is called stylography. And the basic idea here is to figure out if I am an attacker, can I figure out who you are just by looking at writing samples from you? So imagine that for whatever reason you're hanging out on 4chan-- don't hang out on 4chan-- and I want to figure out if you've actually, in fact, been hanging out on 4chan.

So perhaps what I can do is I can look at a bunch of different posts from 4chan. Maybe I can cluster those posts into sets of posts that I think look stylistically the same. And then what I can do is I can find things that you've written publicly where you're actually attributed as the author. I'll look at you homework assignments or papers that you've written or things like that. And I'll see do you match any of these clusters from these 4chan comments.

And if so, them maybe I can say maybe send you a stern note. Talk to the parents that their kid has gone off the beaten path. Get off of 4chan. So the reason is I would like to look at this thing called stylography. It's actually quite interesting. Does anyone have any questions about that? Excellent.

So we discuss how we might be able to use VM or modified operating systems to provide private browsing support. And so you might wonder, OK, well, then why don't browsers require users to do one of these things-- to have one of these tricked out VMs or tricked out OSes? So why do browsers take it upon themselves to implement all this stuff?

And so the main reason is deployability. So in fact, browser vendors typically do not want to ask their users to do anything special to use the browser besides install the browser binary itself. This is similar to the motivation of the native client. So if Google wants to add these cool future to end users' computers. But it doesn't want to force users to install some special version of Windows or Linux or whatever. So Google basically says, we'll take care of this ourselves.

Then another reason is actually usability. So a lot of these VM and OS-level solutions in private browsing-- as we've discussed, they make it more difficult for users to persist state from private browsing sessions that they do actually want to persist like downloading files like bookmarks they create and things like that.

So basically the browser vendors say, well, if we implement private browsing modes ourselves, we can actually allow users to do those things. We can allow users to take downloaded files from private browsing mode and take them to the rest of the machine. So that seems nice at first. But note that, of course, that allowing users to export some type of private state actually opens up a lot of security vulnerabilities. It makes it very difficult to analyze security properties that result in private browsing modes actually provide.

And so in the paper, they try to characterize the different types of browser states that can be modified and how current private browsing modes actually handle the modifications at stake. So the paper describes this taxonomy of browser state changes. And so there are four things in the taxonomy. So one type of state change is initiated by the website itself. And there's no user interaction.

And so examples of this type of state change think about stuff like when a cookie gets set-- when something gets added to the address history of the browser-- maybe within a browser cache or something. And so from this type of state, basically, private browsing mode says this state is a private browsing mode session.

But it basically is going to be destroyed when that private browsing session concludes. And so the intuition behind this is that because there is no user interaction in creating this state, then perhaps the right thing for the browser to do is assume that the user wouldn't want that to persist. So another type of browser state change is initiated by the website that the user is visiting. But there is some type of user interaction involved in the state change.

So an example of this might be the user installs client certificate or maybe there's a safe password. So the user tries to login to something. And the browser says very helpfully would you like to save this password? And then if the users says, yes, then these types of things, say passwords, can actually be used outside of the private browsing mode.

And so it's a little bit unclear in principle what the policy for this should be. So what ends up happening in practice is that browsers typically allow statements in this category that set in private browsing modes to persist outside of that private browsing mode under the intuition that the user did have to say yes or no. If the user said, yes, then maybe the user is smart enough to understand that they save some password for some unsavory site and someone comes on later and figures that out, that's the users fault-- not the browsers fault.

So it's a little unclear what the best policy is here. But in practice, this type of state change is allowed to persist outside of private browsing mode.

So there's another type of state change, which is purely initiated by the user. And so here you can think about things like setting a bookmark or maybe downloading files. And so the story for this state is similar to the story for the state up here. So basically because the user was explicitly involved in the creation of that state. Private browsing modes typically say, OK, it's OK to persist these types of changes to the outside world outside of private browsing mode.

Then there's some sets of state which are actually unrelated to any particular session at all. So this is stuff, for example, like an update to the browser itself-- the actual binary that constitutes the browser. And so the way the browser vendors think about this state is this state is essentially assumed to be part of the single, global state that's available to both public and private browsing modes.

And so eventually, if you look at it, there's actually quite a lot of states that will actually potentially leak outside of private browsing mode, particularly if there's user volition involved. So it's interesting to think about is this the right trade-off between security and privacy? So what's interesting is that-- so the paper actually says that it's difficult to sort of prevent a local attacker from detecting whether or not you've been using private browsing mode. And the paper was a little bit vague about why this might be the case.

So one reason why this might be the case is because some of this state that actually leaks from private browsing mode to public browsing mode, essentially it can actually contain hints the state was generated in private browsing mode. So for example, on Firefox and Chrome, when you generate a bookmark in private browsing mode, that bookmark has a bunch of metadata with it.

So for example, the time that it was visited and things like that. So in many cases, that metadata will be set to zero or some null value if that bookmark was generated inside of a private browsing mode. So then later on if someone controls your machine, and they look at your bookmark information-- if they see this metadata set to this zero and null value, they can say, aha, that bookmark was probably generated in private browsing mode.

So one thing to think about is typically we talk about browser security. We talk about, OK, what can people do with JavaScript or HTML or CSS. One thing you might want to think about is, well, what can people do with plug-ins or extensions? So in the context of private browsing, plug-ins and extensions are quite interesting because they're not constrained in most cases by the same origin policy. They can constrain stuff like JavaScript.

And what's interesting is that these extensions and plug-ins typically run with very high authority. Loosely speaking, you can think of them as like kernel modules. They implement new features directly inside the browsers themselves. And so that's a little bit problematic because these plug-ins and extensions are often developed by someone who is not the actual browser vendor.

So what that means is that someone is trying to do something nice and provide you with this nice value add in this browser plug in or extension. But that implementor might not fully understand the context, the security context, in which that extension runs. So that extension may not implement private browsing mode semantics. Or it may try to implement it to do it in a bad way.

And so as I'll describe in a couple of minutes, that's actually bad from the security perspective because that means if we add some of these new plug-ins or extensions, you now can't strongly reason about what the resulting [INAUDIBLE] are. Now, one thing that's nice is that plug-ins are actually probably going the way of dinosaurs. So as you probably know, HTML5 adds all these new features like the audio tag and the videos tag, and stuff like that.

And so a lot of these new features were designed to allow people to get away from plug-ins-- to get away from Java-- to get away from Flash . So when people in the past wanted do things like have rich 2D or 3D graphics, they'd have to do something like Java or Flash. Now they can use things like Web GL. They can used things like the canvass tag.

So probably plug-ins are going away. In fact, the IE team for example, has said that in a couple years they don't think anybody's going to be using plug-ins whatsoever. It's all going to be HTML5 type stuff. In fact, if you go to YouTube-- I don't know if you've noticed. But a lot of times if you go to the video, the video is actually using-- it's called an HTML5 player. They've gone away from their standard plugin-based one.

So that's very interesting. You can already see sites trying to move towards this new plug-in world. However, extensions are probably here to stay for at least the foreseeable future. So it's still important to get those right. So, yeah, the last thing that I wanted to discuss is a paper was written in 2010-- that's four years ago.

So you might think to yourself what's changed about private browsing? And so at a high level, private browsing mode is still tricky to get right. And the reason why it's tricky to get right-- a couple of reasons. So first of all, because the browser [INAUDIBLE] is still growing because of things like this HTML5 stuff.

The interface, which needs to be secure with respect to private browsing mode, that frontier is always getting bigger. And also a lot of times developers-- they are more focused on to adding cool, new features. And then the privacy implications get taken up later on. And so in practice, it is still tricky to produce a private browsing mode which catches all potential data leaks.

So one example, there was a Firefox bug fix from January, 2014. And the basic idea is there is this extension-- it's called pdf.js is basically a way to look at PDF files using pure HTML5 interfaces. And so as it turns out, this extension was allowing public mode cookies to leak when it was being used in private browsing mode.

The idea is that let's say that you visit some websites in public mode. You want to download some PDF. Maybe you get some cookie that comes back. You come back in private browsing mode. You want to view another PDF from that site. And then pdf.js is actually sending those public mode cookies along with any private mode things that were set.

And so in the lecture notes, I actually have a link to the bugzilla discussion about the particular bug. So the fix was actually quite simple once they realized this was the problem. Basically they just have to add a check that says morally speaking, am I in private browsing mode? If so, do some things-- and one of those things is not from the cookies.

So the fix here is actually quite simple. But the challenge was that once again, people added this cool, new extension. But it hadn't really crossed their mind to do this full, invasive audit. And say where are all the places at which private browsing with semantics might be impacted by this particular plug-in.

There's another interesting one too-- this is actually the discussion we had about 30 minutes ago about what happens if you have private tabs and public tabs where you open at the same time or very close to each other. There is actually a bug in Firefox. I think that's from-- let's see here-- yeah, 2011, which is still unfilled. And the basic idea is that if you go to a task in private browsing mode-- OK, you go do some stuff. You then close that tab.

You then open a new public mode tab. And you go to about:memory. So as you probably know, a browser is defined as fake URLs and telling information about how the browser works. So you go to the private tab, close it up, then go to about:memory. This is going to tell you information about all the objects that Firefox has allocated.

So what would happen is that window objects are typically deallocated-- they are [INAUDIBLE] in Firefox. So what ends up happening is that when you open up that new public mode tab, go to about:memory you can actually find information still about that private mode window such as things like a URL, for example, that will tell you how much memory to allocate and all that kind of stuff. And it's all in the plain text.

And so that's an example of how these very subtle interfaces and browsers that can actually leak a lot of information. And so it's very interesting. If you look at the bugzilla discussion, it's actually pretty interesting to see how these problems get resolved in real life. And I put a link it so there is a message that this book was deprioritized when it became clear that the potential solution was more involved than originally anticipated.

So that's a pretty long discussion about how do we fix this. And it involved changing the way that garbage collection is done. And it's very tricky because if you invoke it too often then it gets performance. So there's this long discussion about this. So they said, "It was deprioritized when it was clear the solution was more involved than anticipated." And then in response, a developer said, "That is very sad to hear. This could pretty much defeat the purpose of things like session store for getting about closed private windows."

So the developers about this stuff. Like in the case of the session store, this is storage feature for HTML5-- they had gone to a lot of trouble to make it delete things that belong to these closed private windows. But, basically, what this bug did-- it still-- it basically still left information about that stuff sitting around in memory somewhere.

So long story short, it's still very difficult to get private browsing right. And in fact, there are actually off-the-shelf forensics tools that you can download that will actually look for evidence of both public and private browsing modes. So if you're an attacker, you don't have to roll your own custom tool.

There's this one they call Magnet. I think it's an internet evidence finder. You just go get this thing. It'll do things like look through your page file for RAM artifacts. And it will give you a very nice GUI. It'll say here are the images I found. Here are the URLs. So in practice, these private browsing modes still do leak some information. All right, so next section, we'll talk about Tor.