Disable All Information Storing regarding ExamSessions (?)

[dfuchss]

Is your feature request related to a problem?

In https://github.com/ls1intum/Artemis/pull/4914 a flag for the fingerprint usage has been implemented.

~Unfortunately, this also disables the UUID (InstanceId). From my point of view (but please correct me) the InstanceId does not contain any person related data. Therefore, it can be enabled?~

Maybe also the storing of IP addresses & User Agents have to be disabled. Unless a scenario exists where this is needed.

Describe the solution you'd like

~A flag to enable the InstanceId~

Describe alternatives you've considered

No response

Additional context

No response

[bassner]

From my point of view the fingerprint does also not per se contain personal data. They are both just identifiers of a browser: one as UUID in local storage, the other one as hash from fingerprint.js that even works if the storage is cleared or when using incognito mode. They serve the same purpose (tracking a user), so if you disable one for privacy reasons, you would disable the other as well

[dfuchss]

As far as I understand the difference is that fingerprintjs uses the computer of the student. Therefore, it handles personal data .

[bassner]

It uses e.g. values like the screen resolution, the operating system, the timezone etc., combines them, and computes a hash from them to create a unique identifier of the browser. The (personal data) values used to compute that hash are never transmitted to the Artemis server, but are only processed on the client computer. So, even with this technique, the systems hosting Artemis are never seeing this data.

The instance ID is just a random UUID, stored in local storage, also used as unique identifier of the browser.

Fingerprint.JS even compares themselves directly to that:

FingerprintJS is a browser fingerprinting library that queries browser attributes and computes a hashed visitor identifier from them. Unlike cookies and local storage, a fingerprint stays the same in incognito/private mode and even when browser data is purged.

The privacy issue around this (and similar techniques, mostly the use of cookies) is that the server can re-identify an already seen user across sessions, collect the actions of that user, and build a profile from it. This issue is present with both the UUID / local storage approach and the fingerprint approach; the UUID approach is just less accurate. However, neither the instance ID nor the fingerprint contain personal data - they are both just an ID.

But that's just how I see it :D

[bassner]

To be honest, in general, for our use case, that's a non-issue anyways as we only have logged in users, so we can always relate an action to a user. Therefore, in my eyes, a privacy issue doesn't really exist here, unless you'd consider the possibility to track how many different browsers a student uses a problem :D

[ge65cer]

@bassner Actually, GDPR recognizes everything that is able to identify a person as “personal data”. The hash being unique to the user's computer is probably enough to identify it as such a personal datum. A UUID in the local storage would at least be pseudonym (just like an IP address), but could still identify the user. At least that's my understanding.

Fingerprinting ist nur zulässig, wenn:

• eine ausdrückliche Einwilligung des Nutzers vorliegt, dass Fingerprinting erforderlich ist, um einen speziellen Dienst zu erbringen und in diesem Zusammenhang ohne Ausnahme zur Durchführung der Datenübermittlung genutzt wird oder
• wenn eine andere Rechtsgrundlage vorliegt, wie z.B. das Berechtigte Interesse (nach DSGVO Art. 6 1 f), das allerdings auch in Deutschland nach dem BGH-Urteil von Ende Mai ggf. nicht mehr zulässig sein könnte. In anderen EU-Ländern wir das Berechtigte Interesse schon jetzt nicht mehr als zulässig angesehen

https://www.eprivacy.eu/news/news-detail/article/digital-fingerprinting/

[bassner]

@ge65cer You're totally right. Of course machine-bound hashes or UUIDs are personal data. My main point was that there is no difference between a fingerprint and an instance ID from a privacy perspective. They serve the exact same purpose. I can identify a person by the UUID as well if I see it twice, as I can do it with fingerprints. As you say, "like an IP address", there've been a few court decisions that make clear that even that is a personal datum. So if you remove fingerprinting for privacy reasons, you have to remove instance identifiers as well

[dfuchss]

I'm not an expert for law. But it seems that there might be a difference between a fingerprint & some pure random id (don't know why) Feel free to contact me via Slack for more details.

Nevertheless, for us this is not a high priority issue :)

[dfuchss]

Do you think that we should also disable user-agent & ip address in the exam sessions? Is there any need for the storing of this? Otherwise, I guess this should be disabled as well.

[krusche]

It helps to identify potential cheating attempts. If you don't want to do that, you can completely disable exam sessions.

We initially planned to only allow one active exam session at the same time per user and exam, but we did not implement this yet.

The idea would be that a user who joins the exam a second time, cannot submit changes anymore in the first exam session to prevent potential issues (e.g. accidentally overriding the submission with an empty one kn the second browser window) and to prevent that two different persons works at the same time using the same credentials.

We also still plan to analyze the data in exam sessions and show suspicious cases in the exam dashboard.

[dfuchss]

We are currently talking with the department. I hope I can simply close this issue soon :)

[dfuchss]

Currently not needed by us anymore :)

[dfuchss]

We need a possibility to disable any storing of data. Currently working on it in #5297