Privacy and Logs
Discussion of the ways to manage the system logs and other potential privacy problems.
By: Brian Jones (aka Otter)
Part of the Management Series.
Introduction
A MU is a social system. The people within it interact with others. Some interaction is clearly exposed to everyone, such as say and pose within public rooms. Other interactions are done with the intent that the audience be limited, such as with whisper or page. Some interactions are even meant to be totally private for just one other.
These expectations can be breached in a variety of ways. The system logs often track everything entered into the game and people often publish their own transcripts from their clients. In both cases something not meant for public consumption can be exposed to others.
So, the challenge for the management team is: What should the policies be in regards to privacy within the game?
The Nature of the Beast
First, what precisely is in the system log files?
A lot of players hear about the system logs but really haven't seen them. Here is an example of a section of the system logs of Nameless (showing only MY actions so as not to expose anyone else):
01/05/07 17:16:53: WIZ: Otter(181) in Otter's Pond(14847): where 01/05/07 17:16:58: WIZ: Otter(181) in Otter's Pond(14847): "This is a public say 01/05/07 17:17:03: WIZ: Otter(181) in Otter's Pond(14847): :makes a public pose 01/05/07 17:17:06: WIZ: Otter(181) in Otter's Pond(14847): p otter=This is a private page 01/05/07 17:17:11: WIZ: Otter(181) in Otter's Pond(14847): p =This is a private page response 01/05/07 17:17:18: WIZ: Otter(181) in Otter's Pond(14847): w otter=This is what whisper looks like 01/05/07 17:17:23: WIZ: Otter(181) in Otter's Pond(14847): l 01/05/07 17:17:25: WIZ: Otter(181) in Otter's Pond(14847): where 01/05/07 17:17:29: WIZ: Otter(181) in Otter's Pond(14847): +ci #host 01/05/07 17:17:36: WIZ: Otter(181) in Otter's Pond(14847): @rec #33323234 01/05/07 17:17:44: WIZ: Otter(181) in Otter's Pond(14847): gohome 01/05/07 17:16:47: ACCEPT: 127.0.0.1(57314) on descriptor 8 01/05/07 17:16:47: CONCOUNT: There are now 1 open connections. 01/05/07 17:16:47: CONNECTED: Otter(181) on descriptor 8 01/05/07 17:17:45: DISCONNECT: descriptor 8 player Otter(181) from localhost(brianj)
I have two sections because the top comes from commands and the bottom from status. Some MUs only have a single log file depending on their server configuration. But the idea is the same.
The logs are clearly not fit for human consumption. In fact, they are built to be easy to parse by UNIX tools such as sed and awk.
That said, the logs tend to show exactly what was typed. For instance, I sent a page to myself and then responded with p =. Notice that unless you found who paged to me first (hard in a busy log) the log doesn't really show you who I paged directly. So, the logs do require examination, not just simple reading.
I did an @rec of some object (the number is huge because I didn't want to delete a real object). Now, if that had been a real #id, the logs didn't show what it was that I destroyed or how to get it back. That sort of information would be in database backups.
The log shows the commands, but I could have made my own gohome command that did {force:*admin,@toad someone}. So, just because you see text in a log it doesn't
necessarily mean what you think it means. You have to read the logs a LONG way back (or check the live database and all the logs from that point) to verify the integrity of the commands named.
In short, the logs expose everything in the raw and require a lot of experience to really use when evaluating a potential issue.
Some Simple Log Uses
That logs require experience is true, but not everything is hard to evaluate.
One of the most common uses of the logs I've had as a developer of MU software is to track crashes. For that, I look at the last line or two of the log. If @set #-1=x:x was the last line, and I enter that in a test MU and it dies, then I've found my crash cause. I can fix the C++ source code.
One of the most common uses of the logs I've had as a wizard was to resolve the truth or falsity of player-provided transcripts in complaints. I'll discuss that in detail in the next section.
When items "suddenly go missing" a quick scan of the logs for @rec statements
against the item's #id is often revealing: wizards make typing errors and delete wrong things when building. I am guilty of this all too often myself. Once to the point of having to go to a backup and rebuild something substantial. I have great sympathy for those sorts of mistakes. Apologize, restore, no crisis need result.
Often when new software gets put into play it has, well, interesting un-intended effects. If it deletes things, the logs won't show it. The logs only show what the players type, not what the command does. This is why programmers should test their work on non-live "testing" MUs before testing in a live game. The logs are of limited use in this issue.
Logs are often used to identify alts. I'm not going to go into a dissertation on alt-tracking through IP and proxy matching, but any good programmer can easily find alts even through proxy systems and the like. The data is in the connection IDs and status log area.
Statistical analysis is often a useful measuring tool that the logs can easily support. For instance, how many guests/day on average do you have connect and not make a character? That's traceable through the status log by finding connections of your guest login name (often "guest" or "male" and "female" on NMC MUs) and noting the #id. Then, on disconnect of that #id, checking to see if the name has changed. This doesn't work if the system makes a NEW character (though then you track @pcreate vs. guest disconnects).
Note that no personal data is actually reported in such an analysis. Since nothing personal (not even an IP address) is reported, this is normally not considered a breach of privacy.
You can do more invasive studies, such as "amount of IC bytes used in poses/says/spoofs" per character over the last day/month/whatever. That could give you a list of the IC-est people. Publishing that list (or giving rewards based on it) could in fact expose people to attention they didn't want. Such a policy or intent should be documented to your players!
On the other hand, doing an invasive study and using the results as a means to formulate policy, and not publishing the data, seems reasonable to me. It may not seem reasonable to you, however, in which case you wouldn't do it!
So, for some things, a quick scan of the logs can be very useful without causing grief on the part of players. For this reason, strict "We refuse to check the logs" policies (or even not logging) may limit the management team's ability to actually run the MUCK better without violating privacy.
It must be known to players that there is no secrecy regardless. The software doesn't encrypt (in most cases anyway!) and the logs likely do exist.
Using the Logs to Settle Player Disputes
Imagine this: two popular players each complain to management about the other. Both provide transcripts (perhaps cut/paste or from client logging). The transcripts do not agree with each other!
If the players each provide transcripts that agree you don't need to check the system logs. This is the most common case. This is also the case when one transcript is provided and both agree with it. This is now an issue purely for interpretation of the rules and policies and I'll speak no more of it here.
There's a problem when a transcript or transcripts is provided and challenged. "That's not what I said! It's fake!"
The naive approach to this is to ask for witnesses. The reason this is naive is that people have bad memories (as is shown in case after case in RL experiments with eye-witness testimony) and even if two people claim something they could be colluding.
The simple approach: pull the system log for just the lines that the transcript covers.
Since this is a case of "He said/She said" about the validity of the evidence provided itself, there shouldn't need to be any research beyond finding the exact line in the log. That answers two things: is the transcript legal and who is lying?
I often say, "If you wish to pursue this complaint, I will pull the system logs and use them to find exactly what happened. Do you still wish to pursue?" Most of the time, the person decides it's not serious enough and backs down. Care to guess how the real logs would have agreed with the transcript provided?
The logs can't tell you if someone broke a rule; they can only tell you what was typed. It takes a human to evaluate what was typed to determine if it was a breach or not. So, while the logs are good for objective tests like validating transcripts, they don't "solve" problems on their own.
How to Abuse the Logs
If you have the pleasure (or misfortune) of being a MU host, here's a thing to watch for in the system process list:
8789 pts/4 R 0:00 tail -f commands
That means that someone is watching the logs scroll by in real-time. In other words, everything every player types is shown immediately to the person running the command. Obviously, such a listing is only available to someone with login access to the MU host machine. Someone with such access knows how to run ps and get the report I showed. If you do this, and see the site admin running this, it means your admin is spying!
Most examples of log abuse are when people go into the logs seeking to find "the truth" without a cause to go looking. For instance, insecure Chiefs will watch the logs to "be sure" that the players are playing properly. Or a paranoid Chief will go into the logs looking for "proof" to back his suspicions.
What distinguishes log abuse from reasonable use is the intent. Determining the truth of a claim so existing policy can be enforced justly is (at least in my eyes) reasonable and necessary to maintain the integrity of the game for both staff and players. Going "looking for trouble" is basically the equivalent of global phone-tapping and random search without warrant. It may be legal (the logs are, after all, the property of the account holder) but it's certainly not considered reasonable by the players!
A basic rule of thumb is this: if you don't want the players to know then it's probably abusive. Most wizards don't tell the players, "Oh, I read the logs all the time to keep an eye on you!" So, their desire to do so must be "kept secret." Secrecy tends to be abusive in nature. Not always, but often enough that a desire for secrecy causes warning bells to go off for me.
Logs and the Law
For better or worse, system logs (and the DB itself) are subject to subpoena by law enforcement if they have reason (such as a pedophile sting operation). It is very wise to either destroy the logs rapidly or to archive them honestly.
If a subpoena is presented and you can immediately give them the archived logs of the period of interest you won't be considered in contempt. On the other hand, if the system doesn't save logs or they are routinely purged, you aren't in contempt because they don't exist.
If you attempt to filter the logs, alter them, or delete them on receipt of the subpoena, you are going to be in serious legal jeopardy. Also, worse, your backups might be requested and they will discover that you lied and/or made changes. That's absolutely not what you want.
As a simple example: my logs are archived offline. There may be some days missing because of a random crash or something, but I've got them going back years. I do this so that I can show due diligence and assist an investigation if my system is in fact abused. Don't look upon law enforcement as the enemy here! If you have a criminal using your system, those logs may help the police catch the bad guy!
For this reason, I encourage you to store and preserve the integrity of your logs. Doing so will also help remind you that if you break your own policies and those logs are fetched you will be caught. It helps keep the honest among us honest.
When it's known that you store logs honestly, it also has the side-effect of reducing false claims because those logs hang over all liars like the Sword of Damocles.
Disclaimer: I'm not a lawyer. My advice is based on the simple basis that honesty and integrity are the best defense. No secrets, no risks.
Publishing Log Data
I have published logs. I repeat this: I have published logs.
I do so when an issue is so divisive to the players that the truth must be clearly shown. I've done it seldom and it has usually resulted in more hurt feelings than benefits. But, since what I post matches the transcripts (I'm honest) it does usually clearly indicate just what happened and lets us move forward.
In general, I recommend against publishing anything that is destructive to someone. If you have proof (validated by logs or by agreed transcripts) that someone broke a rule and needs to be removed, then by all means remove them. But, to publish that proof can lead to a lot of hurt feelings.
My normal way to answer questions about someone removed is "I am not willing to discuss the issue."
Most published "logs" are really transcripts. Those are generally from client capture and so the policies of the game really don't apply to them. That said, most of the published logs are published to share in-game role-plays and all are happy about it!
Anytime a transcript or log is published, it's a courtesy to remove from it private things. For instance, pages are normally chopped from published RP transcripts. This is especially important if the publisher is a wizard!! Wizards often see IP addresses and other data that can expose the real identity of a player. That information must be cleaned from what is posted!
Wizards: use a non-wizard alt to quietly sit and log big events. Use a zombie and strip the zombie prefixes. Use anything but your W-flag character that might let a page or output slip through that exposes a player's personal identifying information!
When players get into fights with each other (players, not characters) and publish logs disparaging of the other, there's really nothing in-game that can be done. It might be policy to consider the players "too annoying" to let continue as players, but the wizards seldom have the means to remove the offending messages because they're posted on blogs and other means outside the wizards' control.
Even when the offending messages are posted on places the wizards do have access to (such as message boards) it often causes really bad feelings if messages are stricken by authorities. People scream "Censorship!" (which it isn't, it's not the government) and bad feelings result. That said, if the wizard is responsible for the content (such as if they own the host it's on) they might choose to remove for legal liability reasons.
When players go to war on the blog, wise wizards stay out of it!
In-game privacy and Personal Identity of Players
The transcript issue touches on a much broader issue. Within the MU, wizards have the means to see a great deal of personal data, such as email addresses, connection IP addresses, etc. Most players expect these things to be handled "professionally". Normally, they expect that what they provide the system is protected. Many systems have real privacy policies specifically about this data because of the litigious nature of privacy and breach these days.
I'm not worried in this section about the legal side, but about the integrity side.
As a wizard, I know your IP address. You may try to be clever and use proxies and what-not, but if I push (using the logs, and other tools of my trade) I can likely track you to a real name, address, phone number, etc. There is no real privacy anytime you connect to an online system unless you are truly skilled and actively concealing your identity. Even [1] had a security geek break some protection and link people to messages.
I'm not the only wizard who can do this, and law enforcement can always do it. So, while there is a general expectation of privacy in-game, don't expect anonymity or secrecy!
Now, that also means that wizards (and many staffers) also "see" alts immediately.
It's considered rude (and you may want to put in your policies forbidden) to expose alts to others. For instance, because I can see that Player-A and Player-B are the same, if someone asks me, "Hey, is Player-A an alt o Player-B?" I would answer, "I don't expose private information."
Of course, if a staffer doing their job has an issue and needs to know, I get involved and MAY answer them. But, notice the logic: I use my extra system access only to enforce the MU policies.
Wizards, you can easily violate privacy. You can put dark listeners in player's rooms. You can cause all messages to a player to be echoed to you. Be sure if you use such awesome capabilities its for the right reasons!
In general, don't divulge anything to anyone in-game. If someone says, "What's Player-B's email?" answer with "Use pinfo." If they say, "But it's not listed!" then "I guess they don't want it known." I've forwarded emails to unlisted addresses at times (because that doesn't breach the privacy) but I don't give out the data.
Be sure if you plan to allow privacy exposure you list it. Your players will likely let you know what they think about it in advance.
The basic suggestion: document what you intend plainly.
Conclusion
In privacy, there's not a lot of choices. It's really a question of "When is it reasonable to breach it?"
The MU environment provides a false sense of anonymity. This lets people act in ways they would never do if they were personally "there" and subject to exposure. In RP that can allow an introvert to finally interact. But it can also allow someone to become lewd, lascivious, and even sexually harassing or pedophilic.
I say the sense of anonymity is false because the person can be tracked with limited effort.
So, the goal for the wizards is to establish a policy for when breach of privacy is expected.
Common issues to think about in the policy are:
- using the logs to validate a transcript used in a dispute
- using the logs to track criminal action
- using logs to track software problems
- using logs to find how objects were deleted
- using logs for statistical analysis of management data
- using logs to watch all actions in the game
- using logs for titillation
Most players don't like the idea of the logs, but they understand uses that enable the game to run better. As long as what you do and what the players expect you to do are in agreement, your policy can be considered successful!
Created by Otter
Last modified 2007-01-07 12:27 PM
