English version.

Warum?

Im letzten Jahr haben wir die die Hard- und Software des Phone Operation Center (PoC) fast vollständig ersetzt und somit die Benutzung erleichtert. Zusätzlich hat uns dies die Möglichkeit eröffnet Funktionen zur Verfügung zu stellen, die mit dem alten Setup unmöglich waren. Dazu gehören die Selbstregistrierung von Telefonen, bessere Erweiterbarkeit, die Selbstverwaltung von Nebenstellen und Rufnummerngruppen oder das LDAP Telefonbuch. Nun wollen wir ein weiteres großes Problem aus BenutzerInnensicht lösen: Die Kompatibilität von DECT Endgeräten. DECT-GAP ist ein Standard, der einen relativ großen Gestaltungsspielraum zulässt. Das führt dazu, dass es eine beachtliche Anzahl an Geräten gibt, die zwar DECT-GAP-Konformität in ihren technischen Daten angeben, aber trotzdem nicht oder nur mit Einschränkungen an unserem System funktionieren. Bisher war kein Hersteller bereit, z.B. durch Firmwareanpassungen dafür zu sorgen, dass die Geräte an unserer Anlage funktionieren, auch wenn wir konkrete Vorschläge zur Änderung gemacht haben und sich dadurch keine Nachteile hinsichtlich der Kompatibilität zu ihren Basisstationen ergeben.

In unserem Testsystem konnten wir die Kommunikation von einigen Endgeräten, die bisher nicht funktioniert haben, analysieren und verstehen. Wir haben unsere Anlage so angepasst, dass sie diese Modelle erkennt und ihnen die Daten so zur Verfügung stellt, dass sie funktionieren. Bei anderen Modellen haben wir noch zu wenig Informationen, um reproduzierbare, zuverlässige Verbindungen zu ermöglichen. Es gibt auch Modelle, bei denen wir überhaupt nicht wissen, warum sie nicht funktionieren.

Wir möchten einen tieferen Einblick in die interne Funktionsweise der DECT-Infrastruktur erhalten, wenn viele unterschiedliche Modelle, unterschiedlicher Hersteller eingebucht sind. Dies ermöglicht es uns (vielleicht) eine größere Vielfalt an Endgeräten unterstützen zu können. Grundlage dafür ist, dass wir die Funktionsweise verschiedener Geräte auf der DECT-Schnittstelle verstehen. Dazu benötigen wir deutlich mehr Beispiel-Daten, als wir mit unseren manuellen Tests produzieren können. Da wir grundsätzlich keine Verbindungsdaten speichern, haben wir keine Möglichkeit Daten von vergangenen Veranstaltungen zu analysieren. Aus diesem Grund wollen wir auf dem Easterhegg 2019 die Verbindungsdaten speichern.

Aktuell haben wir keine Möglichkeit gefunden, dies optional anzubieten. Wir konnten viele Fragen nicht sicher klären. Was machen wir, wenn eine Teilnehmerin der Speicherung der Daten zugestimmt hat und eine Teilnehmerin anruft, die nicht zugestimmt hat? Was passiert bei einem Gruppenanruf, bei dem einige der Speicherung zugestimmt haben und einige nicht? Wenn wir Daten pro User optional anonymisieren, kann man anhand des Rufaufbaus trotzdem sehen, wer versucht wurde anzurufen und es müsste der versuchte Rufaufbau bei dem User gelöscht werden, der versucht hat anzurufen und umgekehrt. Wir sind uns bewusst, dass das Speichern von Daten grundsätzlich schlecht ist und sind zu der Erkenntniss gekommen, dass die Situation nicht besser wird, wenn wir die NutzerInnen im Glauben lassen, dass es sicher ist, wenn sie eine Checkbox anklicken obwohl wir es nicht sicherstellen können. Wir haben uns entschieden, transparent zu machen, was wir vorhaben, verantwortungsvoll mit den Daten umzugehen und sie nach einer vorher angegebenen Frist sicher zu löschen. Wer nicht möchte, dass seine Metadaten gespeichert werden, darf auf dem Easterhegg 2019 keine Nebenstelle von uns verwenden. Wir sind der Meinung, dass dies im Gegensatz zu einem Congress oder Camp, auf einem Easterhegg vertretbar ist.

Welche Daten sind betroffen?

