Private and Incognito browsing: what's left behind
2026-06-21 · 4 min
Incognito (Chrome) and Private (Firefox, Safari) mode is built to defeat exactly the on-disk parse that most browser forensics relies on. The session is held in memory and discarded on close, so the usual SQLite and LevelDB stores never see it. That is a real limitation, and pretending otherwise wastes case time. But "nothing on disk in the profile" is not the same as "nothing anywhere" — the traces just move off the browser and onto the rest of the system.
What private mode actually does
The contract is narrow and consistent across vendors: do not persist ordinary session data to the profile on disk, and throw away the session state when the last private window closes. Concretely, that means a private session does not write to:
- History —
urls/visitsin Chromium,moz_places/moz_historyvisitsin Firefox. - Cookies — held in memory only, gone on close.
- Local Storage and IndexedDB — no LevelDB entries for the session.
- Form and search history, autofill.
What it does not promise: invisibility from the network, your employer, or the operating system. That distinction is the whole game.
What this means for a disk parse
If you acquire the profile and run it through an on-disk parser — including this tool — a private session shows up as a near-absence. The history tables will not contain the private browsing. The cookie store will not hold its cookies. You can confirm the browser was used, but the private activity itself is not sitting in the normal databases waiting to be queried.
Be honest about this with whoever tasked the case. An on-disk profile parse is the wrong primary instrument for a private-mode question. It is still worth running — to establish baseline normal activity and to catch the leaks below — but do not promise a browsing timeline it cannot deliver.
Where traces can still live
Private mode contains the browser, not the machine. Look outward:
- System DNS cache. Name resolution happens at the OS level. Visited
hostnames can sit in the resolver cache regardless of browser mode (Windows:
ipconfig /displaydns; survives until flush or reboot). - RAM. The whole session lives here. URLs, page contents, form input and in-memory cookies are recoverable from a memory capture — and from anything RAM spilled into: the pagefile/swap and the hibernation file.
- Cache and temporary files. Mostly memory-backed in private mode, but under some conditions — large media, certain plugins, crashes — fragments reach disk. Treat slack and unallocated space as in scope.
- Downloaded files the user saved. A private session does not record the download in history, but the file the user chose to keep is on disk, with its own filesystem timestamps.
- Bookmarks added during the session. Bookmarking is an explicit persist action; those entries survive in the normal bookmarks store.
- OS-level execution artifacts. Prefetch, jump lists and shimcache show the browser ran and when — not what was browsed, but useful corroboration.
- Extensions. Where the user allowed them in private mode, an extension can log activity to its own storage, entirely outside the private-session contract.
How to run a private-mode case
Reorder your priorities. Memory capture moves to the top: a live RAM image, taken before shutdown, is the single highest-yield source for private browsing. After that, OS artifacts (prefetch, DNS cache, pagefile, hibernation file) carry more weight than the browser profile.
Acquire the profile anyway — for the baseline, the saved downloads, the
bookmarks, and any extension storage — but set expectations: it answers
"normal" browsing, not the private session. As always, grab the -wal / -shm
sidecars; on a machine used in both modes, the last normal commits often sit
in the WAL. Cross-reference saved downloads against the
MFT for file creation and the
USN journal for any later cleanup.