Requirement specification and our results
Requirement Status
Capture when keys are
pressed and released Completed Capture mouse interaction Completed
Continues on the next page
Requirement Status Distinguish different HW
components used (exter-nal mouse, touchpad etc.)
The method we first used to detect different hardware worked in some scenarios, but in other scenarios it pro-vided completely wrong results in other again it propro-vided no results. It seems like all mouse hardware is grouped in as one logical mouse one some systems, which means that we probably need to create a device driver to accurately gather this type of information.
Capture peripheral
equip-ment and their status Completed.
Capture how the user
in-teracts with software What information is captured and the type of data we store has been developed throughout the project, until the amount of information was detailed enough. We also found a generic way to gather information, so that in-cludes any applications that was set as a minimum.
Correlate events We have developed some simple rules to decide if two events are connected or not. See section 5.4.2 for a dis-cussion of how we do that and possible wrong correla-tions.
Timestamp with
millisec-ond accuracy Timestamps with millisecond accuracy ±16ms. After a talk with the employer, this was satisfactory, see separate section about time granularity 6.1.3.
Ability to detect lost
pack-ets in retrospect Each event has a counter and each session has a start and stop message. If we lose packets in the middle or at the start, we know how many packets has been lost, if we lose packets at the end, we only know that packets has been lost.
Secure transmission of
data All data is transmitted over SSL/TLS, which provides both security and integrity.
The application should at minimum run at Windows 7 and later
Because of libraries used, the user need at least Windows XP SP 3, which corresponds with the requirement.
Application signed by
cer-tificate authority The application is now digitally signed with a certificate, provided by HIG, and the process for doing this has been detailed, so the employer can sign the code with their own certificates.
Implement mitigative measures to hinder a third party to pose as another user
All the IDs are generated randomly and hashed with MD5.
Each ID is considered a secret and is only sent encrypted over the network.
Continues on the next page
Requirement Status The program should run
unobtrusively By default, the program starts and stops everything when the user power on and power off the computer. The user has the option to turn this off. The program resides in the system tray with minimal obstruction to the user, while still visible.
GUI design There was no hard requirement for how the GUI should look. After discussions and programming, we came to a solution that was simple and provided the basic function-ality and hides all advanced features. For a discussion of the design and how it progressed, see chapter 4.4. It does contains all the elements that were given as requirements.
The loss of logged events
can’t be greater than 1% We have not tested this actively, but have never experi-enced any loss of events, so we are quite sure we are within this boundary.
Estimate total amount of
possible users We have given a moderate estimate based on our limited test. Since we didn’t saw any problems with a couple hun-dred users, these estimates are higher than what we ex-pect to observe in the beginning.
Anonymous, unique and
persistent identifier Each user gets an ID based on computer properties and the username. This ID will be the same for that specific user on that specific computer, but will be different for another user on the same computer.
Table 15: Which requirements we have fully completed and which we have not fully completed, for some reason. means completed, and means not completed.
Table 15 shows a summary of which requirements we have fully completed and which requirements has not been solved for some reason.
The functionality of the application follows closely with the requirement specification.
This also follows from the fact that the requirement specification was not static through-out the project. Several parts where undefined in the beginning and had to be defined as we progressed.
The main part of the application is what we store about each user session. There was no right or wrong way to do this. We had to find a method that we thought would work and decide with the employer. We found a method that collects information about any program that the user interacts with, after a discussion with the employer, we agreed upon this method. Collection of how the user interacts with input devices has been pretty static since the beginning, but has progressed some under meetings with the employer.
The format for the data, had to be in a CSV file format. Exactly how this format should be written changed over time, but we all agreed on a final format, which is what is used in the final application.
Tasks not in requirement specification
During development we also discovered several features that was not part of the require-ment specification, but would be useful.
CSV files are easy to read and analyse when you know what the data is like, but for future work, we came to the conclusion that XML would be a more complete format for this type of data. We implemented the possibility for both CSV and XML in the final application.
Storing this type of information in separate files throughout the system can get com-plicated fast. When you have large amount of information, you also need a fast way to retrieve certain properties. Databases are excellent for this purpose, therefore we also implemented a method for inserting all data into a database. Since this couldn’t be done directly from Syslog-NG (see section 6.3), we created a cron-job which could run every night (when very few people are using the system).
One of the problems we saw with this type of application, is privacy, and what users would think about this type of information gathering. We are open and honest with everything we collect, but some users may still have a problem. Therefore we also im-plemented a method to store the files locally first, before sending it to the server. The user also has the options of filtering out certain time frames. The method we used here is quite limited and provides very little functionality, but it serves as a prototype for what is possible, in section 8.3 we discuss more ideas about this.
Automatic update is a central part of almost any modern application, we have im-plemented this functionality, but since the application will not be in active development after we are finished with the project, it has been turned off.
To test the client-server communication, we used a temporary server. We where sup-posed to set up and configure the development server before the report was handed in, but the server was not ready, as of May 15.