Chrome on Android: the History Database

What it is

Chrome on Android is built from the same Chromium code as the desktop browser and stores its profile in the same SQLite formats. The History database records every URL the browser loaded in a normal (non-Incognito) tab, one row per visit, together with downloads and the search terms typed into the address bar. Because Chrome is the default browser on most Android phones, it is often where a smishing link, a sideloaded APK download or a search for incriminating information shows up.

The same schema is used by Chrome Beta (com.chrome.beta), Dev (com.chrome.dev) and Canary (com.chrome.canary) under their own package names.

Where it lives

Paths are identical from Android 8 to 16; what changes is the Chrome version, which adds tables over time. Samsung Internet (com.sec.android.app.sbrowser) and other Chromium browsers keep their own, similar databases in their own sandboxes.

What it proves

• That Chrome loaded a URL, and each time it did (visits), not just the last time (urls).
• How each visit happened, from the transition type: a typed URL, a followed link, a form submission, a reload, a redirect.
• What the user searched for with the default search engine (keyword_search_terms).
• What was downloaded, from which page, to which path, how big it was and whether it completed (downloads, downloads_url_chains).

It does not prove the user read the page, and a visit can be triggered by a redirect or by another app opening a link in Chrome. Visits synced from other devices can also appear (see tips).

Key fields

transition & 0xFF gives the core type: 0 LINK, 1 TYPED, 2 AUTO_BOOKMARK, 3 AUTO_SUBFRAME, 4 MANUAL_SUBFRAME, 5 GENERATED, 6 AUTO_TOPLEVEL, 7 FORM_SUBMIT, 8 RELOAD, 9 KEYWORD, 10 KEYWORD_GENERATED. High bits are qualifiers such as 0x01000000 FORWARD_BACK, 0x02000000 FROM_ADDRESS_BAR, 0x40000000 CLIENT_REDIRECT and 0x80000000 SERVER_REDIRECT.

Timestamps

Chrome stores times as microseconds since 1601-01-01 00:00:00 UTC ("WebKit time"). Subtract 11,644,473,600 seconds to reach the Unix epoch:

SELECT datetime(v.visit_time/1000000 - 11644473600, 'unixepoch') AS visit_utc,
       u.url, u.title, v.transition & 0xFF AS core, v.transition,
       v.from_visit, v.visit_duration/1000000.0 AS seconds, v.originator_cache_guid
FROM visits v JOIN urls u ON u.id = v.url
ORDER BY v.visit_time;

SELECT datetime(start_time/1000000 - 11644473600, 'unixepoch') AS started_utc,
       target_path, tab_url, referrer, total_bytes, state, mime_type
FROM downloads ORDER BY start_time;

Retention

Chrome deletes history older than roughly 90 days on its own. Users can clear all or part of it from the history page or Delete browsing data, which removes rows from urls and visits and, depending on the options chosen, download records (never the downloaded files themselves). Incognito tabs write nothing to History. Recently removed rows may survive in the journal or WAL and in free pages of the file. If the user syncs history to a Google account, it also exists server-side.

Collection

• Full file system extraction (AFU) is required: the profile is in the app's credential-encrypted sandbox. Take the whole app_chrome/Default/ folder and app_tabs/ with every sidecar file.
• Logical: you can only pull the downloaded files from /sdcard/Download/; their names and timestamps are useful but say nothing about the source page.
• ADB backup and bugreport do not contain browsing history.

Parsing

• Browser Forensics opens the History file in the browser: visited URLs, a per-visit timeline with decoded transitions, downloads and search terms.
• Hindsight parses a whole Chromium profile folder and builds a timeline across History, cookies, cache and other files.
• ALEAPP has Chrome parsers for Android extractions; Plaso reads the History database as part of a super-timeline.

Investigator tips

• On recent Chrome versions, visits synced from the user's other devices can be stored locally with a non-empty originator_cache_guid. Check that column before attributing a visit to this handset.
• Follow from_visit backwards from a malicious download to find the page, SMS or chat link that started the chain; then look for the same URL in SMS or WhatsApp.
• A .apk in downloads followed by a new package with a sideload installer in installed packages is the classic malware installation sequence.
• Links opened from other apps usually arrive as LINK visits with no from_visit; confirm the source app was in the foreground with usagestats.
• Values in Login Data and cookies are encrypted with keys protected by the Android Keystore; the URLs, usernames and timestamps in them are still readable.