Client: Reporting von Inhalten - wirklich?

[mlangguth]

Hallo zusammen,

gemäß Client-Spec Kap. 5.2.5 muss der Client [Client-Server API#Reporting Content] unterstützen, um "unerwünschten Inhalt an Nutzer in der Rolle 'Org-Admin' zu melden.".
Nähere Details fehlen.

Da in der Regel von personenbezogenen Rauminhalten auszugehen ist, stellt sich die Frage, wie und was genau die Spezifikation hier von wem verlangt. Wenn ich es richtig verstehe, wir dem Org-Admin durch das Event lediglich die Raum-Nummer sowie Event-ID mitgeteilt (sowie die Schwere und eine optionale Beschreibung).

Für eine Prüfung müsste der Org-Admin entsprechend den Raum betreten, um die Nachricht überhaupt lesen zu können.
Wird das gewünscht? Das ein Org-Admin jederzeit jeden verschlüsselten Raum betreten können soll? Vermutlich nicht.
Welcher Mechanismus aber dann? Soll der meldende Nutzer zusätzlich einen Invite an den Org-Admin schicken? oder der Org-Admin "anklopfen"?
Damit er den aus seiner Sicht alten Eintrag lesen kann, muss history_visibility entsprechend zuvor gesetzt worden sein. Mit diesem Setting sieht der Admin dann alle Einträge des Raums. Kann das gewollt sein?

Sofern dies alles gewünscht ist (was ich aus Datenschutzsicht nicht glaube), stellt sich die Frage, wie der Org-Admin anschließend verfahren soll? Nach welchen Richtlinien soll er/sie eine Bewertung durchführen? Und welche Aktionen soll er/sie anschließend auslösen? Und da es i.d.R. ein Raum sein wird, in dem mit TIM 1.0 zwei unterschiedliche Einrichtungen kommunizieren (bzw. ab TIM 2.0 auch die Mitglieder einer Kasse), ergeben sich multiple Homeserver mit mulitplen Org-Admins. Die Meldung geht dann an den Org-Admin des eigenen Kontos (beim Versicherten dann an den seiner Krankenkasse). Soll dann dieser Org-Admin alleine entscheiden? Oder sich mit den anderen Org-Admins der anderen Einrichtungen abstimmen?

Ich bin skeptisch - sehe hier aber in jedem Fall Normierungsbedarf, sofern diese Feature von den Clients weiterhin umgesetzt werden muss. Ansonsten sollte Kap 5.2.5 umgeschrieben und das Reporting verboten werden.

Oder habe ich da etwas gänzlich falsch verstanden?
Dann bitte eine Korrektur zu meiner Sicht. 😊

[Johennes]

Wenn ich es richtig verstehe, wir dem Org-Admin durch das Event lediglich die Raum-Nummer sowie Event-ID mitgeteilt (sowie die Schwere und eine optionale Beschreibung).

Das ist richtig.

Für eine Prüfung müsste der Org-Admin entsprechend den Raum betreten, um die Nachricht überhaupt lesen zu können.

Das ist nicht zwangsläufig notwendig bzw. in Abhängigkeit von der aktuellen Room History Visibility sogar nutzlos. Der Org-Admin kann alternativ z.B. per DM Kontakt mit dem anfragenden Nutzer aufnehmen oder sich per Screenshots bzw. Screensharing ein Urteil bilden. Den genauen Prozess lassen wir hier vorerst bewusst unspezifiziert um mangels praktischer Erfahrungswerte nicht unnötig einzuschränken.

Da es hier seit fast einem Jahr keine anderen Meinungen gab, schließe ich diesen Issue.

[Johennes]

In #291 (comment) gab es verschiedene Stimmen und kritische Nachfragen zur Sinnhaftigkeit des Content Reportings. Es erscheint mir daher sinnvoll dieses Thema doch noch einmal zu eröffnen.

[mlangguth]

Dann trage ich meinen dortigen Kommentar noch mal hier her ... 😊

Ich denke, dass die gematik basierend auf ihrer eigenen rechtlichen Einschätzung und ihrer Kontrolle über die Spezifikation, die Verwendung von Content Reporting in verschlüsselten Räumen grundsätzlich untersagen sollte, um die Komplexität in der Umsetzung (technisch wie organisatorisch) zu reduzieren.

Sobald unverschlüsselte öffentliche Räume (wieder) erlaubt werden, sollte die Funktion dort eingeführt werden, da in öffentlichen Räumen ohnehin Moderatoren benötigt werden.
Für private, verschlüsselte Chats gilt das selbe wie bei Mail-Kommunikation: Der Anbieter hat darin nichts zu suchen und kann auf Grund der mangelnden Einsicht in die Inhalte ohnehin nichts anfangen. Eine Einsichtnahme für den Anbieter verbietet sich bei Kommunikationen, die der Schweigepflicht unterliegen - und das sind bei einem für das Gesundheitswesen genutzten Messengers potentiell alle Chats.

[Johennes]

Die Sinnlosigkeit im aktuellen TI-M Content Reporting als MUSS zu deklarieren leuchtet mir mittlerweile auch ein. Ich glaube verbieten sollten wir es aber nur wenn damit Schaden angerichtet werden kann. Da mit einem Report nur Raum-ID, Event-ID und vom Anzeigenden eingegebener Freitext übermittelt wird, scheint mir hier kein nennenswertes Risiko zu bestehen.

Andererseits würde ein KANN für den Client wegen A_26210 ein MUSS für den Server bedeuten. Da fast alle Hersteller Synapse verwenden muss die API selbst in der Regel nicht mehr implementiert werden. Es müsste aber natürlich ein organisatorischer Prozess aufgesetzt werden um eingehende Reports zu bearbeiten. Ein Anbieter könnte allerdings auch hinreichend durchsetzen, dass nur Clients ohne Reporting-Funktion gegen seinen Server verwendet werden womit dann aus dem MUSS effektiv ein "BRAUCHT NICHT" wird.

[mlangguth]

Den potentiellen Schaden sehe ich bei der Akzeptanz auf Seiten der Endnutzer. Wenn aus vertraulichen Gesprächen heraus ein Reporting möglich ist (laut Spec), dann stellt das schnell wieder einen Vertrauensbruch bei einem hochsicheren Messenger dar. Das muss dann wieder umfangreich erklärt werden, warum das nun doch nicht schlimm ist - und eigentlich auch von niemandem verwendet wird...
Da wäre es - für alle Beteiligten - deutlich einfach und in der Kommunikation auch sinnvoller, wenn Reporting in dieser Spec-Version einfach verboten wird.

[Johennes]

Kein schlechtes Argument. 🤔