This service

This service hosted at jabber.libretank.org runs on a voluntary, honorary basis and serves to enable its users to do some cool stuff. It follows the principle of data minimisation and processes personal data only for this purpose. Since you can expect this processing (otherwise you would not use the service), I consider the legal basis for data-processing to be your consent (according to Art. 6 (1) lit. a GDPR) which you can revoke for the future at any time.

Your rights

You have the right to see what data is stored about you, access it in a machine-readable way, to have it corrected, deleted, or at least restricted from further usage if there are legal or other substantial reasons not to delete it. Just use the general contact credentials given below and expect an answer within a month.

Server rules

The basic rule is to act in accord with the purpose of this service and to do it no harm. Communicating with each other means not to violate mutually accepted rules of communication on purpose; but it also means to assume good faith. Counter examples could be insults, attacks, spam, advertisement, but also hidden bridges to other systems. Owners of public groupchats shall interprete these rules adequately for their group.

• For preventive actions against spam, I will occasionally perform manual plausibility checks (contacts, devices, ...) on unknown accounts.
• Matrix bridges leak a lot of other users' data without their knowledge to Matrix users and are thus blocked.
• I use the XMPP community blocklist against known spammers.

Stored user and contact data

As is typical for an instant messaging server, it receives and delivers your chat messages as well as your presence indicator (online, busy, …) from and to your contacts, as well as other information your client sends (e.g. operating system, client software, etc.). Besides your account name ("JID"), its password and its creation date it also stores your contact list ("roster") including your contacts, the contact groups and nicknames you assign them to, their vCards, etc., the group chats you participate in ("MUCs") and your public vCard (display name, avatar and anything else you like to add). You can edit or delete any of these elements at any time, except for your account as such which has to be manually deleted by me.

It is a core design feature of XMPP that your messages are principally not stored on the server. Nonetheless, I strongly recommend using OMEMO to encrypt your message contents, especially as there can be some exceptions to this rule:

1. Offline messages: the server keeps up to 500 messages sent to your account while none of your clients is online. They are deleted upon first delivery to any of your clients. This is an important feature since otherwise none of your contacts could send you messages while your phone is off, for example.
2. Message Archive Management (MAM, XEP-0313) lets your clients store your messages on my servers which is particularly important if you use several clients and want them to be in sync. The server assumes per default that you use it though waits for your client to request. Hence, you can disable it within your client (e.g. Conversations). Any message is automatically deleted after 7 days.
3. MAM can also be activated for MUCs by their administrators. Any message is automatically deleted after 7 days.
4. Files uploaded via http (XEP-0363) are stored for 7 days and can be re-downloaded for that time. Their path is randomised so that it cannot be guessed. If uploaded with OMEMO encryption their contents are hidden to me, though I can still see their name, type and size.

As a user's contact you can not access messages stored by or for a user. This is just the nature of instant messaging services just as it is with postal mail. Only in case of paramount security interests (you know "life and death" things and such) will I begin to consider intrusion into my users' privacy to delete specific messages.

Log level of ejabberd is set to 3 (warning), sensitive data (e.g. IPs) is hidden from ejabberd specific logs (though might be inferable from general syslog).

If you register an account on this server, I receive a message at one of my accounts. This serves as spam protection measure and – if I know you – it allows me to welcome you and ease your start on my server.

Account deletion

You can delete your account from this server on your own, if your client supports that. Inactive accounts are deleted after 178 days, so you could just wait (for this purpose, your last online time and connection state are logged via ejabberd's mod_log; I also get a notification about deleted accounts). After logs and backups time (see below) all data related to you will be gone from this system.

Third party services

No external services are either embedded or used.

Push services

In order to notify you of new messages while your client app is in background, this server might communicate with third-party push services like Google's FCM, Apple's APNS and others. To activate, your client needs to send push credentials to my server, i.e. you would have to activate this in your client. In case of a push notification, your app's push server is notified that there is a new message waiting for you at jabber.libretank.org. The push server then tells your push service that there is a new message waiting in the app (XEP-0357). The push notifications do not incluce message bodys and sender IDs. It will also send periodical messages to keep the connection with MUCs alive. Push should only be necessary for iOS devices.

Analytics

No analytics tools are used, neither external nor internal.

Non-vetoable processing

However, there are server logs and backups. Servers logs (including IP addresses, user agents, visited pages, etc.) are necessary in terms of security, that is in order to provide basic protection against brute force attacks, other attacks, as well as spam. They are also a technical necessity, since they allow debugging and maintenance works. Logs are saved for up to 7 days and up to another 10 days in complete server backups. Complete backups are necessary in case of technical or administrative failures as well as repair works after attacks like ransomware. I consider this processing a legitimate interest in the sense of Art. 6 (1) lit. f GDPR, but also a legal obligation according to Art. 6 (1) lit. c GDPR since I am obliged to protect your data and thus my systems. This means that you cannot veto this processing.

Logs and other system informations are collected by my monitoring system, hosted at Strato (Germany).

Service provider

No other administrators. The service is hosted on a Germany-located server at Contabo, Hetzner and Netcup, which confirmed in a contract on commissioned data processing (CCDP) that they will process the data only according to the contractual purposes. Backups might also be stored with other hosters (as is recommended), but only end-to-end-encrypted and with a CCDP.

Supervisory authority

The responsible supervisory authority is the data protection officer of Rheinland-Pfalz (Rheinland-pfälzischer Landesbeauftragter für Datenschutz und Informationsfreiheit).