The first question is which database state a browser-history finding describes. A main database copied by itself can differ from the state available to a running application. A logical export can be internally usable while omitting original transaction files and filesystem context. Identify the collected object before interpreting its rows.
Understand the companion files
SQLite’s write-ahead logging documentation explains that WAL mode places changes in a separate file and that the WAL can form part of the database's persistent state. Separating the database from its relevant WAL can lose committed changes or produce corruption. This is a database-level fact; whether a particular browser database uses WAL depends on the application, build, and profile.
Preserve the acquired database, any present WAL and shared-memory companion, their original paths, acquisition times, sizes, and hashes. Document absent companions rather than creating replacements and implying they came from the source. A file's absence can reflect normal database lifecycle or the collection method; it is not by itself evidence of deliberate interference.
Avoid an accidental reconstruction of the source
Keep original acquisition files under controlled handling and examine a documented working set. Opening a database with a library or graphical utility can create companions or otherwise change the working directory. Record the program version, open mode, and hashes before and after relevant transformations. A changed working copy needs an explanation; it does not retroactively invalidate an independently preserved acquisition.
SQLite’s online backup API documentation describes producing a database snapshot using database-aware methods. Such a snapshot serves a different purpose from preserving the original files and transaction context. If a collection tool uses a backup API, label its result as a derived database and retain the tool's description of scope. Do not imply it contains every residual byte available on the device.
Establish the browser and profile scope
Record the browser version, profile path, account context, collection state, database schema, and parser version. Verify a table and field against the actual schema before accepting a parser's “visit” or “download” label. An entry can represent synchronization, background behavior, import, or another application process; determining its meaning requires browser-specific evidence.
Preserve original timestamp values beside converted times. Distinguish a row's recorded event time from the filesystem times of the database and the analyst's export time. A database copied today can contain older application records without inconsistency.
Test completeness with a bounded comparison
- List the collected files and companions, including any acquisition warnings.
- Compare the parser's row counts and selected records with an independent reading of the preserved working database.
- Record unsupported tables, errors, and any recovery mode used.
- Compare an important candidate with an independent service record or another relevant artifact.
Successful parsing does not establish that every transaction was preserved. Recovered fragments also require a separate label and contextual support; a fragment is not automatically a committed application record.