reconstruct what someone did from their browser data

your browser remembers everything, even when you don't

here's a thing most people don't think about until it matters: your browser is basically a diary. not a metaphorical one, an actual sqlite database sitting in a folder on your machine, quietly logging where you went, what you typed, what got downloaded, and what you were logged into. it doesn't ask permission. it's just how browsers work.

this reel context is framed around "reconstructing what someone did," and in dfir that's a completely normal, legitimate thing to do on a machine you're investigating, your kid's laptop, your company's endpoint, your own device after you think something got compromised. the same data that makes browsers convenient for you makes them a goldmine for anyone who gets access to that profile folder. so let's break down what's actually stored, and then, more importantly, how you lock it down on your own systems.

history and downloads: the where

every url you visit gets a timestamped row in a sqlite file, usually called History, sitting inside your browser's profile directory. it's not just "visited example.com," it's visit count, last visit time, referrer chains, and typed vs clicked navigation. downloads get their own table with source url, save path, and completion time. this is the part most people already assume exists. the part they don't think about is that clearing "history" in the ui doesn't always securely wipe the underlying file, it just marks rows for deletion, and depending on the browser and disk, remnants can still be recoverable from the file itself.

cache: the what, even after you deleted it

the cache stores actual page content, images, scripts, so pages load faster next time. this is where things get interesting for reconstruction, because cache entries can persist even after history is cleared, since they're a separate mechanism entirely. a properly examined cache can show pages a user viewed even if they never intended to leave a trace, because "clear history" in most people's mental model doesn't include "clear cache" unless you specifically check that box.

cookies and sessions: the who and the logged-into-what

cookies get their own sqlite database too, and this is the sensitive part. session cookies and auth tokens are what keep you logged into gmail, your bank, whatever, without retyping your password every five minutes. if someone gets read access to that cookies database and the browser isn't enforcing encryption properly, they don't need your password, they can potentially hijack an active session outright. this is exactly why "just clearing history" after using a shared or public computer is not enough. the login evidence lives in a completely different table.

why it's all sqlite, and why that matters

chromium and firefox based browsers store almost all of this in sqlite database files inside the profile folder, things like History, Cookies, Web Data. that's a deliberate design choice, sqlite is fast, structured, and query-able. the flip side is that any standard sqlite browser tool can open these files and run queries against them if it has file system access. no exploit required. no cracking. just read permissions on the right folder. that's the entire point of this post: the barrier to reconstructing someone's session isn't sophistication, it's access to the file.

how you protect your own exposure

start by treating your browser profile folder like the sensitive file it is. full disk encryption on your device means someone needs your login to even reach that folder in the first place, that's step one and it's non negotiable. next, use your browser's actual settings to clear cookies, cache, and history together on a schedule if you're on shared machines, not just one of them.

turn on a master password or os level keychain protection for saved logins, don't let the browser store credentials in plaintext-adjacent form if you can avoid it. log out of sensitive accounts instead of just closing the tab, since an open session cookie is still valid until it expires or you explicitly kill it. and if you're auditing your own machine after letting someone else use it, or checking a device you administer, tools like a basic sqlite viewer pointed at your own profile folder will show you exactly what's retrievable, which is the best way to understand your real exposure instead of guessing.

on shared or public computers, use a private/incognito window as a baseline, it limits what gets written to disk in the first place, though it's not a substitute for full disk encryption and good account hygiene on your own devices.

the takeaway

your browser isn't just a tool, it's a persistent record of your digital behavior sitting in plain sqlite files. understanding that is what lets you actually defend it, encrypt your disk, clear the right data, kill sessions you're done with, and know what's recoverable before someone else finds out for you.