This is an idea I had a while ago that I wrote up on Slashdot but can't find any more. The idea is to implement a document distribution system which allows the author to send a key of some type out to the intended recipients. This key contains the information required to access the document. However, the initial setup by the author allows certain restrictions to be placed, such as editing and printing. The end user has an authentication key of some type that proves they are who they say they are. The initial author of the document can specify who can do what with the document. Examples of permissions that can be granted on a user-by-user bases are:
- Reading (i.e. whether they get sent the document at all)
- Writing (i.e. can they put changes back into the server)
- Permissioning (i.e. altering these permissions)
- Saving (can the document be saved locally?)
- Printing (can the document be printed?)
It is important to keep in mind that the first three are server-controlled permissions. They can be guaranteed to be enforced, whereas the latter two are client-side, and so really can only be relied on to reduce the chance of this happening accidentally. The authentication/authorisation will use a public/private key system.
An additional feature of this is that it enables documents to expire after a certain date.
This could be done with a simple client-server mechanism. The key is given to the viewer (e.g. OpenOffice), OpenOffice looks at the key, works out from it what server to ask and the ID of the document, connects to the server, and asks for the document. The server may ask for authentication, and if OpenOffice provides it correctly, the document is returned, with flags specifying the client-side security attributes. A similar process is used if the user attempts to update the document on the server.
This demonstrates the process the client goes through in requesting a document:
- Receives the key, extracts the server (S) info and the document ID (ID).
- Connects to S, and passes it ID.
- S then asks for authentication, and includes a string K.
- The client encrypts K with it's secret key and sends that to the server.
- The server replies with the document, which is presented to the person by the client software.
From the servers point of view, this is what is happening:
- Receives a connection from a client asking for document ID.
- Checks to see if ID exists, and checks it's permissions.
- Generates a random string, K, and passes that to the client.
- Receives the encrypted K response from the client, and decrypts it. The key that it uses to decrypt it tells it who the user is.
- If that user is legitimately allowed to access the document, the server sends it on.
This type of system could be used to distribute potentially sensitive documents within an organisation. The saving and printing restrictions prevent accidental disclosure, and the authorisation system prevents people seeing it who shouldn't. As the document is stored on a central server, people are always confident of having the latest version. If someone with authority to do so saves changes to the server, then everyone requesting the document after that gets those changes. A facility could be included to allow the client to periodically check for updated versions. If a particular document becomes useless after a certain point in time, or it is sensitive enough that people should have even more restricted access to it, the server can be told to change the permissions on it after a certain point in time. The reverse could be useful: if a document is going to be useful, it can be worked on by a small group of people until the time it is supposed to be released, at which point the permissions are changed to make it open to all.
Some other ideas that could be used in conjunction with this:
- A local server: this is a program that sits on the local machine and caches credentials and (perhaps) documents. This makes it faster and less intrusive for the end user to request documents.
- Save-over alerts: if user A downloads the document and starts editing it, user B downloads and starts editing, user B uploads, then user A uploads, user B's changes are lost. It would be useful to implement a system that determined when user A's version was downloaded, and if a change has happened in the meantime, alerts user A to this fact, allowing them to do something about it.
- Merging: this is an application specific thing, and attempts to be a nicer solution to the simultaneous edit problem above. If the file format is something that is open (such as text, or that of OpenOffice) and amenable to this (MS Word, and most graphics wouldn't be) the changes are merged if possible. This would likely be done with format plugins on the server that allow it to understand the file format and work with it.