Erasure Concept

The release of the GDPR introduced the ‘right to be forgotten’. Article 15 e of the GDPR states that each data subject can enforce that a processor shall delete all data related to the the data subject. To comply to that law, an erasure concept needed to be developed. The basic intention of the application is to serve with the least amount of subject related data while still providing features to the user. Therefore, we also do not want to store the data of inactive users longer than necessary. Both reasons lead us to an erasure concept that includes two methods how user data can be deleted.

There is an automatic system, that removes inactive users from the database. This reduces regularly the amount of data that needs to be stored. More importantly, it also reduces the amount of data that can be leaked during an incident. Thus, also reduces the risk for every user in the system. The other way allows the user to trigger the deletion of his or her data. Let’s get more into details in the following sections.

Deletion by Inactivity

Users will use the app for the time they are at the Ulm University. This means for the time they work or study at the university. If they leave, their accounts become inactive and it is not longer necessary to store their data.

For that case, there SHALL be an automatic deletion of users after a certain time of inactivity. A requirement for such a function is to define “inactivity of users”. Our definition considers every operation a user requests to our API as activity except of operations towards the Map API. The Map API only delivers routes and determines routes through the universitiy’s campus. Thus, it SHALL neither process nor store personal identifiable information. Each Request to the Laravel back end updates the user’s property last_seen. A cronjob will run once every week to delete all users that have exceeded the features.users.expiration_period.

Note

The current features.users.expiration_period is set to 4 months.

Deletion by User

A user SHALL always have control over his or her data. Therefore, the app SHALL provide a control element that triggers the deletion of all user data. Finally, the app should inform the user about the state of deletion.

Security & Accountability Considerations

Data protection and data Minimization are an important goal for the success of the app. Therefore, it is important to be transparent and give the user as much control over his or her data as possible. However, the Bulletin Board is an exception. If a user infringues the terms of use, i.e. by offering illegal goods over the platform, we must keep them accountable. Therefore, a strategy SHOULD be evaluated that weighs up the privacys rights of the user towards the accountability for misbehavior. The strategy SHOULD answer following questions:

Should a user be able to delete illegal offer or requests by deleting their accounts?

On the one hand, a user that legitimately uses the platform SHOULD always be able to delete his or her data. On the other hand, a misbehavior of an user SHALL be documented, so that it can be proven towards the authorities and so that the user can be made accountable.

If backups are used to provide evidence, then how long are these backups stored?

If backups are used, it is important to keep them only as long as necessary. Otherwise, the backups will contain a lot of data for which there might be no right to have them anymore. A backup concept should be considered and user should be informed.