The resignation letter arrived on a Friday afternoon. By Monday morning, the company’s general counsel was on the phone with an outside attorney. By Tuesday, we had a laptop.
The allegation was familiar: departing employee, potential competitor destination, sensitive company data in the wrong hands. The evidence question was also familiar: what did the employee actually do with company systems in the weeks before leaving?
Browser history analysis is often dismissed as superficial — you look at what websites someone visited, which seems thin. But Chrome’s local databases contain considerably more than just visited URLs. Download records, search terms, form data, and the timing of access to specific cloud storage URLs can construct a detailed picture of data movement that’s hard to explain away.
This is a composite illustration representative of IP theft investigations involving browser artifact analysis.
The Allegation
The employee held a product management role with access to competitive intelligence databases, customer pricing models, and vendor contract terms. The company’s concern: in the eight weeks before resignation, the employee had begun a side conversation with a direct competitor — confirmed through a mutual contact who’d mentioned it inadvertently — and several files from a shared drive had been accessed from an IP address outside company networks.
Our engagement was to examine the company laptop for evidence of data exfiltration or unauthorized access to competitive information.
Chrome History: More Than Visited URLs
Chrome’s browser history lives in a SQLite database file at:
“`
C:\Users\[Username]\AppData\Local\Google\Chrome\User Data\Default\History
“`
The `History` file contains multiple tables. The ones most relevant to IP theft investigations:
`urls` table. Every URL Chrome has visited, with visit count and last visit time. This is the table most people think of when they think “browser history.” For IP theft, you’re looking for visits to competitor websites, cloud storage services, personal webmail, and file transfer services.
`visits` table. Records every individual visit event, linked to a URL in the `urls` table. The key distinction: the `urls` table shows that a URL was visited and when it was last visited. The `visits` table shows every visit with individual timestamps. An employee who visited a competitor’s customer portal 47 times in three weeks will show a count of 47 in `visits` — the `urls` table only shows the last visit date.
`downloads` table. Records every file downloaded through Chrome, including the URL it came from, the file path on the local disk, the download start time, end time, and total bytes transferred. This is frequently the most probative table in IP theft cases.
`keyword_search_terms` table. Search queries entered into Chrome’s address bar or Google search. Searches for competitor pricing, customer names, or product specifications during the relevant period are worth documenting.
`segments` table. Grouped visit segments — useful for understanding the pattern of site access (continuous browsing session vs. isolated visits).
What the History Showed
The examination covered the 60 days before resignation, matching the scope authorized by counsel.
Competitor portal access. The `visits` table showed 31 visits to a URL pattern consistent with a competitor’s supplier extranet — a password-protected portal not accessible to the general public. These visits were concentrated in a 12-day window, six weeks before resignation. The `urls` table would have shown only the last visit and a count; the `visits` table showed the distribution across specific dates and times.
The employee didn’t have a legitimate business reason to access this competitor’s portal. We documented the URL, the visit count, and the date/time distribution of the 31 visits without drawing the conclusion about how access was obtained — that determination was outside our scope.
Cloud storage access. The `urls` table contained multiple visits to personal Google Drive and Dropbox URLs. The Dropbox URLs were particularly interesting: they followed the pattern of shared folder access URLs (`/sh/` in the Dropbox URL structure), not personal account URLs. This suggested the employee was accessing shared folders — either their own shares or folders shared with them by a third party.
More significantly: the Dropbox access occurred in tight temporal clusters with the competitor portal visits, on the same dates.
Download records. The `downloads` table showed 18 file downloads in the 60-day period. Of these, 14 were clearly benign (software installers, PDFs of industry publications, internal tools). Four were flagged for further analysis:
- Two were downloads from Google Drive URLs matching the shared drive where competitive intelligence documents were stored
- One was a download from a personal Gmail account’s attachment URL (indicating the employee had emailed something to themselves and then downloaded it)
- One was a download from a Dropbox shared folder URL
The file names (preserved in the `downloads` table) matched document naming conventions used in the company’s competitive intelligence library.
USB Device Connections: The Physical Transfer Layer
Browser history documents cloud-based movement. USB connections document physical movement. Together, they cover the primary exfiltration vectors.
We examined the Windows registry USB device records (described in detail in the [corporate espionage case study](/corporate-espionage-logical-acquisition/)) and found two USB storage devices of interest:
A standard USB flash drive that had connected on multiple occasions during the period of interest. The company had no record of issuing this device.
More interesting: a personal smartphone connected via USB during three sessions in the final two weeks before resignation. Smartphones connected via USB in file transfer mode (MTP) appear in the USB device enumeration registry just as external drives do. When connected in MTP mode, Windows can read and write files to the phone’s storage.
The phone connection timestamps correlated with the Dropbox access periods in the browser history — same days, with the phone connection following the Dropbox access by 30 to 90 minutes in two of the three sessions.
Correlation Is the Core of the Analysis
No single artifact source makes the case here. What makes the findings credible is the convergence:
Competitor portal access (31 visits, concentrated in 12 days) → Dropbox shared folder access (same dates, temporal clustering) → Phone connected in MTP mode (same dates, following Dropbox access) → File downloads from company cloud storage (file names matching competitive intelligence documents).
Each artifact source independently establishes a pattern of behavior. Together, they describe a transfer chain: access competitor information, stage company competitive intelligence in a cloud service, transfer to personal device.
The timeline also mattered. The competitor portal access began approximately six weeks before resignation. The download and phone connection activity concentrated in the final two weeks. This escalation pattern is common in insider threat cases — the reconnaissance phase follows the decision to leave; the extraction phase accelerates as the departure date approaches.
The Download Table as Key Evidence
The `downloads` table deserves specific attention because it’s frequently overlooked.
Unlike the `urls` and `visits` tables, which show where the browser went, the `downloads` table shows what came out of those visits onto the local disk. The combination of:
- The source URL (where the file came from)
- The destination path (where it went on the local disk)
- The download time
- The file size
…gives you a document-level view of what was transferred and when.
In our examination, the download destination paths showed that company documents were downloaded to a folder path under `C:\Users\[Username]\AppData\Roaming\Dropbox\` — inside the local Dropbox sync folder. A file downloaded to this path would be automatically synced to the employee’s personal Dropbox account by the Dropbox desktop client.
This is the full chain: download from company cloud → lands in local Dropbox sync folder → syncs to personal Dropbox → accessible from any device. The browser history captured the first step. The Dropbox client log (a separate artifact) confirmed the sync.
Personal Webmail as an Exfiltration Vector
The Gmail attachment download in the `downloads` table pointed to a separate channel: email to a personal account.
Gmail attachment URLs follow a predictable pattern. The URL in the `downloads` table confirmed the download came from a Gmail account. The attachment file name, preserved in the `downloads` table, matched a pricing model document from the company’s finance shared drive.
We documented this as a finding: the browser history records a download of a file named X from a Gmail attachment URL at time Y. We did not examine the Gmail account content — that required separate legal process — but the download record alone placed the file in the employee’s personal Gmail at the documented time.
For counsel, this created the basis for a legal demand directed at Google for account activity records during the relevant period.
Report Structure for IP Theft Matters
IP theft reports serve a litigation function. They’re read by opposing counsel, challenged by opposing experts, and sometimes presented to a court or arbitrator. Structure matters.
We organized our findings into sections corresponding to the exfiltration channels we identified:
Cloud storage access. Competitor portal visits with dates, times, and visit counts. Company cloud storage downloads with source URLs, file names, and destination paths. Dropbox folder access with temporal correlation to other activity.
Physical transfer. USB device records with connection dates. Personal phone MTP connections with temporal correlation to cloud activity.
Email channel. Gmail attachment download record with file name and timestamp.
Timeline summary. A unified chronological view of all findings, with activity from each channel mapped to specific dates. This is the exhibit that works for an arbitrator or judge who needs to see the pattern without reading 50 pages of artifact analysis.
Each section follows the same structure: what artifact we examined, how we accessed it, what tool we used, and what the artifact shows. No conclusions beyond what the evidence directly supports.
What We Didn’t Find (and Why That Matters Too)
A complete forensic report documents negative findings as well as positive ones.
We found no evidence of access to the company’s source code repository or customer database. These were explicitly included in the examination scope as areas of concern. Their absence in the browser history, download records, and USB artifacts is forensically meaningful — it constrains the scope of what may have been taken.
We also found no evidence that the employee had accessed remote access tools or VPN configurations that would have allowed access to company systems from outside the network. The network-based accesses that triggered the initial concern were outside our artifact set; we noted this as a scope limitation.
Documenting what you didn’t find prevents opposing counsel from arguing that you cherry-picked your findings. And it accurately reflects the limits of what your examination covered.
Frequently Asked Questions
Can Chrome history be selectively deleted without leaving obvious traces?
History can be deleted — the `urls` and `visits` tables simply have rows removed. However, selective deletion often leaves artifacts. The SQLite database’s WAL files and page slack can retain partially overwritten records. More importantly, the indexing structure of the database changes when rows are deleted — statistical anomalies in the index structure can indicate targeted deletion rather than routine history clearing. External corroboration (system event logs, network proxy logs, print records) can also fill gaps left by history deletion. Document the gaps and document the corroborating sources you used to fill them.
Is Chrome history from a company-issued device usable in litigation without consent?
Company-owned devices are generally fair game for employer forensic examination under the company’s acceptable use policy, without the employee’s specific consent. The analysis changes significantly for personal devices or for company devices where the company failed to establish clear ownership and monitoring policies. Before any examination, review the company’s IT policies, the employee’s signed agreements, and consult with counsel about jurisdiction-specific requirements. This is legal guidance, not forensic guidance — we implement the examination within whatever authorization framework counsel establishes.
How do you distinguish between incidental visits to a URL and purposeful access?
Visit count, visit duration patterns (available via the `transitions` field in the `visits` table), time-of-day distribution, and co-occurring activity. A single visit to a competitor URL might be incidental — a result from a Google search that the user didn’t intentionally seek out. Thirty-one visits in 12 days, during off-hours, with file downloads following shortly after, is not incidental. Present the full visit pattern, not just the existence of visits. The pattern is more probative than any individual visit.
What if the employee used the company laptop in private browsing mode?
Incognito mode doesn’t write to the `History` database. But it doesn’t prevent all artifacts. The DNS cache, Windows Event Logs, proxy server logs (if the company ran a network proxy), and browser crash reports can all contain traces of incognito activity. Additionally, incognito mode is disabled by corporate Chrome policy in many organizations — check the Chrome `Preferences` file for any enterprise policy flags. If incognito appears to have been used during the relevant period (evidenced by gaps in history correlating with network log activity), document the gap and the evidence suggesting incognito use without overstating what you can determine about the content of those sessions.
How long does Chrome history persist before being overwritten?
Chrome retains browsing history for 90 days by default. Entries older than 90 days are automatically purged. For investigations that involve activity more than 90 days before examination, browser history won’t contain those records — examine proxy server logs, firewall logs, or other network-layer records that may capture the relevant period. Some organizations retain proxy logs for 12 months or longer, making them a valuable backup source for browser-level activity when Chrome’s own history has rotated.