20 Aug When the Software Lies: The 2:27 A.M. Timestamp in the Karen Read Trial
In January 2022, Jennifer McCabe’s iPhone recorded a Google search for “hos long to die in cold.” The extraction report put a time next to it: 2:27 a.m. John O’Keefe’s body wasn’t found in the snow until after 6 a.m.
If that time were real, someone was searching how long a person survives in the cold hours before anyone was supposed to know he was out there. Karen Read’s defense leaned hard on that line.
I do defense work. My practice is built on finding what the prosecution’s digital evidence gets wrong. So it costs me something to say this: the 2:27 timestamp almost certainly didn’t mean what the defense said it meant. Why it didn’t is the most useful lesson in that entire trial for anyone who handles digital evidence.
What the report showed
The extraction listed the search at 2:27 a.m. Richard Green, a private examiner working for the defense, testified in the first trial that the search happened at or before 2:27, based on how that particular phone behaved and on comparing other data on it.
The prosecution disputed it from the start. Ian Whiffin, a product manager at Cellebrite, and forensic examiner Jessica Hyde both testified that the 2:27 time belonged to a different event entirely.
What the timestamp actually recorded
Whiffin recreated the conditions on test devices. His conclusion was that 2:27 marked when a Safari tab was brought into focus, not when the search was typed. Hyde placed the search itself at 6:24 a.m. A separate misspelled search, “how long ti die in cikd,” was logged at 6:23 a.m.
Here is the sequence in plain English, as the prosecution’s experts described it:
- Around 2:27 a.m., McCabe had tabs open for unrelated browsing. Whiffin pointed to pages about banking, YouTube and youth sports.
- Around 6:23 a.m., she reused one of those tabs for the cold-weather searches.
- Safari didn’t write that tab’s record until she closed it at 10:33 a.m. The saved record paired the tab’s original timestamp with the URL and title it held at closing.
- The forensic report read that one record and printed the newest search beside the oldest time.
Nothing was faked. Nothing was deleted; Whiffin testified the history database showed no missing records. The database did what Apple designed it to do. The report presented one record as if it described one moment, and people read it that way.
Why this matters beyond one trial
After a 2024 mistrial, Read was acquitted of murder and the other serious charges on June 18, 2025, and convicted only of operating under the influence. The 2:27 theory didn’t win that verdict. A lot of courtroom time went into defending a timestamp that two experts and a set of test devices said was wrong.
A bad timestamp doesn’t stay contained. When opposing counsel shows that your expert misread one artifact, the jury starts wondering what else got misread. Your strongest arguments then get weighed by people who just watched your digital evidence come apart.
The same mistake cuts the other way just as often. Police examiners run the same tools, read the same reports, and print the same kind of line with the same confidence. Every timestamp the prosecution or the Crown relies on deserves the questions below.
Five questions to ask about any timestamp in a report
- Which database and which field did it come from? “Safari history” isn’t an answer. On iOS, Safari keeps browsing history and open-tab state in separate databases, and they record different events.
- What event does that field record? Created, modified, last viewed, brought into focus and written to disk are five different moments. Most fields record exactly one of them.
- When was the record written? Some records are written the instant something happens. Others are written later, when an app closes or a tab shuts, and they can stitch together data from different times.
- Was the interpretation tested? Same operating system, same app version, test data, the way Whiffin tested it. If nobody tested it, it’s an assumption wearing a timestamp.
- Does anything else on the device agree? A real 2:27 a.m. search should leave other traces: network activity, a screen unlock, other app activity around it. A time nothing else corroborates is a lead to chase. It isn’t a finding.
The takeaway
The extraction report is a tool’s reading of the phone. The phone’s databases are the evidence. When a case turns on a time, somebody has to go below the report and confirm what that time records, before the other side does it in front of the jury.
If you’re holding an extraction report and your case leans on a timestamp, start with a TruthScan. It’s a flat-rate review that tells you whether that line means what everyone assumes it means.