情景 – 嫌疑人攜帶一部僅使用 Wi-Fi 連線的 iPhone，該 iPhone 並無電信業者的上網服務。訊息正在從不同的同夥發送到嫌疑人的 iPhone 上。當 Wi-Fi 最終連接並接收到訊息時，這些訊息會顯示什麼時間點的時間戳？它們會保留發送時的時間嗎？還是顯示 Wi-Fi 連接時的當下接收時間？
一般認知
如您所知，大多數資料庫資料表會使用主鍵（Primary Key – 即每筆紀錄中唯一的值）來幫助定位和索引記錄等。大多數的資料表（Tables）還會使用「自動遞增 – Auto Increment」功能，每次新增一比記錄時，主鍵會自動加一。當前最大的主鍵數字通常存儲在另一個單獨的資料表中。
這方式對鑑識人員非常有幫助，可快速查看資料庫並立即知道任一資料表中應該有多少筆記錄。
它還可以幫助鑑識人員識別記錄是否已被刪除。例如，如果主鍵記錄 100 和 102 存在，那麼記錄 101 必然在某個時間點存在過；由於它已消失，101 一定是被刪除。
進一步說明，透過查看主鍵記錄 100 和 102 的日期和時間，可以推測記錄 101 必須發生在這兩個時間之間。這有道理吧？
那麼，掌握了這些資訊，可以從以下資料表中確定什麼？
圖一、已刪除紀錄的資料表
您可以馬上看到 ID 3 和 5 的紀錄，但 ID 4 記錄不存在。
您知道因為 ID 5 存在，ID 4 該筆記錄必定在某個時候存在過，並且它必定已被刪除。
我們還可以推測，由於 ID 4 的紀錄位於 ID 3 和 ID 5 之間，那麼 ID 4 的「時間戳」必定在 06:23:11 和 06:23:28 之間。
您同意嗎？
謬誤
讓我們看一下 ID 4 紀錄刪除前的資料表。
圖二、未刪除紀錄的資料表
從上方可得知，ID 4 該筆資料的時間晚於 ID 5，並非同我們一般認知，紀錄與紀錄間的主鍵與時間戳排序是有順序的。
- ID 3/Test Message 3: 06:23:11。
- ID 4/Test Message 5: 06:39:18。
- ID 5/Test Message 4: 06:23:38。
讓我們來分析這個順序異常是怎麼發生的。
線索
實際操作過程
06:21:26 – ID 1 – Test Message 1：從裝置 1（嫌疑人裝置）發送到裝置 2。
06:22:32 – ID 2 -Test Message 2：從裝置 2 發送到裝置 1。
06:22:50 – 裝置 1 進入飛行模式。
06:23:11 – ID 3 -Test Message 3：從裝置 1 發送到裝置 2，實際尚未發送。
06:23:28 – ID 5 – Test Message 4：從裝置 2 發送到裝置 1，裝置 1 尚未收到。
06:39:11 – ID 4 – Test Message 5：從裝置 1 發送到裝置 2，實際尚未發送。
06:42:00 – 裝置 1 退出飛行模式。
06:42:01 – ID 5 – Test Message 4 訊息送達。
06:42:03 – ID 3 – Test Message 3 發送失敗。
06:42:04 – ID 4 – Test Message 5 發送完成。
ID 4 的 Test Message 5 在這之後被刪除。
所以您可以看到，早些時候在對話中發送的訊息，被保存在 cloud 中，直到其他訊息已經被保存後才被傳送。
總結
這並不是唯一會導致這種差異的情況。一個 iCloud 帳號同步多個裝置時，僅僅是信號不佳也可能會引發類似的問題。
即便如此，這通常不會是問題，假設「被刪除記錄」的日期/時間通常不會偏離實際時間太遠。然而，除非有其他形式的佐證資料（例如通知、第三方設備或電信提供商的記錄），否則這肯定會影響「被刪除記錄」的時間戳重視程度。
