Hasso-Plattner-Institut für Digital Engineering gGmbH - Information Systems Group
Prof.-Dr.-Helmert-Str. 2-3
14482 Potsdam
Tel.: +49 331 5509 280
Fax: +49 331 5509 287
E-Mail: felix.naumann(at)hpi.de

Internet: https://hpi.de/naumann/

Authorized Representative Managing Directors:
Prof. Dr. Christoph Meinel

Registry Office: Potsdam District Court
Register Number: HRB 12184

Persons responsible for content: Prof. Dr. Felix Naumann

Web Design: Information Systems Group
Texts: Information Systems 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.
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.

User accounts are managed in our chair-internal User-Account Management, namely hpi.de/naumann/admin/ldap/, with an LDAP-server in the backend. For better user management we are storing:
- first and last name for account identification
- username in the format 'firstname.lastname' for authentication (or following similar naming schemas, if necessary)
- password for authentication (external users only)
- e-mail address for administrative contact
- student vs. staff status (only for HPI accounts) - nevertheless this information is already present in the e-mail address ('@student.hpi.de' vs. '@hpi.de')
- creation date and 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.

External users can change their password (by supplying the old one) on the page mentioned above. HPI-internal account passwords are bound to the HPI user account, so their passwords can be changed in the OWA settings at owa.hpi.de

The administrative staff (including professor Naumann) 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.

This section includes the admin Trac, refered as wiki too.

The wiki is for internal documentation and organisation. It's content should serve the chair. It is and will always be non-public. Permissions will be given and taken as necessary, usually for the time of employment/collaboration. Every user should improve the content he feels responsible for. The content will then be kept, until someone considers it unnecessary and removes it. Data without a need for the chair can always be removed.