Es geht grundsätzlich um die Metadaten der DECT-Nebenstellen. Sprachdaten werden nicht gespeichert. Betroffen sind die Kontroll-Nachrichten zwischen den Antennen und der zentralen Software-Komponente, welche die Antennen und Telefone koordiniert.

Im Detail sind das folgende Daten:

• • die Identitäten der Endgeräte: IPEI, TPUI und IPUI,
  • die verwendeten Schlüssel für die Verschlüsselung der Gespräche,
  • der Anrufaufbau: Anrufer(in) und Angerufene(r)
  • der Anrufabbau (Dauer),
  • die Endgeräte Details (Fähigkeiten des Endgeräts),
  • die Tastendrücke am Endgerät (bei einigen Geräten),
  • die Zugriffe auf das Telefonbuch (bei einigen Geräten).

Beispiel: Wir speichern, wann Alice bei Bob angerufen hat, wie oft es geklingelt hat, wie lange der Anruf dauert, was für ein Gerät Alice genutzt hat, welches Gerät Bob genutzt hat, was auf den Displays angezeigt wurde und dass während des Anrufs z. B. die Taste 2 gedrückt wurde. Dazu gehören auch alle Daten die nötig sind, um den Anruf auf- und abzubauen sowie alle beteiligten Basisstationen.

Tastendrücke und Zugriffe auf das lokale Telefonbuch werten wir nicht aus, wir können jedoch nicht ausschließen, dass diese Informationen gesendet werden.

Wo werden die Daten gespeichert und wie?

Für den Easterhegg bringen wir den Server in ein gesichertes Rechenzentrum. Die gesammelten Metadaten werden verschlüsselt gespeichert. Der Zugriff auf die Daten erfolgt ausschließlich verschlüsselt. Die Daten sind explizit von allen Backups ausgeschlossen.

Wie lange werden die Daten gespeichert?

Die Metadaten vom Easterhegg 2019 werden höchstens 4 Monate, also bis zum bis zum 25.08.2019 gespeichert (Ende des CCCamp 2019). Spätestens am 25.08.2019 werden die Daten gelöscht und der Bereich überschrieben.

Wir werden die Löschung offiziell bekannt geben.

Kann ich ein Telefonat führen ohne dass Metadaten gespeichert werden?

Ja, wenn du eine SIP Nebenstelle nutzt und eine andere SIP Nebenstelle anrufst, werden keine Metadaten gespeichert. Allerdings kannst du nicht sicherstellen, ob ein User eine SIP Nebestelle kurzfristig in eine DECT Nebenstelle oder Gruppe gewandelt hat. Du musst also vor dem Telefonat persönlich klären, ob die Nebenstelle, die du anrufen möchtest, eine SIP Nebenstelle ist.

Kann ich die Services des PoC anonymisiert nutzen?

Ja, du kannst dich mit Fantasienamen und anonymer E‑Mailadresse registrieren. Wir haben dann zwar die Metadaten, könnten sie aber keiner realen Person zuordnen. Beachte jedoch, dass du das Telefon nicht auf dem Camp (da wir die Endgeräte in den GURU3 syncen darf es auch nicht auf dem 35C3 gewesen sein) mit einem Realnamen nutzt, denn da könnten wir die Daten anhand der IPEI zusammenführen (auch wenn wir das nicht vorhaben, gibt es die Möglichkeit, dass uns jemand zwingt).

Habe ich ein Auskunftsrecht?

Ja.

Solltest Du fragen zum Vorgehen und oder dem Datenschutz haben, kannst du uns gern kontaktieren. Wie und Wo, findest du hier: https://guru3.eventphone.de/support/

Freiwillig bestellter Datenschutzbeauftragter ist:

Stephan Kambor
Nobistor 40
22767 Hamburg

E‑Mail: st ‚at‘ eventphone.de
DECT auf Events: 2078 (20ST)

ST

ST ist Künstler und seit 2003 Teil des Eventphone Teams.

www.kambor-wiesenberg.de/

Deutsche Version.

Why?

Last year, we almost completely replaced the Phone Operation Center (PoC) hardware and software, making it easier to use. This has given us the opportunity to provide functionality that was impossible to implement with our old setup. This includes self-registration of DECT phones, better extendability, self-administration of extensions and call groups and the LDAP phonebook. Now we want to solve another major problem from the user’s point of view. The compatibility of DECT devices. DECT-GAP is a standard which allows free interpretation of some parts. As a result, there is a considerable number of devices that do indicate DECT-GAP conformity in their datsheets, but still do not work at all or only with restrictions on our system. Up to now, no manufacturer has been willing to ensure that the devices work with our system, e.g. through firmware adaptations, even though we have made concrete suggestions for changes that wouldn’t have caused disadvantages with regard to compatibility with their own base stations.

