Audit log ideas

Libraries Libpurple
,
1

It’s not uncommon for someone to change a setting (account, preference, etc) or something and then forget what it was or that they did it at all. To combat this, I want to add an audit log.

The audit log should be focused on libpurple and the user interface and no so much on the chat networks themselves. So tracking something like blocking a user would be outside of the scope if it is done at the protocol level. But if it was just a libpurple block (not yet implemented) then it should be logged.

Log items should consist of a timestamp, source, and the text of what happened. A source would be something like user, system, remote. user would be an action of the user, change a preference or something. system could be a network connectivity change, restoring enabled accounts at startup, etc. And remote would be something like a server side disconnect.

I would like this to cover at least the following items:

  • application startup/shutdown
  • accounts creation/deletion/setting changes/connected/disconnected
  • preference changes
  • plugin loading/unloading including failures
  • network connectivity changes
  • scheduled tasks run (maybe, not sure this is helpful but maybe)

There is also a list of questions:

  1. Should we allow disabling this feature? This is a privacy issue as someone might add a temporary account and not want others to know about it.
    1. if yes, is it build time or just a setting?
  2. Do we allow deletion/clearing items? I’m leaning towards no, an audit log like this feels like it should be append only.
  3. Should this be text only list?
    1. trying to make this “rich” would super complicate things, but would allow us to revert changes maybe?
  4. What kind of storage should we use, sqlite seems like overkill in the short term, but after years of use would make sense.
    1. Should we allow different storage backends?
2
  1. I would allow it to be disabled. Maybe this could be something that could be configured by the sysadmin.
  2. I would allow a “clear log” to clear the entire log but not individual entries.
  3. Yes, text-only. No real value in rich text for a log.
  4. No preference here, but I’m used to seeing logs as raw text.

Scheduled task execution should definitely be logged too.

3 Likes
3

If we allow disabling and clearing,then pausing seems pretty reasonable to? Or maybe that’s just disabling.. Which asks the question, does disabling clear existing or just not add new ones?

4

To me pausing and disabling are the same thing, because you would unpause eventually, which is the same as enabling.

I would interpret disabling as just preventing adding new entries.

5

got it. So disable is effectively pause, and if you want to clear when disabling, then clear manually.

1 Like
6

I’ve been finding duckdb on top of a pile of text gives sql like tooling without the fixed schema hassle or db overhead.

So if ya dump out structured something, append jsonl seems popular today, or csv, and “Robert is your fathers brother?” :hugs:

1 Like
7

This as a simple schema with three fields and is documented above.

Adding an additional format that isn’t already available is not something we want to do. We already depends on libraries for SQLite and JSON, and have an XML parser built into glib.

But maybe SQLite is the answer here as we can then just SELECT * FROM audit_log ORDER BY timestamp DESC; and be done.

1 Like
8

I might be misunderstanding things, but this feature sounds to me a lot like running pidgin -d 2>&1 >> ~/.purple/pidgin.log today. One major addition is the logging of changes to the preferences. I have a rather bad feeling about it due to privacy concerns. If I delete an account, I want it gone. Will credentials be stored, too? If I change a password, I want to have no record of the previous one.

My stance for point 1. is “have it as a setting (default off)” and no strong opinion on the other points.

For the immediate future, the usual ephemeral log to standard output looks sufficient to me. :slight_smile:

9

The debug logging is completely separate. This is to track changes made to the configuration of the client across runs of the program. The debug log is whatever someone decided to log and is fire and forgot and lost forever.

For privacy concerns we’re going to add the ability to disable this entirely.

Credentials are stored in a separate system, PurpleCredentialManager, we would not track passwords changing there as there is no means to do so and it would be silly to do. Most password manager tell you the last time it was modified and keep a history already.

We’re not defaulting it to off. One of the key reasons for this feature is to help users who go “i just changed a setting that broke everything and i can’t find it again”. Helping them is a huge time sink that this brings down to basically nothing. “Check tools → audit log” and we’re done.

Again the debug log is something completely different.