Our last video showed how gun uses timestamps to figure out the correct order of updates. In our concert app, we needed to establish a timeline of updates (and in the correct order), otherwise we might end up saving the wrong data. In our case, it was the agreements between us and our concert sponsors.
When an update is created, the computer attaches it’s timestamp, which is then used by the database to determine if your update is more recent than what it already has. However, this opens a vulnerability. There’s an employee at your sponsor’s company who really hates concerts, and he’s trying to sabotage the agreement. Knowing gun uses timestamps, he cleverly sets his own clock two years into the future and submits his devious update.
With such a high timestamp, it’ll be considered the most recent data for the next two years, ignoring all other writes. It’s obviously malicious, so how do we safely ignore it? That’s where deferred updates come in. Since the data claims to be from the future (relative to our own machine), we wait until our system clock reaches that timestamp before even acknowledging its existence.
While the concert-hating attacker is left waiting for his update to be recognized, others reading from the database will still see the old agreements, and if anything happens to the database process, the malicious update will be lost from memory, needing to be re-sent by a peer that trusts it.
