Hasso Plattner Institute for Digital Engineering gGmbH - Algorithm Engineering Group
Prof.-Dr.-Helmert-Str. 2-3
14482 Potsdam
Phone: +49 (0)331 5509-410
Fax: +49 (0)331 5509-429
Email: office-friedrich(at)hpi.de

Website: hpi.de/friedrich/

Authorized Representative Managing Directors:
Prof. Dr. Christoph Meinel
Dr. Marcus Kölling

Registry Office: Potsdam District Court
Register Number: HRB 12184

Persons responsible for content: Prof. Dr. Tobias Friedrich

Web Design: Algorithm Engineering Group
Texts: Algorithm Engineering Group

Legal information:
Hasso Plattner Institute (HPI) constantly checks and updates the information on its web pages. Despite the utmost care taken, we cannot rule out that some of the data may since have become outdated. Therefore, we cannot accept liability for the currency, accuracy and completeness of the information displayed. The same applies to all other web pages that can be reached via hyperlink. HPI is not responsible for the content of websites which can be reached via such links. Furthermore, HPI reserves the right to make changes or additions to the information displayed. Content and structure of the HPI website is protected by copyright. The reproduction of information or data, in particular the use of texts, text excerpts or illustrative material, requires our prior approval.

This privacy policy is an addition to the HPI privacy policy you can find here: hpi.de/en/data-privacy.html
This extension is necessary, because we are using additional services and technologies, which are not already covered. It is also meant to provide a more specific imprint.

Additional covered sites are those below 'hpi.de/naumann/...', which are not published via the main HPI homepage, but instead proxied to internal, chair-controlled servers (keeping the same URL). It also includes some domains, which are directly proxied to our servers. Have in mind, that the servers, which are proxying our contents, store log information too. Find more information in the HPI privacy policy.

Each time you access websites of Information Systems Chair, details of your request will be stored in log files on our servers to keep our internet service running serving your needs. We save data about:

• Name of the requested file (URL)
• Date and time
• Transferred data volume
• Notification, whether the retrieval was successful
• Anonymized IP-Address for regular requests
• Full IP-Address in the event of an error for a maximum of 14 days
• Information about the Operating System and Browser (so called UserAgent, automatically sent by the browser)

The log data will be kept for 14 days, before the log files automatically get deleted.

The data will not be transfered, nor will there be any automated analysis. It is meant for manual security and debug analysis only.

Some of our websites are requiring a login to use them, because they are only useful and/or secure in connection with a user account or are meant to serve only a restricted user group. For this we are mostly utilizing HTTP basic authentication and in some cases cookie based logins. Without a valid login, only a limited error page will be shown.

Cookie based logins do not leave additional traces in our web server log files, only those mentioned for public websites. Instead they create additional application logs. Those will be further explained in the relevant application sections. Using this method, it is technically necessary to use Cookies, that is why they are excluded from the need for acceptance and will be set, when the user logs in. The login will not work, if your browser rejects cookies.
However, this technology needs to be implemented in every backend web application and is though not always useful.

Our alternative kind of authentication is HTTP basic authentication, where the login is done by a browser prompt (requesting a username and password) and the web server. Username and password will be sent with every user request, but only used for authentication purpose. The transmission will be protected through encryption.
With this method, a logout option is not always provided, but because every user should only have one account, this should not be a problem. Still most browsers perform a non-interactive logout (they forget username and password), when they get closed. This should be preferred, to perform a logout. Following the official specification, an interactive logout is hard to implement and could even be lacking support.
The advantage of this authentication is, the backend content may not even recognize the authentication, so they are independent and easier to implement. Because we are in a research environment, this is still the authentication of choice.
For the reasons of debugging and security auditing, this method adds the username and the authentication status (failed or valid) to the web server log (and still logging basic information - see public websites).

Anyhow, the log files follow the same deletion policy as the logs from our public websites.

This chair provides some interactive, partly login-restricted online service to support collaboration. They are not only available for people within the HPI (after activation; login through HPI account), but for registered externals too.

External user accounts are managed in our chair-internal User-Account Management with an LDAP-server in the backend. For better user management we are storing:
- first and last name for account identification
- username for authentication (for Jan Muster it would be jmuster)
- password for authentication
- optional e-mail address for administrative contact
- optional note as administrative user information. The note can be something like the initial reason for the account, e.g. a project name or the requesting tutor. It's format is not standardized and will not be analyzed.

Users can change their password on this page: https://hpi.de/friedrich/docs/fusiondirectory/ (please login: My Account -> User -> Edit - enter new password -> Ok)

The administrative staff (including professor Friedrich) can view and modify the user information as well as add or remove accounts. We are creating user accounts as necessary (only in coordination with the new user) and keep the right to delete user accounts, if they are abused or there is a permanent lack of necessity. Users can also send us an e-mail to request the deletion of their account (preferably from the stored e-mail address to prove legitimation - otherwise the deletion is dependent on the trustworthiness of the sender). In the same way information about the own account can be requested.

