Data Privacy Realization

Data privacy was one of the general requirements for the LA tool (section 6.1). Indeed, it turned out to be a relevant issue, concerning the realization of evaluation phases with real courses and real data, e.g., data privacy regulations affected the selection of pilot courses during the impact evaluation (see chapter 7). We learned that the way data privacy is considered is an important criterion for the successful integration of LA applications in higher education (see section 5.2.3).

E-learning and especially LA are in an area of conflict between the goals of research, teaching, and privacy policies (Hackelöer 2011). Educational systems store sensitive data that impact users’ privacy. LA developments need to consider this, when using this data.

To ensure data privacy, the personal data, which can be extracted from a VLE, needs to be modified. We chose to store pseudomized data, in order to be able to uniquely distinguish between the data of different users while securing their identity. For eLAT, a hash from the username with a learning environment specific salt was created, so that the transformation is not easily reversible. The algorithm used was MD5 with a hash size of 128 bits (Rivest 1992). Also the use of any kind of personal user properties like gender or study course in the indicators was prevented, when there were less than a certain number of students, e.g. five users with that certain property in a course, in order to prevent identification of users with unique properties.

During the research for this thesis, also an alternative possibility was explored: a contract-based system that regulates the use of analytics interfaces by so-called ‘contracts’ (Hackelöer 2011). These contracts form an intermediate instance that checks requests before calculations are performed and outcomes delivered. A contract contains three categories of dynamic conditions: preconditions, postconditions, and invariants. Pre- and postconditions specify conditions, which must be met by the caller of an interface or the callee. Invariants define conditions that must hold before and after the execution of each method of a class, but not necessarily during the execution of a method (Meyer 1992).

Contracts are more flexible than the concept of static typing present in many programming languages, for which already ranges of values for input and output parameters are defined, which can be regarded as a pre-and postconditions. The parameters of the contracts, however, can relate to each other. An example is the precondition:

If parameter A is in range of X, parameter B must be in range of Y, or in the range of Z.

Because of this, the validity of data regarding the contracts can only be checked at runtime (Hackelöer (2011), p. 31).

According to Hackelöer (2011), a contract, which is regulating the use of an analytics interface, is based on up to four dimensions:

• the user inquiring the system, • the type of data being inquired,

• the courses which are targeted by the inquiry, • results of the inquiry.

A contract evaluation process begins with the request of a user. This person selects one or a set of courses and chooses an indicator with specific parameters. For instance, an RWTH computer science teacher selects his current programming lecture and chooces an indicator, which tackles the question “Is wiki page access related to gender?”. The system completes this request by adding information on the required data for the indicator, e.g., data on access to wiki pages by gender.

Then a contract audit is carried out: First, all matching contracts that do not relate to the outcome dimension are processed. A matching mechanism determines those contracts that must be fulfilled. Regarding our example, these are all contracts relating to the three dimensions: RWTH user, wiki pages by gender, and RWTH course. An analysis process evaluates the request data against the constraints imposed by these contracts. Such a contract might, e.g., determine that only registered user are allowed to request this information. If the request can withstand this test, the database query and indicator calculation is released. A transformer regulates the transformation of the data request into the appropriate format for the data access module in both directions. Once the results are available, the contract system checks the pending contracts regarding the outcome dimension. For example, there might be a contract defining that there has to be at least data of five students of the same gender, if gender data is requested by an indicator. If the test is positive, the data access module is granted access to the data. Subsequently, the indicator can make the necessary calculations on the data. However, data access will be denied if one of the contract checks during the whole process is negative. Regarding the example, this would be the case, if there were, e.g., less than five female or male students registered for the programming lecture.

By means of this contract-based analytics process, it is possible to allow a more open provision of indicators. In other words, advanced analytics users could get permission to define new indicators themselves and analyze the results, provided that the contract evaluations allow it. However, a detailed and careful definition of the contract database together with policy experts constitutes an important prerequisite. Contract-based design should be tackled by future versions of eLAT12.

Table 12. Example XML file for importing L²P data into the eLAT database. <?xml version=”1.0”?> <AuditExport xmlns:xsi=”http://www.w3. org/2001/XMLSchema−instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” ExportDate=”2010−12−22T16:10:02.4948859+01:00” SiteId=”4ad20579−86cb−43dc−a618−f0b3115a8d51 ”> <AuditItems> <AuditEventItem EventType=”View” EventSourceType=”Document” EventSourceUrl=”ws10/10ws−19089/shared/discussions/display.aspx” EventSourceId=”e16ccad9−86 cd−4ef7 −8345−8d1c039e9589” SiteId=”4ad20579−86cb−43dc−a618−f0b3115a8d51” UserId=”ED6BD965008D3428C05E27E6B630D1F9” Occured=”2010−12−14 T14:05:52+01:00” /> <AuditEventItem... /> </AuditItems> <ContentItems> <ContentItem xsi:type=”ContentList” FriendlyName=”Hyperlinks” SourceType=”List” SourceUrl=”/ws10/10ws−19089/information/hyperlinks/all.aspx” Id=”89d71d89− a112−4acd−9075−1b51686a70d1” CreatedBy=”475DCA6D15E6B7723C3A18B89B364779” Created=”2010−09−21 T10:31:04+02:00” ListType=”Links” /> <ContentItem…/> </ContentItems> <Users> <User UserName=”044A9414FD72DBF2C5C40F355FBD40C2” Role=”Student” Domain=”CAMPUS” /> <User…/> </Users> </AuditExport> 6.4.4 Data Import

For importing the VLE usage data into the eLAT database, an XML schema was defined. The respective XML file contains three main elements:

• AuditItems: These are individual requests of a specific user on a specific content.

• ContentItems: These are the resources of the VLE, which can be accessed by the users, and their respective creator.

• Users: All users who have either accessed an AuditItem or created a ContentItem.

An example file is shown in Table 12.But this was not the only data that was needed for some indicator calculations. Therefore, other systems need to provide, e.g., personal data or performance data.