browserforensics
Back to all articles

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:

FieldMeaning
emailThe signed-in account address
full_nameDisplay name on the Google account
gaiaThe 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:

FieldMeaning
profile.nameThe user-visible profile label
profile.created_by_versionChrome version that created the profile
profile.creation_timeWhen 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_startup1 restore last session, 4 open a specific set of pages, 5 open the New Tab page.
  • session.startup_urls — the explicit pages opened on launch when restore_on_startup is 4.
  • homepage and homepage_is_newtabpage — the configured home target.
  • default_search_provider (or default_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.

Further reading