These platforms are made for collaboration of users and project management. They are by design dependent on storing and sharing of user-contributed data (any kind of files in SVN, Git and Trac; especially textual content in the Trac). Version control systems like Git and SVN are made for tracking all versions of contributed data, the Trac systems store all versions of wiki pages too.

All submitted data will be stored until we have no more storage capacity or the repository gets deleted. Repository means a Trac instance with an optional Git or SVN instance. Repository administrators are responsible for user and permission management. The setup restricts access to any data without a permitted account. One exception to this is the anonymous Trac access, which can be configured in the Trac permissions.

By default, the administrative staff have administrative access to the repositories to ease repository management. These permissions can be removed, but we would like them to be kept.

Deletion of owned repository can be requested by e-mail (provided it is trustworthy), but because repositories are bound to projects and/or research, we keep the right to finally decide, whether the content is still needed. Our infrastructure so should not be used for solely private content.

Git and SVN instances are usually accessed through non-browser based clients and even though you may never browse to the corresponding website using a browser, you are still accessing our repositories and servers in a similar way. Every action (like pull, push) will leave traces in our log files and because you have to log in, please read the section about non-public websites.

By design, Git and SVN are distributed services, meaning submitted content can be downloaded (pulled) and though leaves our systems and action range. Please be aware of the fact, that not all data will always be able to be deleted. The same states for single versions of data. You should not push private data you do not want to be shared. Take care about your personal data in commits (usually Name and E-Mail address) too, it might be impossible to delete it.

As good as possible and practicable, we try to protect your personal data rights.

We are providing a Moodle Instance for better coordination of our lectures, to provide information and a platform for discussion, and for interactive exercises. We ask every student, who is participating in our lectures, to use the learning platform for a better learning experience.

The account used to login is already handled by LDAP or is out of our range (because we are utilizing the HPI user account backend) and we use cookie-based authentication (see the section about non-public websites).
Account deletions can be requested by mail (like the sections above).

We are storing activity logs for logged-in users to retrace unwanted or malicious behaviour. They get deleted after 10 days and no automated analysis will happen to them.
To provide the full functionality it is necessary to store user-owned and user-connected data (always bound to a lecture/course), e.g. submissions or forum discussions, or gradings. They get deleted when the course is deleted.
Somehow, not all user-owned data can be deleted while a lecture is still running, because forum discussions could get incomprehensible or exercise sheets might still be needed for grading completion. Some data might even be needed until the whole grading process is completed, because the Moodle is used as documentation source for reached grading points. Though it is technically possible to remove such data, it might not always be allowed due to the strong integration into the lectures.

Anyhow, most data directly resulting from account actions can safely be deleted.

Illegal content (including copyright infringements) will be manually removed, at least after we got to know it.

For some data (surveys, exercise submissions, forum questions, gradings,...) it is necessary to be processed. Some analysis happens automatically, e.g. summation of grading points to form a grade or the evaluation of a survey. In other cases the processing is done by lecturers and their (student) assistants. They are required to respect the users privacy, but their processing is a requirement for the lecture too. For their complete rights regarding grading, please see your study regulations.

As an alternative to our platform we can only offer you a minimum of the requirements for our lectures (like exercise submission) to happen by mail or file share. Otherwise it is technically not possible or hard to implement. We welcome suggestions, if necessary.

Our Domjudge instance is a judging platform for competitive programming challenges. It is used in seminars for high performance computing and is though necessary for comparisons between student performances.
The platform is set to self-register with a self-chosen username. For seminar participants we are requesting a match of username and student name, to be able to use the platform results for grading. That is why we suddenly have user-related data.
To limit the affected group, a pre-login with an HPI account is required. This is done with HTTP Basic Authentication. Additional (external) accounts can be requested.

The domjudge authentication is cookie-based, so please see the section about non-public websites.

We are storing all user submissions (together with submission timestamps, execution time and execution results) and user actions until the seminar grading is finished to eventually re-check or prove the seminar grade. The user submissions obviously get processed (compiled and executed). It is even possible, that this happens multiple times, because the execution timings are sometimes unstable. Old submissions are kept for the purpose of rejudgings (reprocessing of previous submissions).
The user actions do not get processed automatically, they are again only for documentation and retracing purpose.

Because the programs are executed on our server, it can not be completely guaranteed, that no student will ever find a bug, which gives him access to the other user data. Even then, he would be required to respect the user privacy.

The lecturers and their assistants have access to all submissions and can trigger the processing. The users can not see their previous submissions, but they are still kept by us.
In any action, we are respecting the ownership of submitted code.

To increase the competition, all users can see a scoreboard with all usernames, where for each task and user the fastest execution time and the number of tries are shown.

If you want your account to be deleted, please send us an e-mail (and preferably one of your submissions to prove your identity - if not already matched to a student name).

For an alternative see our offer in the Moodle section.