Alignment of the System Time With The German Official Time
In order to obtain the most accurate clock time for the required timestamps, the system time of FileWatch is synchronized via the network time protocol (NTP) every 5 minutes. The network time protocol is a standard protocol for synchronizing time in computer systems. The protocol was especially developed in order to achieve reliable time verification in networks with variable packet runtime. The source of the German official time is the Physical-Technical Federal Institute (PTB) with its two so-called “Stratum-1″ servers. These servers are directly provided with the exact time by an atomic clock or radio-controlled clock.
Media Protector GmbH itself owns two “Stratum-2″ servers which are operated as follows: both Stratum-2 servers are synchronized every 16 seconds to one of the Stratum-1 servers of the PTB. In case this server cannot be reached, the other Stratum-1 server of the PTB will automatically be used for synchronization. All systems on which FileWatch is installed are synchronized every 5 minutes to one of Media Protector’s Stratum-2 servers. In case this Media Protector GmbH server cannot be reached, the second Stratum-2 server of Media Protector GmbH will automatically be used for synchronization.
In case a time lag larger than 0.04 seconds evolves between the FileWatch system and the Stratum-2 server despite of its frequent synchronizations, all logged data sets which were logged since the last accurate point of synchronization (with a time lag smaller than 0.04 seconds) will be discarded. Thus, data sets showing incorrect time data are not used for subsequent analyses, guaranteeing that later investigations refer to a timestamp with effectual accuracy in terms of the logged IP address and further data.
About the Logging of User Activities
FileWatch provides some very important features that allow collecting data about activities of other clients within the file-sharing network and storing those into its own database. In particular, the software is able to log crucial data at the moment at which a client downloads certain files from the file-sharing network or when the client makes certain files available for download to other users of the file-sharing network. For logging a client, FileWatch basically uses two options:
For logging a client, FileWatch basically uses two options:
- The first option for logging crucial data arises after the handshake procedure was successful and a client established a connection to FileWatch or when information about the client connected to FileWatch are being updated. Here, data about the particular client and the related file are being exchanged. Those data are so-called “metadata”.
- The second option arises when a client transfers file data to FileWatch (test download). FileWatch uses this specific moment when it is possible, in addition to collecting metadata, to directly collect information about the transmitted file data (i.e. about the transmitted file content itself).
The following data are the most essential information which is logged by FileWatch
- Timestamp, accurate to the split second, indicating the exact time at which the monitored client was logged
- File hash value of the monitored file
- Alias used by the user in the file-sharing network
- Hash value which unambiguously identifies the client in the eD2K network
- File-sharing software name of the logged client
- File-sharing software version number of the logged client
- Maximum number of parts, the monitored file consists of
- Total size of the monitored file (bytes)
- Number of parts of the monitored file actually downloaded by the logged client
- IP address of the logged internet connection
- Internet Service Provider which assigned the IP address to the monitored client
- Graphical diagram illustrating which parts have already been downloaded completely from the monitored client (and which not)
- Identifier which indicates whether FileWatch tried to download data of the monitored file from the logged client (”d” for “download”) or whether the logged client tried to download data of the monitored file from FileWatch (”u” for “upload”)
FileWatch is able to log a client over a time span of several months, even if the client IP continuously changes.
How We Prevent Data Uploads
In addition to logging activities of other clients in the eD2K network, FileWatch allows downloading files which are offered within the file-sharing network. Since Media Protector GmbH itself cannot be the distributor of copyright-protected content when conducting its investigation and logging activities, an implemented software feature prevents any file upload – unlike the popular conventional clients.
Storing Entries of the Client’s Shared List
As already outlined in this expertise, each user who downloads files from the eD2K network usually offers those files automatically to other users of the network. Typically, the offering of files and the file download (virtually) happen simultaneously. In addition to that, the user can choose to expressly share further files within the eD2K network. For this purpose, all popular eD2K clients offer the possibility to determine specific folders or directories as “shared”. The list of files which are located in these shared folders/directories is referred to as the “shared list”.
After FileWatch has successfully completed a TCP connection handshake with another client, the client will be asked whether it wants to transfer its shared list to FileWatch. If the client sends a positive response regarding this enquiry, the shared list will be transmitted to FileWatch. FileWatch is then able to save all entries from the shared list in its own database.
How FileWatch Validates the Content of Downloaded Parts
If a file is supposed to be monitored in the eD2K network, the file’s file hash value will be provided to FileWatch. The file’s file hash value was calculated beforehand by staff members of Media Protector GmbH (by using the eD2K standard algorithms). The first client who offers the file to be monitored to FileWatch transfers, among others, the following information to FileWatch:
- List of all of the file’s part hash values
- File hash value of the file
After this information has been transmitted, FileWatch calculates the file’s unambiguous file hash value from the list of the file’s part hash values.
Afterwards, FileWatch performs the following operations for comparison:
- Does the file hash value which was calculated from the part hash values match the file hash value of the file which is to be monitored?
- Does the file hash value which was transferred by the client match the file hash value of the file which is to be monitored?
If both matching results are positive, the list with the part hash values will be stored for later use. If one of both matchings provides a negative result, FileWatch will try to receive the list of the part hash values and the file hash value from a new client.
As soon as the matching results are positive, FileWatch starts to download the file from the monitored client. FileWatch verifies the correct download of each particular part of the file. This is achieved after all bytes of a part have been collected and the part hash value is calculated and compared to the part hash value from the list which was transmitted and saved before. If matching of the part hash values is positive, FileWatch records all relevant information of all the clients who participated in the part’s completion in a database. This way, FileWatch is able to confirm that correct data of specific parts were received by the logged clients which excludes the possibility of a client being a so-called “leecher client” (the term “leecher client” refers to a modified client who is able to perform downloads but no uploads).
If there is no matching between the compared part hash values, it must be presumed that data transmission was defective. In this case, the entire part is discarded and the download operation is started all over again. Likewise, all data from the clients which participated in the completion of this part are discarded by FileWatch. This prevents clients to be wrongly logged by any means. The possibility of a part hash value matching the part hash value of the transferred list despite wrongly transmitted data is close to zero (1:2128 – it would be more likely to hit the lottery (6/49) jackpot 5 times in a row).
How Downloaded Fragments of a File Are Stored Into The FileWatch Database (Test Download)
In order to provide conclusive evidence of the fact that a client de facto transmitted data of a monitored file to FileWatch, not only the part hash values are verified, but in addition FileWatch saves the first 10,240 bytes of part data which were provided by the client. Thus, genuine data blocks of 10,240 bytes in size are stored in the database of Media Protector GmbH per client and part. In this manner, it is well possible to reconstruct which clients contributed to specific parts and therefore to the completion of the entire file that is monitored.
In order to serve the purpose of safe verification, the size of approx.10 KB for each data block is totally sufficient as the chances of coincidental transfer of data which are identical to the data block of the genuine (referenced) file are practically zero (to be specific, the chances are 1:281.920 – it would be more likely to hit the lottery jackpot (6/49)1000 times in a row).
In addition, its beginning and end point within the file are determined and saved for each data block. Therefore, it is possible that for each successful test download, the 10,240 bytes are automatically located in the reference file (file for which matching with the original work was already verified by staff members of Media Protector GmbH and which is stored on the archive servers of Media Protector GmbH) and checked for consistency. With this procedure, FileWatch is not only able to determine that correct data of a certain part were transmitted by a logged client but also to identify the transferred data themselves. If a client was logged positive, a leecher client can be excluded.
The storage of the 10KB-sized data blocks guarantees that the test download from a specific client can be presented as evidence in unaltered form at a later point in time.
