[RaptorJ]

I'm not sure if this is what they do, but it seems like a solution would be the git commit hashing procedure. So at the end of a day/worksession have the app take the hash of ( what you entered today + yesterday's hash) so you create a provable trail of changes.

[michaelmior]

I'm not sure I see why hashing is necessary nor why it provides any "proof" of what was changed. Perhaps it's the git analogy that's tripping me up because you can easily forge commits to appear as being from any user at any time.

[charles_parnot]

The problem evoked here is for your institution at which you work, to know that their researchers are not changing the data afterwards and following best practices. In this scheme, the user would submit the hashes to a central server controlled by the institution. Then, the user have no way of changing the content without them knowing.

And yes, you would need to add some authentication to know it's always the same user, but that's a different, orthogonal issue.

For actual proof e.g. in court, you'd need a third party with a private key used to sign the content. A little more involved... But the main point of that would be patent litigation, and with the new 'first to file' rule in the US, it is much less relevant.

[michaelmior]

If you have a trusted third party that can hold content for you, why not just have them store the actual data? Unless of course it's very large, but that seems unlikely to be the case in this scenario.

[charles_parnot]

You could actually have quite a lot of data generated in a lab, depending on what you do. By only storing the signatures, you can have a much cheaper service that what would be needed to store GB of data, and really focus on other aspects that are critical for this: security, backup, user interface, speed,... Having only to worry about backup of a bunch of signatures is a much easier task than having to worry about backing up the actual data.

[charles_parnot]

Good idea, and no, we don't have anything like that at the moment.