In our test system, we were able to analyze and understand the communication of some devices that had not worked before. We have adapted our system so that it recognizes some of these models by making the required information available to them. With other models, we still don’t have enough information to guarantee reproducible and reliable connections. There are also models where we don’t even know why they don’t work.

We like to get a deeper insights of the DECT infrastructure when many different models from different vendors are registered. (Perhaps) This will enable us to support a greater variety of DECT devices. The basis for this is an understanding of how different devices communicate on the DECT interface. Therefore, we need significantly more sample data than what we can produce by manual tests. Since we do not store any connection data, we are not able to analyze data from past events. Because of this, we want to store connection data on the Easterhegg 2019.

Currently we have not found a way to offer opt-in on a per user basis. We could not answer many questions such as: “What do we do if a participant agrees to capture the data and calls a participant who has not agreed?”; “What happens with a group call where some members have agreed and some have not?”. If we optionally anonymize data per user, you can still see who tried to call from the call setup and you have to delete the attempted call setup for the user who tried to call and vice versa. Since we know that it is basically bad to store data, we have come to the conclusion that the situation doesn’t get any better if we make users believe that it’s safe to click on a checkbox when we can’t make sure it will work. We have decided to make transparent what we intend to do with the data, store it in a responsible way and to delete it safely after a specified period of time. If you do not want your metadata to be stored, you must not use any of our extensions on Easterhegg 2019. We believe that, unlike a Congress or Camp, this is acceptable on an Easterhegg.

What data is affected?

It is basically about the metadata of the DECT extensions. Speech/Voice data is not stored. The control messages between the antennas and the central software component that coordinates the antennae and phones are affected.

In detail, these are the following data:

• the identities of the DECT devices: IPEI, TPUI and IPUI,
• the keys used to encrypt the calls,
• the call setup: Caller and called party
• the call end (duration),
• The mobile device details (capabilities of the mobile device),
• the keystrokes on the device (for some devices),
• the accesses to the phone book (for some devices).

Example: We store when Alice called Bob, how often it rang, how long the call lasted, what device Alice used, which device Bob used, what was shown on the displays and that during the call e.g. key 2 was pressed. This includes all data necessary to set up and disconnect the call as well as the base stations involved.

We do not evaluate keystrokes and accesses to the phone book, but we cannot rule out that this information will be sent.

Where is the data stored and how?

For the Easterhegg, we will take the server to a secure data center. The collected metadata is stored encrypted. Access to the data is exclusively encrypted. The data is explicitly excluded from all backups.

How long is the data stored?

The metadata of Easterhegg 2019 will be stored for a maximum of 4 months, i.e. until 23.08.2019 (end of CCCamp 2019). By 25.08.2019 at the latest, the data will be deleted and the area overwritten. We will officially announce the deletion.

Can I make a phone call without saving the metadata?

Yes, if you use a SIP extension and call another SIP extension, no metadata will be stored. However, you cannot ensure that a user has not converted a SIP extension into a DECT extension or group at short notice. So you have to check if the extension you want to call is a SIP extension at the moment.

Can I use the services of the PoC anonymously?

Yes, you can register with fantasy names and anonymous e‑mail addresses. We will then have the metadata, but we won’t be able to assign it to a real person. Note, however, that you are not using the phone at the camp (or 35C3) with a real name, because then we would be able to merge the data using the IPEI (we don’t intend to).

Do I have a right to information?

Yes.

If you have any questions about the procedure or data protection, please do not hesitate to contact us. You can find contact possibilities here: https://guru3.eventphone.de/support/

Our voluntarily appointed data protection officer is:

Stephan Kambor
Nobistor 40
22767 Hamburg, Germany

E‑Mail: st ‘at’ eventphone.de
DECT on Events: 2078 (20ST)

thomasDOTwtf

Thomas ist Eventphone Fullstack Entwickler und gehört seit Jahren zum Team. Er liefert aber nicht nur Code und administriert das Blech, sondern ist auch im Kundensupport, der Logistik, im Backoffice sowie im Marketing und der “Unternehmenskommunikation” aktiv.