Feature Wiki
Tabs
Privacy Improvements of the Learning Progress for Course Members
Page Overview
[Hide]1 Requirements
Status 5.1
The Learning Progress is gloabally activated /deactivated. If activated globally the learning progress can be activated and configured for each object individually.
Yet individual users cannot opt out of being tracked and are not actively notified if the learning progress is switched on after they accepted the legal notice of a given course.
Requirements for 5.2
Priority 1
- The "User Confirmation when Entering Courses" should be adaptable for individual courses and not one global text as it is today. This should allow for outlining what data will be tracked and how it will be used.
- If users did accept a "User Confirmation when Entering Courses" and the learning progress is switched on afterwards the "User Confirmation when Entering Courses" has to be presented and accepted again, now comprising an automatically insert information about the learning progress being switched on.
- It has to be conceptualized how the activation of the learning progress of sub-objects (Objects contained in the course) affects this re-setting of the "User Confirmation when Entering Courses". There has to be a concept how to handle this.
- Additionally there should be a way to configure the course to only show the "summary sub-tab with the anonymised data on object usage.
- If the learning progress is activated, members of a course should get informed about it. This information could be included into the respective course or group mail.
- Users should be able to effectively opt-out of being tracked. They should be able to decline the "User Confirmation when Entering Courses", yet still be able to enter the course and work with all it's content. No learning progress data is displayed for these opted-out members. Their record has to be taken out of any aggregated data of the learning progress as well (Summary sub-tab, Member-tab). This would be a major over-haul of the learning progress concept.
2 Requirements
Learning progress data is based on rather large amounts of user tracking data that ILIAS collects even when the learning progress is "deactivated" for an object or even when it is deactived globally. However, if it is globally enabled, course admins can, for example, switch the learning progress on without the users being aware of this at all. (Think of a sneaky instructor who switches this on for his course at 1 a.m., exports the data and switches it off again. Nobody will ever know...)
This is not compliant with any privacy policies that are relevant for German universities (at least in BaWü) unless the university has regulated this issue explicitely. Even though the tracking users is problematic in general and the didactic usefulness is debatable, the current behaviour of ILIAS makes it almost impossible to use for universites and public institutions to use it.
Another very problematic context for this is, when ILIAS is used as a collaboration platform by employees of an institution. Given that a superior has course admin permission, they could use the learning progress to check / spy on their employees performance without them noticing it when some users are "only" course members in a course. Union representives love such tools and could ban ILIAS from applications in this field simply because of this potential for sneakiness.
The current implementation of course specific user agreements does not mention this kind of data at all reagerdles of whether the LP is activated or not. In the screenshot below you see a such a user agreement in a course on an installatio which has every data tracking feature that ILIAS provies switched on and there is no way to adapt this agreement to the needs / information / scenario of the respective course.
Thus, I propose a set of improvements to tackle these issues:
- create a container news item when the learning progress is activated or deactivated for a single objects and containers (mandatoriness globally configurable)
- notify users directly (via email) at least when the learning progress is (de-)activated for container objects (course, group, folder) (mandatoriness globally configurable)
- give course admin the option to restrict themselves to anonymized data OR chose the personalized lp data
- make the course specific user agreement more flexible to give teacher a chance to explain what data they can see and what they will do with it (absolutely normal when it comes to introducing a survey, for example)
- course agreement should state all data that is available to to course admin
- when the learning progress is activated, the course agreement must be withdrawn
- show the status of activation of the learning progress on the course registration confirmation screen to make course members aware of the current default setting when the enter a course
- restrict the possibility to activate the lp to a subtree of the repository or flag courses manually (as a system admin) in which the lp can be activated by the course admin
- optional: opt out for some users who do not wish to make their data available to the course admins
3 Status
- Scheduled for: Not scheduled yet (will be set by Jour Fixe)
- Funding: Required / Interest in funding: (please indicate if you are interested to fund this feature)
- Maintainer: (will be set by Jour Fixe)
- Implementation of the feature is done by (company, developer)
- Contract settled: No | Fill in "Yes" if a contract is already settled and add Institution / Organisation in "Funding" row
- Tested by / status: (name, e-mail), (status information set after implementation)
4 Additional Information
Contact the following persons if you want to know more about this feature, its implementation or funding:
- Information about concept: Marko Glaubitz, Universität Freiburg
- Information about funding: partly funded by Universität Freiburg
- Information about implementation: (name, e-mail)
5 Discussion
Zenzen, Enrico [ezenzen], 03 AUG 2022: This request no longer fulfills the requirements of the Feature Wiki. In consultation with the maintainer I change the status of the feature request to "Redundant / outdated". If the request is still relevant, please update template and mockups.
6 Implementation
...
Last edited: 3. Aug 2022, 11:48, Zenzen, Enrico [ezenzen]