Well I was thinking that the timing—basically Google or apple got the document within a short time after signing—is evidence it wasn’t tampered with, or if it was, one of the parties was already intending fraud from the start.
Like say party A never uploads, and during discovery in a lawsuit 2 years later they present 1 version, while party Bs phone said it was taken with the camera (fakeable but requires a rooted phone) and has a different version. Nothing definitive distinguishes the 2 documents at a pixel level. (Because if there was a way to tell, the AI critic during the fabrication process for 1 or both documents would have noticed....)
So then B is more likely to be telling the truth and A should get sanctioned.
I have brought in another element here : trusted hardware chains. You need trusted hardware, with trusted software running on it, uploading the information at around the time an event happened.
If A’s device scanned and hashed the document, and produced a signature stamp unique to that document, then B couldn’t just copy A’s signature onto a different document. The stamp and document wouldn’t match.
If B has a document that has a signature which only A could have produced and which matches the semantic content of the document, then A can’t claim to not have signed the document. The signature is proof that A agreed to the terms as written. B couldn’t be faking it. Even if A tampered with their own record to erase the signing-event, it would still be provable that only someone with A’s private key could have produced the stamp and that the stamp matches the hash of the disputed document.
Oh, and the stamp should include a UTC datetime as part of the hash. In case A’s private key later gets compromised, B can’t then use the compromised private key to fake A having signed something in the past.
Seems legit. Note that hash functions are usually sensitive to 1 bit of error. Meaning if you optically scan every character, if 2 different devices map a letter to even a different font size there will be differences in a hash. (Unless you convert down to ASCII but even that can miss a character from ocr errors etc. Or interpreting white space as spaces vs tabs..)
Well I was thinking that the timing—basically Google or apple got the document within a short time after signing—is evidence it wasn’t tampered with, or if it was, one of the parties was already intending fraud from the start.
Like say party A never uploads, and during discovery in a lawsuit 2 years later they present 1 version, while party Bs phone said it was taken with the camera (fakeable but requires a rooted phone) and has a different version. Nothing definitive distinguishes the 2 documents at a pixel level. (Because if there was a way to tell, the AI critic during the fabrication process for 1 or both documents would have noticed....)
So then B is more likely to be telling the truth and A should get sanctioned.
I have brought in another element here : trusted hardware chains. You need trusted hardware, with trusted software running on it, uploading the information at around the time an event happened.
If A’s device scanned and hashed the document, and produced a signature stamp unique to that document, then B couldn’t just copy A’s signature onto a different document. The stamp and document wouldn’t match. If B has a document that has a signature which only A could have produced and which matches the semantic content of the document, then A can’t claim to not have signed the document. The signature is proof that A agreed to the terms as written. B couldn’t be faking it. Even if A tampered with their own record to erase the signing-event, it would still be provable that only someone with A’s private key could have produced the stamp and that the stamp matches the hash of the disputed document. Oh, and the stamp should include a UTC datetime as part of the hash. In case A’s private key later gets compromised, B can’t then use the compromised private key to fake A having signed something in the past.
Seems legit. Note that hash functions are usually sensitive to 1 bit of error. Meaning if you optically scan every character, if 2 different devices map a letter to even a different font size there will be differences in a hash. (Unless you convert down to ASCII but even that can miss a character from ocr errors etc. Or interpreting white space as spaces vs tabs..)
Yeah, you’d need to also save a clear-text record in your personal ‘signed documents’ repository, which you could refer to, in case of such glitches.