Pseudonymization of statements with xAPI LRS Proxy

If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ.

1 Initial Problem

From time to time, data is needed to evaluate applications without having to allocate that information to specific users. It may also be useful to generally save data in the LRS through pseudonymisation - especially since there is not always the possibility of deleting data.

2 Conceptual Summary

The ILIAS LRS proxy undergoes such an expansion that incoming personal data is converted into pseudo-virtualized data and forwarded to the LRS. The resolution, which person is to be assigned to which data in the LRS, is only possible with ILIAS. If users or the respective assignment are deleted within ILIAS, the data available in the LRS can no longer be assigned to persons.
If possible, an attempt should be made to provide this resource with pseudomised data as soon as a xAPI resource is called upon. This can prevent personal data from being passed on without being controlled. Normally, fake email addresses are to be generated, whereby it must be ensured that even fake email addresses only exist once, taking into account the clients (for example: rhjzgx2 @ domain-ILIAS). Is has to be checked whether negative effects are to be expected when operating mail servers.

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: Kohnle, Uwe [ukohnle]
• Maintainer: Kohnle, Uwe [ukohnle]
• Implementation of the feature is done by: Kohnle, Uwe [ukohnle]

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

7 Discussion

Klees, Richard [rklees], 2018-07-05 - I consider this an at best ineffective measure to prevent personal data to be passed to an LRS. In the worst case this will make it impossible to control personal data in an LRS. In general I consider the idea that an LRS can be treated as an external system that stores user data in a way unaccessible to the LRS provider to be flawed.

The described mechanism may allow to pseudonymise data in "actor"-fields of the Statement-API, even in a way that makes a user impossible to identify for the LRS provider. However, the extremely open semantics of XAPI allow it to store arbitrary data about a user in the LRS. E.g. "$PSEUDONYMIZED AGENT stored its name 'Richard Klees'". Personal information stored in that way could not possibly be subject to the proposed pseudonymization in a reliable way. The situation gets worse when considering other APIs, especially Agent Profile, that are explicitely designed to store arbitrary data about agents.

This makes it impossible to treat the LRS as an external store that can be shielded from data privacy concerns with pseudonymization. If the proposed pseudonymization is used it moreover makes it actually harder or impossible to determine which data is in fact stored about a user, thus circumventing a reliable answer to requests according to the GDPR.
I would not recommend to implement this feature, as it is ineffective and thus introduces unnecessary complexity.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.