Chrome Preferences and account artifacts
2026-06-21 · 3 min
Two JSON files at the root of every Chromium profile answer the question
investigators ask first: whose profile is this? Preferences and
Secure Preferences record the signed-in account, the profile name, sync
state, configured startup pages and the default search engine. They are
plain text, parse in seconds, and tie a folder of databases to a real
identity. Edge stores the same files in the same shape.
Where they live
Both files sit per profile, alongside the SQLite databases:
…\User Data\<profile>\Preferences
…\User Data\<profile>\Secure Preferences
<profile> is Default, Profile 1, Profile 2, and so on — one pair
per browser profile. See
where browsers store their artifacts
for the rest of the profile layout.
The account: who was signed in
The single most valuable object is account_info, an array of the Google
accounts bound to the profile:
| Field | Meaning |
|---|---|
email | The signed-in account address |
full_name | Display name on the Google account |
gaia | The stable numeric Google account id |
The gaia id is the one to anchor on. Emails and display names can be
changed; the GAIA id is the durable identifier that survives renames and
lets you correlate the same person across devices or profiles. A profile
with a populated account_info is signed in and, usually, syncing —
which means artifacts here may originate from other machines too.
Profile metadata
A handful of fields under profile describe the profile itself:
| Field | Meaning |
|---|---|
profile.name | The user-visible profile label |
profile.created_by_version | Chrome version that created the profile |
profile.creation_time | When the profile was created (microseconds since 1601-01-01 UTC) |
creation_time gives you a hard lower bound for the profile's lifetime,
and created_by_version can corroborate or contradict a claimed install
date. Both go straight into a timeline.
Startup, homepage and default search
These fields describe how the browser was configured to behave — useful for spotting hijacking and for understanding what the user saw on launch:
session.restore_on_startup—1restore last session,4open a specific set of pages,5open the New Tab page.session.startup_urls— the explicit pages opened on launch whenrestore_on_startupis4.homepageandhomepage_is_newtabpage— the configured home target.default_search_provider(ordefault_search_provider_data) — the default search engine, including its search URL template.
A startup URL or default search pointed at an unfamiliar host is a
classic adware / search-hijack indicator. The signin block and the sync
settings round out the account picture — whether sign-in is enabled and
what data categories are syncing.
Secure Preferences: tamper detection
Secure Preferences carries everything above plus two things worth
calling out. First, it holds the authoritative extensions.settings
block — the real installed-extension inventory (see
browser extensions forensics).
Second, it stores a protection.macs tree: HMACs computed over selected
preference values, seeded per profile.
Chrome verifies these MACs on load to detect off-browser tampering — for example an attacker hand-editing the file to add an extension, change the default search, or pin a startup page. A missing or mismatched MAC is itself evidence: either the value was edited outside the browser, or it was written by a process without the seed needed to recompute the HMAC. Treat MAC mismatches as a lead, not noise.
In the tool
BrowserForensics parses Preferences and Secure Preferences into a
profile/account table — email, full name, GAIA id, profile name and
creation version, startup configuration and default search — alongside
the installed-extensions table, entirely in your browser with no upload.
That turns the first question of any browser exam, whose profile is
this, into a one-file answer. Cross-reference it with
Local State, which lists every
profile on the machine, and with the
History databases for activity.