Post in Audit Trails

As this topic has arisen in another (closed) group, so I thought I would open
the topic of audit trails here.

An audit trail is what it sounds like: a record of all the changes to a system.
It is used during an audit: security audit, activity audit, or simply activity
reporting. Besides being a good idea, audit trails are also required by many
government standards
http://www.archives.govt.nz/continuum/documents/publications/s5/s5-controls.php#2
(while I am using an New Zealand document as an example, it is based on
international standards).

In GroupServer, I am intending audit trails to be used as the core of many
things. Keeping a record of what has changed with a user's profile should also
allow the user to undo changes. Keeping a record of the changing membership of
a group would allow us to record how many people received messages in a
particular month. Keeping a record of who accessed what can be used during a
security investigation. Knowing who changed what will allow better support of
users who have problems with their accounts.

The way I am intending to implement audit trails is to implement the command
pattern
  http://www.dofactory.com/Patterns/PatternCommand.aspx
(I preferred the above to the Wikipedia page). Effectively, the audit-table of
the GroupServer relational database will contain little snippets of XML that
can be used to undo, or redo, particular actions. It is not necessary to
implement audit trails in the way I propose, but the command-pattern will give
us the most utility from the auditing system.

As I said previously
  http://groupserver.org/r/post/7i4zzvM94cHbk42y6xeDUw
modifying a post, or another user's profile (by a group administrator, for
example) relies on the audit-trail system before it can be implemented
ethically (or legally, in most of the developed world). Neither editing task
needs one, technically; I promise to actively hinder all efforts to implement
post-editing, or profile-editing, by an administrators without audit trails.
*The*  *user*  *must*  *know*  who altered his or her profile or posts. Any
other situation is reprehensible.

The biggest problem for the audit-trail system is that it is not small. Large
does not even cover it: every part of GroupServer will eventually be hooked
into the auditing system. Extensive interfaces are needed to give people access
to the audit logs associated with themselves, and the parts of GroupServer that
they manage. The size of the task daunts me, but I know that many important
user-tasks rely on audit trails being present…