Skip to content

Data Economy

Richard Ebeling edited this page Mar 15, 2021 · 12 revisions

Several efforts have been made to reduce the amount of data that EvaP stores and that is visible to users. Among those:

Data creation

  • Rating answers are stored in an aggregated format and not individually (#584), so apart from the first voter (see #1335), there are no sequential IDs that help grouping the answers by voter.
  • Comments have random IDs (#1002), otherwise the usually sequential IDs would enable grouping comments by voter.
  • Random IDs have also been applied to rating answers (#1341), since it was previously possible to reconstruct the votes of the first couple voters (see #1335 for an explanation)
  • Comments and Rating Answers are re-ordered by their random ID. Otherwise, insertion order could have been deduced. (#1335 and wiki page on installing)
  • Insertion order could also have been deduced by inspecting transaction IDs (xmin) of tuples (see #1384). In #1549, we added code that always updates all critical tuples to make sure they have the same xmin. We regularly run VACUUM and CLUSTER on the database to ensure that dead tuples are eliminated (see wiki page on installing). At the moment, we don't intend any further efforts to actually overwrite the memory or any backups or copies that might have been made.

Data deletion

  • Participations can be archived (#505), enabling participants to be deleted (bulk deletion: #749)
  • Grade documents can be deleted in bulk for a semester (#1219)
  • Results can be archived (#1219), making them invisible for all users except managers and the respective contributors
  • When evaluation results are published, text answers that do not meet the threshold for publishing and hidden textanswers are deleted (#1188 (1) (2)).
  • The first voter of an evaluation can decide whether they want their text answers to be kept instead of deleted in case they remain the only voter (diff in pr)

Data visibility

  • The user group with the most rights (managers) can be kept very small by the introduction of a second group (reviewers), which can assist managers with reviewing comments (#920, #1230). Reviewers have limited edit rights and cannot see user profiles and archived results.
  • Users have to explicitly enable the "Staff mode" to use their additional viewing and editing rights (#1109)
  • External users can only see their own courses (#1085)
  • Courses marked as private can only be seen by their contributors, participants, and staff users (#807)
  • Results are shown to different user groups only when certain thresholds are met, see Publishing-Results

Transparency

  • On the voting page, next to each text fields, students are told who will be able to see their answer (#1133)

Passwords

  • We changed to OpenID from Kerberos for authentication, this way our server doesn't handle passwords anymore (#1366).

Out of our reach

  • The underlying storage technology (especially on a virtual server) might keep copies or old versions of our database that can be used maliciously. We do not mitigate that in any way.