It would be a good idea to put the legal documents in a version control system. Then all the revisions can be tracked.
It's time to adopt the ideas we've learned in CS to other professions.
It's time to adopt the ideas we've learned in CS to other professions.
Whoever solves that problem will be a very wealthy individual, but, like many organizational people-problems, it may be intractable from a technology perspective.
Qualifications like these are highly, highly problematic when you don't actually enumerate what they are.
From what I know, the content management sector has a problem of being too generic, trying to handle any form of content, including digital media content, which has very different requirement than documents. Version management is low in the requirement list. Also indexing and searching are a big part of the requirements, which lead to the emphasis on OCR and different format conversion. Archiving and document retention are pretty big with emphasis on the compliance with the various laws. This leads to bloated products that the customers find hard to use and hard to fit into their process and workflow.
I heard of effort by law firms trying to implement content management systems but couldn't because of diverging requirement. At the end just threw the printed PDF into the system and called it for the day.
I heard of contract version management system, just to track the changes to the text of a contract, which was pretty successful because of focused effort. Contract can have numerous versions during negotiation and small changes can have huge impact.
What we need is a system with a small well defined feature set focusing only on the version control of text documents. Outsource the format conversion, OCR, index and search work to other systems.
As that tool is successful, people will start thinking, "I sure wish I could do that with my [Word docs, Photoshop files, video files, etc]," and they start looking. Then they find Content Management and think they've found the perfect solution (and it really does sound good on paper).
But there are three fundamental problems: Unlike the contract management system, you generally don't use the CMS to create or edit documents[1], so you always have a point of impedance between the authoring and the management. Now you are relying on people to "do the right thing", and the right thing isn't the easiest thing.
The next problem is managing versions of the documents gets ugly and confusing pretty quickly. Most file formats we use today don't diff well, so the benefits of e.g. seeing just the changes from v2 to v3 are hard-to-impossible to implement.
The final problem is the content lifecycle of most documents is very fluid. Whereas a contract has a well-known lifecycle with a point in time that it is DONE (e.g. the contract is signed) and a well-known set of approvers (companies generally understand their money-spending approval process well), most documents people interact with follow very ad hoc processes. Invariable, people try to build formal processes out of those ad hoc processes, and people get frustrated. Given the first problem (authoring outside of management), people can easily make an end-run around the tool, perhaps putting a document into it only when they absolutely have to.
Anyway, I could go on for a long time, but my take-away from my experience in content management is to solve small, well-defined problems and forget about the siren's call of "all our documents managed in bliss" because it won't happen.
1. Like contract management, web content management tends to be more successful, because the authoring environment is usually the management environment.
When nailing down an RFP proposal, for example, the technology is the easy part. Distributed ownership of documents, or people changing the wrong version is the hard part. (And drives me nuts!)
But, decisions are fixed entities, a decision is made by the court and handed down, stat. The decision doesn't change, a court can sit again and make a new decision (eg rescinding or amending the former decision) but the former decision still stands, as is, as the decision that was made.
If post-facto amendments aren't substantive then they're unnecessary, if they are substantive then they shouldn't be made without the court sitting and issuing a further decision. Seems logically that amendments should never be made; clarifications might be issued later but the decision as handed down to the parties in the proceedings should stand unaltered.
We'll get court opinions stored in version control when we get a generation of judges that grew up with word processors with integrated version control. As it stands, version control isn't even well-implemented in mainstream word processors.
Maybe we should be teaching version control first when we introduce students to word processing. If they know they can always go back to an earlier version and compare changes, they might be more willing to explore and learn faster.
> Even within the tech industry, tooling moves at a glacial pace.
Oh the irony...
That would be proof positive to me that they have no intention of leaving the documents unchanged. MD5 has been unusable as tamper-proof signature for a long time now.
In the use case where you want to change the document for your own purposes without leaving evidence that you've tampered with it, you would not be searching for just a single other file which generates the same hash value. You would be looking for another file which results in the same value when hashed, has the same format (text is easy, I suppose, but it's conceivable they could switch to a binary format at some point), makes grammatical and syntactical sense, and also contains the desired content that you are looking for (or some approximate.. the 'exact' desired content would result in a different hash in most scenarios).
That said, I agree that there are better hashing algorithms out there. Multiple signatures from several common hash functions could be provided for quick confirmation purposes while still making it relatively easy to validate quickly.
(Edit: Also, since you are concerned: I am not the downvoter)
http://cryptography.hyperlink.cz/MD5_collisions.html
A collision in under a minute would seem to me to qualify as 'broken' for all practical purposes of this particular has function for the purpose of proving a document was not modified after it was signed.
That that minute is still a substantial number of cycles is not too relevant given the importance of the documents that are being modified, it counts as a 'non-expense'.
Once this is done, you can explicitly blacklist the offending chain and get on with life.
(For anyone who isn't familiar with the reference, here's a primer: https://plus.google.com/+YonatanZunger/posts/ZZ9wDbLDr3A )