The core argument between the prosecution and the defense has been regarding the use of Encase which is a computer forensics tool. Encase was used to interact with Macs, running the OSX operating system on the POSIX level, the stuff common to every UNIX. So the prosecution did not look at anything which is OSX specific, for example the defense objected to the fact that the prosecution only examined the 3 types of timestamps used by POSIX vs. all 5 types of timestamps that OSX supports. The defense argues that there is evidence in some of the OSX files and flags showing signs of human activity, and that these signs are not present in the POSIX things that the prosecution examined. To give you an analogy If I were describing a book in Chinese I might have to talk about its color, its weight, the front cover illustration if there is one, the number of pages. That's a limited amount of information. While if I were talking about a book in English I could talk about its title, the description on the back or dust jacket, other books by the same author. And the defense's argument is that they have found evidence in that additional information proving human activity at the time of the murder.
Getting more specific the defense argues that there is exactly the kind of exculpatory evidence that could have been missed via. inappropriate methodologies in the windowserver.log file. Windowserver.log is part of OSX's NeXTSTEP heritage. On most POSIX systems the sorts of messages in the Windowserver.log file would have been caught at the X11 level, not by the windowserver and thus wouldn't have been logged. Since this is one of the key points in the appeal it is worth answering the questions:
- What does the Mac's windowserver do?
- What sorts of things does it log?
Take a quick peek at this diagram to the left. You can see basic I/O actions like typing on your keyboard or moving your mouse get dealt with at the lowest level by Kernel drivers these can also basic translations So user hold shift - a - release shift - n - g - e - l - space - f becomes user types "Angel f". Then the system needs context if the system is booting or in some sort of single user mode you don't want to send messages to a complicated GUI. The context determination is done by "Core Services". For hardware actions that are going to require interaction with end user applications, like spreadsheets, web browsers or games the message is passed through to the Windows Server. It then can handle the message itself, which is generally the case with mouse movements; or it can pass the message onto the correct application depending on where various things are on the screen, which is generally the case with keyboard input. Lets see an example of both. Microsoft Windows machines also have window servers and while things don't work quite the same, but close enough for this demonstation.
I want you to grab another window other than this web browser and move your mouse really quickly so that you keep covering and uncovering this line from various angles. Next I'd like you to reload this webpage and have the browser's rendering engine redraw everything. The first kind of redraw was fast. What happened was your window server saw the two windows were going to overlap, had already buffered what the applications wanted in their windows broke everything down into primitives and fed it to the your graphics card. When you changed your mouse direction the window server used the relative eternity of those hundredths of a second to repeat this process and the two windows passed smoothly. The second time we had the application actually redraw everything and let the window server know what was needed. Orders of magnitude slower.
So hopefully I've convinced you:
- To be grateful to your window server for the years of eye strain it has saved you from suffering
- Why the window server is a very credible witness to a human interaction with a computer. Exactly the sort of process that would know when Raffaele (or another user) was clicking his mouse or banging on his keyboard.
I've highlighted the NSWindow binding which is where Window Server interactions will occur. You can see it is inside of NSResponder, which makes sense, this is how the system is going to pass events to you as an application that it believes you need to respond to. Conversely creating a Window needs to create a reference with Window Server so it can manage it....
It is this interaction between NSWindow as an abstract binding and WindowServer as an actual entity that will generate log. Anytime for example an application requests something impossible, like a window bigger than the screen it is on, if an applications reports that it has no idea what do with a message that was passed to it, etc... Window Server writes a short message in windowserver.log recording this failure and then "uses its judgement" about how to handle the problem. If you look at your own windowserver.log (if you are on a mac) you'll see that depending on your applications somewhere from every few seconds to every ten minutes something like this happens and a note is recorded. They may seem a bit cryptic but they are designed for the applications programmers to see where and when these times when windowserver had to guess occurred. Apple's documentation for the NSWindow class, discusses in detail what sorts of events specifically will generate log. For example in the section on setBackingType Apple indicates that if buffering is changed after initialization that will generate an error, a log entry in windowserver.log. I don't see any advantage in going another level deep but I hope the discussion above makes it clear what the connection is between NSWindow and Window Server, and why that documentation should be taken as authoritative on Cocoa applications generating windowserver.log entries.
For the other environments:
- Carbon the default is to register windows and get messages more or less like the OS9 windowserver unless kOSAModeNeverInteract is set.
- Java the interaction happens at the JRE level.
- Quartz-wm: handles the interaction for X11 applications.
- Quicktime has a lower level primitive that can peer with windowserver (this is complex)
- Classic didn't run on Raffaele's computer so we can ignore.
Let me move away for teaching for a second, and do a pure editorial. I've never personally done forensics in a case involving violence; when I've done it has always been theft or fraud or mostly just trying to figure out and reverse the cause of corrupted data that is driving the investigation. That being said a programmer's laptop should be analyzed more like you would a server and less like you would a general end user's. Encase is fine for Amanda or Meredith's laptops had the prosecution not "accidentally" destroyed them. I don't think it is appropriate at all for Raffaele's. Since he was doing a computer science thesis he's a programmer it is going to require a skilled operator to do the investigation things are not going to in most obvious places or setup in the most obvious way and your typical forensic analysis will be wrong. For example the prosecution focuses heavily on cache data, and that is exactly the sort of thing you would typically check on an end user's laptop to look for activity. I agree with the prosecution's thinking. Most end users on a Mac would have their cache's in /Users/[Raf's username]/Library/Caches and /Library/Caches. But on Raf's machine I'd want to check places like /opt/local/var/cache (Apple's Darwinports default cache location), /sw/var/cache (Fink's default cache location) and he might even have a personal one like ~/caches. Encase won't check for those sorts of caches and thus the investigators won't find these in a cache's report. I agree with Raffaele's defense's intuitively, professionally, the examination the defense argues should have occurred, is exactly what I would have done were I investigating. I do consider this to have been a mistake.
Moreover, I'll say it is the sort of mistake that a forensic accountant / examiner is likely to make; so at least on this point I don't see evidence of an intent to mislead the court. I think the prosecution is innocently incorrect. I hate to take Mignini off the hook ever, but I don't see signs of the prosecution deliberately lying on this point.
There is one another bad news for the defense. Raffaele being a programmer cuts both ways. Because he programs we can assume he knows or can easily learn how to have programs generate events that look like interactions with hardware. He also knows how to change the windowserver.log file. Which means on his system we have to consider the contents of these files less definitive than they otherwise would be. I'd want to look at samples of his code from that time to get a grasp on whether the computer is telling me is likely to be true at worst or highly likely to be true at best. I would scratch definite however in either direction.