Shared computers changed the rules on browser forensics. When one device has three profiles — a work account, a personal account, and maybe a guest session — examiners who only look at the default profile are missing the full picture.
Multi-profile browser usage has exploded over the last few years. Chrome, Firefox, and Edge all support multiple user profiles on the same installation. Each profile gets its own history, cookies, cache, and saved passwords. From the browser’s perspective, they’re separate users. From a forensic standpoint, they’re all on the same machine.
This matters more than most practitioners appreciate.
How Profile Isolation Works (and Where It Breaks Down)
Chrome stores each profile in a numbered subdirectory under `User Data\`. The default profile lives at `User Data\Default\`. Additional profiles are at `User Data\Profile 1\`, `User Data\Profile 2\`, and so on.
Firefox uses a different naming convention — profile folders get random alphanumeric suffixes — but the structure is similar: each profile has its own `places.sqlite` (history), `cookies.sqlite`, and cache directory.
Edge follows Chrome’s pattern almost exactly, given its Chromium foundation.
The isolation is real at the application layer. If you’re in Chrome Profile 1, you can’t see the history from Profile 2 in the browser UI. Cookies don’t cross profiles. Saved passwords are separate.
But the filesystem doesn’t care about profile isolation. All profiles live on the same physical drive, under the same user account’s directory structure. A forensic examiner with read access to the filesystem reads all of them simultaneously.
Synced History vs. Local History
This is where it gets complicated, and where examiners sometimes draw incorrect conclusions.
Chrome profiles can sync with Google accounts. When sync is active, Chrome sends browsing history, bookmarks, and open tabs to Google’s servers and pulls history from other devices signed into the same account.
What this means forensically: the history in a local Chrome profile may contain entries from activity on other devices — the user’s phone, a work laptop, a home desktop. These synced entries are indistinguishable in the local database from entries created on the device you’re examining.
The `urls` table in Chrome’s `History` SQLite database doesn’t flag entries as local vs. synced. You need to cross-reference visit times against system event logs (logon/logoff, application usage records) to determine whether the machine was in use when the history entry was created.
This matters enormously in attribution cases. “This computer’s browser history shows the user visited X” is only accurate if the device was actually in use at the relevant time. Synced history from a phone visit can appear in a laptop’s browser database.
Firefox Sync works similarly. Edge syncs with Microsoft accounts.
Why Multi-Profile Analysis Matters in Shared-Device Cases
Consider a household computer used by multiple family members — a scenario common in divorce proceedings, estate disputes, and child custody matters.
User A logs into Windows, opens Chrome, and uses Profile 1 (signed into their Google account). User B logs into a different Windows account, opens Chrome, and has Profile 1 under their own Windows profile.
So far so good — the Windows profiles separate them cleanly.
But what about a single Windows account shared between household members? In that scenario, all Chrome profiles exist in the same directory, under the same Windows user. Distinguishing which family member created which browser history entries requires more than just looking at the profile — you need system event logs, application focus events, and potentially device-level usage data to attribute activity to a specific person.
The same challenge arises in employment cases involving shared workstations, small offices where multiple staff use the same credentials, and civil investigations involving family-owned businesses.
The Guest Session Question
Chrome and Edge both offer a guest browsing mode that explicitly avoids writing history to disk. In theory, guest session history disappears when the window closes.
In practice, the same caveats apply as with incognito mode — RAM artifacts, OS swap files, and GPU cache can retain traces. But more practically: the value of multi-profile analysis in cases involving guest sessions is usually about what other profiles reveal about normal usage patterns, not about recovering guest session data directly.
If a user ran guest sessions but had an active signed-in profile, the signed-in profile’s history can establish a baseline of normal behavior that contextualizes the gaps where guest sessions presumably occurred.
What a Complete Multi-Profile Examination Looks Like
Start by mapping every profile on the device. On Windows with Chrome:
“`
C:\Users\[Windows User]\AppData\Local\Google\Chrome\User Data\
“`
List every subdirectory. Note which ones contain a `History` database. Document the Google account associated with each profile (visible in the `Preferences` JSON file in each profile directory, under the `account_info` key).
Then analyze each profile’s `History` database independently. Compare the activity timelines. Look for:
- Temporal overlaps (two profiles active at the same time is impossible on a single keyboard — if it appears, sync is the explanation)
- Shared search terms or URLs across profiles (suggests same user operating multiple profiles)
- Gaps in one profile that correspond to activity in another
Cross-reference the browser history timestamps against Windows event logs (Event ID 4624 for logon, 4647 for logoff, application event logs). This grounds browser activity to specific authenticated sessions.
Tools like Hindsight process multiple Chrome profiles in a single run, outputting unified timelines. For Magnet AXIOM users, the browser artifact analysis section handles multiple profiles automatically and flags them separately in the results.
A Note on Profile Attribution
Knowing what was in a browser profile is not the same as knowing who was at the keyboard.
Profile analysis tells you what activity occurred within a specific browser profile. Attributing that activity to a specific person requires one of: single-user device with documented sole access, physical access logs, witness testimony, biometric authentication records, or behavioral analysis consistent with a known individual’s patterns.
In shared-device cases, be precise about what you’re claiming. “Profile 2 contains history showing access to X on these dates” is a forensic finding. “User B accessed X on these dates” is a conclusion that requires the attribution bridge — and that bridge needs to hold up under cross-examination.
The [Chrome offline cache evidence guide](/chrome-offline-cache-evidence/) covers how cache data complements history analysis, particularly when history has been selectively cleared but cache entries remain.
