Clocks are not trustworthy

[alanhkarp]

Timestamps are used in the last write wins commit strategy, but timestamps are unreliable. Clocks on computers exhibit strange behavior, sometimes jumping forward or even backward. A malicious party can set the timestamp to an arbitrary value. Therefore, a timestamp should only be accepted if it comes from a trusted party or if it was signed by one.

[csuwildcat]

@alanhkarp there are no wall clock timestamps used in the spec to determine logical ordering of any kind, there is a clock property that represents a simple incrementing integer/global vector. Additionally, data is only allowed to be written in based on permissions the user allows, so random attackers have no ability to just overwrite this clock value. If Alice permissions an app to write and they overwrite an object with a greater vector value, then that's simply a poorly coded app that she should not use.

[csuwildcat]

Here is the definition of the clock param: The object MUST contain a clock property, and its value MUST be an integer representing an incrementing logical counter. - it's not a timestamp, and the processing instructions do not rely on any concept of relativistic time: https://identity.foundation/identity-hub/spec/#processing-instructions

[alanhkarp]

My bad. The document specifies that the datePublished "MUST be an Unix epoch timestamp". However, I was wrong, since those time stamps are not used in the commit decision. Can an incorrect datePublished cause problems?

Insider attacks are common. A user with a legitimate permission to update an object may choose a large clock value to guarantee the user's update will be considered the last writer, blocking updates from other users. Also, is there a need to provide for clock values wrapping?

[andorsk]

Discussed at DIF:

@alanhkarp : There is no hard anchoring on clock timestamps in the spec.. Given this perspective in DIF, are you OK with us closing this out? Adding motion to close tag.

[alanhkarp]

Was my question "Can an incorrect datePublished cause problems?" answered in the documentation?

Was my question "Also, is there a need to provide for clock values wrapping?" answered in the documentation?

Even though the timestamps used for commit order decisions aren't clock values, there is a question of whether they can be manipulated. If they can, you either need to mitigate the problem or explain any impacts. The other choice is to rely on consensus of arrival order.

[andorsk]

Discussed on DIF:

Lost where the language is on this. We should repoint this issue to the updated commit strategy language.