The general problem
Internet evidence has an unusual quality. It looks self-evident - here is the page, here is the date, here is the address it came from - and almost none of that is as solid as it appears. The page is a rendering assembled from parts, the date may belong to a crawler rather than to the publisher, and the address identifies a network endpoint rather than a person.
Retained as an internet expert, my work is to collect that material properly, explain how each system actually produces its records, and then say what follows from it and what does not. The second half is the part that decides whether an opinion survives. Web evidence that is presented as more certain than its source systems allow gets dismantled by anyone who knows how those systems work, and that damages the retaining party more than a modest, well-bounded finding ever would.
The disciplines below cut across matter types - contract, intellectual property, defamation-adjacent claims, employment, fraud. The technical questions repeat even when the legal theory does not.
Web archives and what a capture really is
Public web archives are the most cited and most misunderstood source in this field. An archive is not a mirror of the web. It is a collection of crawler snapshots, gathered on the crawler's schedule, subject to what the crawler was allowed and able to fetch.
The consequences matter in litigation:
- Absence proves nothing. No capture on a date does not mean the page did not exist. It usually means nothing crawled it.
- A displayed page can mix dates. The archive assembles a rendering from the closest available capture of each component, so the HTML may come from one date while an image, stylesheet or script comes from weeks away. A viewer sees one page and one timestamp.
- Dynamic content is frequently missing. Anything behind a login, a search form, a script call or a paywall generally was never captured.
- Exclusions can appear retroactively. Captures that existed can become unavailable through later exclusion requests or site directives, which means a capture seen last year may not be there when the other side looks.
- Rendering can leak live content. An archived page may pull a resource from the live web at viewing time, so what you see today is not entirely what was captured.
Used carefully, archives are excellent for establishing that content existed by a date. They are weak for establishing when content first appeared, and they cannot establish that something never existed.
Capturing pages so the capture survives challenge
A bare screenshot is the weakest form of web evidence in common use. It has no address, no clock, no response data, and it can be altered in a text editor by anyone with a browser's developer tools open. I treat a screenshot as an illustration of a finding, never as the finding itself.
What I collect instead, wherever the situation allows:
- The HTTP response - status code, headers, server dates, redirect chain - not only the rendered result.
- The raw HTML and referenced assets, saved as files, and where practical a web archive file that preserves the request and response together.
- A full-page image showing the complete address and the system clock, plus screen video of the navigation path for anything interactive.
- A cryptographic hash of each collected file, recorded at collection, so the version relied on can be identified later.
- A collection log: who collected, when, in which time zone, from what network, with which tool and version, and any configuration that affected what was returned.
That last item is not bureaucratic. Personalization, geolocation, logged-in state and consent settings change what a site returns, and a report that cannot describe the collection conditions cannot explain why the other side's capture differs.
Server logs, IP addresses and the limits of attribution
Server logs are the best web evidence most matters will ever get, because they are contemporaneous records generated by a system with no interest in the dispute. A line records the requesting address, the timestamp, the resource, the response status, the referring page and the client string.
Now the caveats, because they are where opinions overreach.
An address is not a person. Residential connections rotate. Carrier-grade address sharing puts many mobile subscribers behind one address simultaneously. Offices, schools and public networks aggregate everyone behind a gateway. Virtual private networks, proxies and privacy browsers exist and are ordinary. Modern address privacy features rotate identifiers by design. At best, an address places a network endpoint in a place at a time, and connecting that endpoint to an individual takes records held by someone else.
Client strings are trivially forged. A user agent is a self-description, and automated traffic frequently claims to be a browser or a search engine crawler. Verifying a claimed crawler requires a reverse lookup and confirmation against the operator's published ranges.
Clocks drift and time zones lie. Two systems that disagree by minutes will scramble a sequence, so I normalize everything to a single reference and document what was adjusted.
Logs expire. Rotation is often measured in days or weeks. This is the single most common way decisive evidence is lost before anyone thinks to ask for it.
What a forensic timeline can and cannot prove
A timeline is usually the deliverable that makes a technical matter comprehensible. Events from independent systems - registrar changes, DNS updates, deployment records, log entries, archived captures, message metadata, account activity - normalized to one time reference and placed in sequence.
Built properly, it establishes sequence and coincidence with real precision. It can show that a configuration change preceded an outage rather than followed it, that content existed before a claimed first-use date, that an account was accessed in the interval when a record changed, or that two events alleged to be connected were separated by weeks.
What it cannot do is supply intent or identity. A timeline shows that something happened and when. Who was at the keyboard, and why, are inferences drawn from surrounding evidence, and they belong to the fact-finder rather than to me. I keep that boundary visible in the document itself by marking each entry as observed or inferred and naming the source record for every line. An entry with no source is an assumption wearing a timestamp.
Chain of custody and reproducibility
Web evidence is uniquely easy to alter and uniquely hard to authenticate, which puts the weight on process. The practices that hold up are unglamorous: collect to write-once storage, hash at collection, analyze copies rather than originals, keep a contemporaneous log of every step, and be able to hand the opposing expert the same materials and instructions and have them arrive where I arrived.
Reproducibility is the discipline I would push hardest on any attorney evaluating an expert. If an analysis exists only as a spreadsheet somebody assembled by hand, its errors are invisible and its steps cannot be re-run. When the analysis is scripted against preserved raw exports, a challenge has to engage with the method rather than with the analyst, which is a much better position to defend.
The same principle governs what I put in a report: assumptions listed, data gaps stated, alternative explanations addressed rather than ignored. An opinion that has already met the strongest counterargument in writing is far harder to unsettle than one that meets it for the first time under questioning.
Working with counsel
Two things make the largest difference, and both happen early.
The first is preservation. Access logs rotate, analytics and hosting accounts lapse with vendor relationships, message retention policies run on their own timers, and a site under dispute is often rebuilt by a party who does not realize what they are erasing. A preservation demand that names specific systems - raw access logs, hosting control panel history, DNS and registrar records, deployment and CMS revision history, tag manager versions, account access logs - retrieves far more than a general instruction to keep documents.
The second is scoping the question. "Tell me what happened on this website" produces an expensive survey. A defined question - did this content exist before this date, did this configuration change cause this failure, is this capture consistent with what the server would have returned - produces an answer someone can use.
I take engagements on either side, and conflicts are cleared before I review substantive material. Retention runs through Hartzer Consulting; this site is my record rather than an intake form.