Lecture 18: Private Browsing

What this lecture covers

This lecture asks what "private browsing" actually promises and why no browser can fully deliver it. It separates two attacker models used in the reading: a local attacker who gets your machine after a private session ends, and a web attacker who runs the site you visit. Each has different goals and different defenses, and the lecture shows with live demos how both can still learn what you did.

It sits in the security course's privacy unit, right before a lecture on Tor, and builds on earlier lectures about browser history sniffing. After watching, you should be able to name the categories of browser state a private session is supposed to erase, explain why RAM artifacts and browser fingerprinting defeat that guarantee, and compare the VM-based and OS-based designs proposed to do better.

Key ideas

• Local attacker: someone who controls the user's machine only after the private session ends; the goal is that they can't recover which sites were visited.
• Web attacker: the site itself, which tries to identify the user or detect that private mode is being used, without controlling their machine.
• Anonymity set: the idea that a user's privacy depends on being indistinguishable from many other users, not on any single technical trick.
• RAM artifacts: private-session data that never touches disk directly can still leak through paging, hibernation files, or memory left uninitialized for a new process.
• Secure deallocation: zeroing memory or files after use is necessary but often insufficient, since copies of secret data linger in kernel buffers, standard-library buffers, and swap.
• Swap/disk encryption: encrypting data before it hits stable storage and discarding the key at reboot makes recovering that data cryptographically hard, without changing the browser itself.
• Browser fingerprinting: plugins, fonts, screen size and similar details can identify a user almost as precisely in private mode as in public mode, since IP address is not the only distinguishing signal.
• State taxonomy: browsers decide what to keep after a private session based on whether the state change involved user interaction (site-only changes are deleted; user-approved ones, like saved passwords or downloads, often persist).

Walkthrough

What private browsing tries to guarantee (0:00)

The lecture opens by noting there is no formal definition of private browsing; browser vendors implement a "living standard" that evolves as features and bugs are discovered. The paper being discussed formalizes privacy against two attackers: a local attacker who inspects the machine after the session, and a web attacker who runs the visited site. Combining both attacks strengthens an adversary's ability to de-anonymize a user, for example by asking a site whether it has seen a particular IP address.

The local attacker and what state must not persist (3:02)

For the local attacker, the security goal only applies after the session ends — a pre-session attacker who already controls the machine can do anything, including key-logging. The lecture also raises "plausible deniability" (hiding that private mode was used at all) as a goal the paper says is hard to achieve. It then catalogs client-side state: JavaScript-visible state like cookies and DOM storage, the browser cache, and visit history are all supposed to be wiped; configuration state, downloaded files, and installed plugins are typically allowed to leak outside the session because the user explicitly acted to create them.

RAM and disk artifacts: the gcore demo (11:12)

Even without writing to disk, a private tab's memory can be reflected into the page file or hibernation file. The instructor demonstrates this with gcore, taking a memory snapshot of a private browsing tab and searching it with strings, finding page URLs and HTML content still in RAM. A second demo runs a small C program that reads a secret file, prints it, and explicitly zeroes its buffer — yet a memory dump of the running process still contains fragments of the secret, because I/O passes through multiple layers (kernel buffers, C library buffers) that the application never touches directly.

Fixing data lifetime: zeroing and swap encryption (26:27)

Two general fixes are discussed. Zeroing memory on deallocation works but costs performance and must be applied everywhere data might live — process memory, kernel buffers, freed pages, even SSD logs and discarded disks. The alternative, encrypting data before it reaches stable storage and discarding the key on reboot, makes disk contents unrecoverable without needing to track every place data was written. OpenBSD's swap encryption is given as a real example; it only protects against a post-session attacker, not one who can inspect RAM in real time.

The web attacker and browser fingerprinting (34:32)

Against a web attacker, the goals are to avoid being identified among other visitors and to avoid revealing that private mode is in use. IP address is an easy identifier, which motivates layering Tor underneath private browsing — a topic for the next lecture. But Tor alone doesn't address fingerprinting.

Stronger designs: VMs, privacy domains, and their limits (53:51)

The lecture compares running each private session in its own VM, deleted afterward, against implementing "privacy domains" inside the OS that track and securely deallocate resources per process. VMs give strong guarantees over a narrow interface but are heavyweight and hurt usability (exporting bookmarks or downloads is awkward); OS-level domains are lighter but harder to get fully right because there are more interfaces to interpose on. Even these stronger designs don't stop TCP/OS fingerprinting or attacks based on a user's own unique keystroke timing or writing style (stylometry), and they don't stop the user from being the same physical person across public and private sessions.

Before you watch

• Review the earlier lecture on browser history sniffing and link-color attacks, since this lecture explains why that specific attack no longer works.
• Be ready to see the demo section move quickly between a live browser, a memory dump tool, and a small C program; pausing helps if you want to read the terminal output.

Check your understanding

1. Why does the local-attacker threat model only apply "post-session," and what happens to the guarantees if the attacker controls the machine beforehand?
2. Why is zeroing an application's own buffer insufficient to remove a secret from memory?
3. How does swap/disk encryption with a discarded key protect against a post-session attacker but not an attacker who can read RAM live?
4. Why can a web attacker often identify a user in private browsing mode without ever learning their IP address?
5. What is the main tradeoff between the VM-based and OS-based approaches to stronger private browsing?