GSC291: Löschkonzept v2

[Johennes]

Proposal

[ManuelB]

Aus meinen persönlichen Gesprächen und Nutzung von Messaging Diensten, kann ich dies bestätigen z.B. benutze ich regelmäßig meine E-Mail Suche um Informationen zu finden z.B. Kontaktdaten von einer Person mit der ich vor 4 Jahren gesprochen habe.

[ManuelB]

Dies können wir (Barmer) nur unterstützen. Organisationen im Gesundheitswesen (Krankenkassen, Krankenhäuster, Ärzte) haben lange Aufbewahrungsfristen (§ 304 SGB V Aufbewahrung von Daten bei Krankenkassen, Kassenärztlichen Vereinigungen und Geschäftsstellen der Prüfungsausschüsse 10 Jahre). Dies sollte auch im TI-M wiedergespiegelt werden. Dies ist auch notwendig um rechtsverbindliche Kommunikation zu gewährleisten.

[ManuelB]

Wir glauben, dass verschiedene Anbieter verschiedene Ziele verfolgen und dass die Löschung von Daten nicht so pauschalisiert werden kann.

[Johennes]

Gemeint ist hier eine Löschung von Inhalten, die von den Nutzern nicht mehr benötigt werden, z. B. weil kein Nutzer mehr im Raum ist. Wenn niemand mehr auf die Kommunikation zugreifen kann und sie verschlüsselt ist, gibt es für Anbieter dann eigentlich auch keinen Grund mehr sie zu speichern.

[phillshort]

Ich kann dies nur unterstreichen. Ab einem gewissen Zeitpunkt möchten wir als Anbieter löschen können. Dies gilt insbesondere für Dateiinhalte wie z.B. Videos, Bilder und Dokumente, da diese über die Zeit große Speichermengen erreichen können.

[denis-loh]

Nach derzeitigem Stand ist das Löschen von Medien mit Matrix-Bordmitteln nur zeitlich aufgrund des letzten Zugriffs möglich, was das DSGVO-konforme Löschen schwierig macht (siehe https://github.com/matrix-org/matrix-spec-proposals/blob/rav/proposal/linking_media_to_events/proposals/3911-linking-media-to-events.md).

[Johennes]

Bei der DSGVO-Konformität bin ich mir nicht ganz sicher. Bei verschlüsselten Medien steht der Schlüssel im Event. Man könnte daher eventuell argumentieren, dass ein Löschen der Events ohne gleichzeitiges Löschen der verlinkten Medien als Einschränkung der Verarbeitung nach BDSG § 58 Absatz 3 gilt.

Davon abgesehen erscheint es aus Resourcensicht aber natürlich sinnlos die Medien weiterhin zu speichern.
Eine transparente Verlinkung wie in MSC3911 wäre also definitiv besser. Momentan wird das im Proposal nur als Wahlmöglichkeit angeführt. Eventuell sollten wir es verpflichtend machen, was dann allerdings als Preis hätte, dass wir dieses MSC adoptieren müssen.

[mlangguth]

Wie über den konstruktiven Austausch in den letzten Wochen herausgearbeitet, war bzw. ist der aktuelle Zustand für die Versicherten schlimm und eigentlich nicht akzeptabel. Es wird von keinem Nutzer akzeptiert werden, dass für ihn relevante Daten - seine Daten! - einfach durch seine Krankenkasse gelöscht werden. Das zerstört die Akzeptanz von TIM auf Versichertenseite.
Daher war und ist es so wichtig, dass wir dieses Problem so deutlich herausgearbeitet und die wesentliche Lösung so klar formuliert haben: KEIN serverseitiges Löschen bei TIM-ePA.

Wenn wir hiervon bei den Medien abweichen, fallen wir auf den für Versicherte nicht akzeptablen Zustand zurück. Die Verbesserunge die wir dann jetzt noch erziehlen, sind aus Versichertensicht vermutlich maginal und werden nicht verstanden werden.

Ich denke man kann durchaus argumentieren, dass eine Lösung für das Löschen von Medien zu gelöschten Nachrichten / Räumen gefunden werden muss - und gefunden werden wird.
Zügig.
Bis eine solche Lösung bereitstehen wird, dürfte die TIM-Speicher der Versicherten sicher noch nicht überlaufen. Wir reden ja noch von einer Rampup-Phase. Daher denke ich, kann man in dieser Version noch gut auf ein Löschen von Medien verzichten und dies nachholen, sobald die Lösung dafür vorhanden ist.

[mlangguth]

Bis Matrix eine Standardlösung für dieses Problem bereitstellt, könnte vielleicht folgender TIM-spezifische Lösungsansatz zum sicheren Löschen von Medien eines Raums umgesetzt werden.

Das Problem die Medien nicht löschen zu können, ist die mangelnde Kenntnis des Servers darüber, welche Medien (mxc:// URIs) in welchem Raum genutzt werden. Hätte der Server diese Information, könnte er bei Löschen eines Raums auf Grund nicht mehr vorhandener Mitglieder auch die zugehörigen Medien löschen - vorausgesetzt, diese Medien werden ausschließlich aus diesem Raum heraus referenziert.

Da wir bei TIM sowohl die Server als auch alle Clients unter unserer Kontrolle haben, möchte ich folgende Lösung zum Löschen nicht mehr benötigter Medien vorschlagen:

1. AFO an Clients: Werden Medien in einem Raum geteilt werden, MÜSSEN diese jeweils im Rahmen der Raumnutzung hochgeladen werden. Die dafür angeforderten mediaids (mxc) DÜRFEN NICHT in anderen Räumen genutzt werden
2. AFO an Clients: Wird ein Medium im Rahmen eines Raums hoch- oder heruntergeladen, MUSS der Client die mxc als state event mit type=gemMediaLink und state_key=mxc-URI speichern, sofern diese mxc-URI noch nicht als state event in diesem Raum erfasst ist.
3. AFO an Server: Im Zuge des Löschens von verschlüsselten Räumen, in denen sich keine Teilnehmer mehr im Status /invite, /join oder /leave befinden, MUSS der Server alle state events vom Typ gemMediaLink aus seinem eigenen Content Repository löschen.

Diese Art der Erweiterung ist für die Clients vergleichsweise unproblematisch. Für die Server sollte diese Erweiterung auch recht gut über eine Ergänzung zu Synapse möglich sein, ohne dass dazu "tief" in Synapse eingegriffen werden muss.

Da die mediaIDs für sich keinerlei sprechende Information haben und bei diesem Ansatz auch nicht sichtbar wird, wer welche Medien hoch- und heruntergeladen hat, sollten sich mit diesem Ansatz auch keine Datenschutzprobleme ergeben.

Wäre das ein gangbarer Weg?
Was denkt Ihr?

[Johennes]

Ich muss erstmal kurz über die Self-Reaction per 🚀 schmunzeln. 😅

[Johennes]

[...] bei diesem Ansatz auch nicht sichtbar wird, wer welche Medien hoch- und heruntergeladen hat, sollten sich mit diesem Ansatz auch keine Datenschutzprobleme ergeben.

Das stimmt glaube ich nicht denn State Events haben auch einen sender. Die unverschlüsselte Verknüpfung von Nutzern und Medien-URIs hätte man hier in jedem Fall. Solange das Medium verschlüsselt ist, ist die URI aber wahrscheinlich nicht wesentlich sensitiver als eine Event ID.

Ich finde die Idee insgesamt nicht schlecht. Man (miss)braucht damit quasi State Events um keine Anpassungen am Datenbankschema machen zu müssen.

Ein Nachteil wäre, dass man bei Redactions nicht herausfinden kann welche Medien eventuell gelöscht werden müssten. Das ließe sich vielleicht realisieren indem man zusätzlich noch eine Relation vom Event, dass das Medium verwendet auf das State Event erzeugt. Allerdings wäre diese Verknüpfung auch öffentlich.

[mlangguth]

Ein Nachteil wäre, dass man bei Redactions nicht herausfinden kann welche Medien eventuell gelöscht werden müssten. Das ließe sich vielleicht realisieren indem man zusätzlich noch eine Relation vom Event, dass das Medium verwendet auf das State Event erzeugt. Allerdings wäre diese Verknüpfung auch öffentlich.

Ich glaube, dass man bei Redactions auf das Löschen der Medien so lange verzichten könnte, bis eine Lösung über Matrix selbst gefunden ist. Die Anhänge sind ja verschlüsselt und damit auch nicht missbräuchlich nutzbar. Entfernt würden sie dann, wenn der Raum selbst gelöscht wird.

[ManuelB]

Wir stimmen hier zu.

[mlangguth]

Das Konzept hat sich jetzt wirklich toll entwickelt! 😃
A_1 würde ich dennoch vorschlagen abzuändern. Die aktuelle Formulierung suggeriert, dass es auch einem TIM-ePA-Fachdienst erlaubt wäre, serverseitige Löschungen vorzuschlagen, wenn er sich nur das Einverständnis der Nutzer dazu abholt. Ein solcher Mechanismus wäre aber versichertenseitig nicht gewünscht (und erhöht die Komplexität für die Implementierung.

Vorschlag
TI-M ePA Fachdienste DÜRFEN Rauminhalte und damit verbundene Medien NICHT löschen, solange noch Mitglieder des eigenen Homeservers ohne /forget enthalten sind. Redactions sind von dieser Regelung ausgenommen.

[Johennes]

Meine Intention war hier tatsächlich, dass die Einwilligung im Regelfall durch ein vom Versicherten ausgelöstes /forget erfolgen würde. Wenn ein Hersteller einen anderen Einwilligungsprozess erdenkt, fände ich das aber eigentlich auch valide. Die Umsetzung wäre dann sicherlich aufwändiger. Im Rahmen des Marktmodells würde ich das aber als herstellereigenes Risiko ansehen.

[mlangguth]

OK, verstehe ich. Würde es die Kommunikation rund um die Nutzung von TIM nicht verkomplizieren, wenn einzelne Anbieter - ich meine hier speziell einzelne Kassen im Kontext TIM-ePA - eine andere Vorgehensweise in der Raumnutzung und dem Löschkonzept hätten?
Bei TIM-Pro-Anbieter könnte ich es noch nachvollziehen, insbesondere, da die Nutzer hier die Wahlfreiheit am Markt haben. Ein Versicherter hingegen hat keine Wahlfreiheit: Er kann ausschließlich den TIM-Account nutzen, den seine Krankenkasse ihm anbietet. Ein "Marktmodell" für den Versicherten gibt es hier nicht...

[Johennes]

Für Versicherte wäre das Marktmodell gewissermaßen die Wahl der Krankenkasse. Wobei wahrscheinlich kaum jemand wegen der TI-M Experience seiner Kasse die Versicherung wechseln würde.

Ich verstehe das Argument prinzipiell. Andererseits haben wir durch das uns vorgegebene Marktmodell immer irgendwo Unterschiede. Die Grenze richtig zu ziehen fällt mir ehrlich gesagt schwer. Deswegen würde ich hier gerna noch andere Meinungen hören.

Generell tendiere ich dazu eher weniger vorzugeben um später nicht Leuten, die schlauer sind als ich, gute Lösungen zu verbieten.

[mlangguth]

Marktmodell ist ja nicht verkehrt. Nur nehmen die Versicherten hier halt nicht teil (nur dafür einen Kassenwechsel durchzuführen ist ja keine Option).
Da wir mittlerweile eine Trennung zwischen TIM-Pro und TIM-ePA haben, könnte man hier recht leicht eine Vorgabe nur für TIM-ePA machen und bei TIM-Pro das Marktmodell "walten" lassen...

[mlangguth]

Ich versuche meine Sorge mit dieser Freiheit für die Client-Umsetzung noch einmal zu erklären:
Wir haben herausgearbeitet, dass der Server von TIM-ePA keine Nachrichten löschen darf, wenn der Versicherte das nicht selbt initiiert hat.
Sprich: Der Anbieter von TIM-ePA darf dem nutzenden Versicherten nicht ohne sein Zutun Nachrichten entfernen.

Wenn es aber zulässig ist, dass der TIM-ePA-Client ohne das Zutun des Nutzers Räume, in denen der Versicherte den Status /leave einnimmt (was bei TIM-ePA auch automatisch ohne das Zutun des Versicherten passiert!), diese automatisch auf /forget setzen darf, dann führt es dazu, dass für den Versicherten doch wieder dessen Anbieter ihm Nachrichten löscht - ohne dasss der Versicherte dies wollte.
Denn schlussendlich hat der Versicherte keine freie Wahl in seinem TIM-ePA-Client, er muss den seiner Krankenkasse verwenden. Entscheidet sich diese bei der Implementierung ihres TIM-ePA-Clients dafür, dass Räume mit /leave des Versicherten-Accounts automatisch auf /forget gesetzt werden, sind die Nachrichten für den Versicherten wieder unwiderbringlich weg. Selbst Nachrichten, die er seit dem letzten Login noch nicht gelesen hatte, sind dann direkt weg.
Das kann nicht unser Ziel für die Versicherten sein, denn das haben wir eigentlich durch die Fortschreibung dieses Löschkonzepts nun verhindern wollen.
Daher ist es wesentlich, dass TIM-ePA-Clients an ein /leave nicht automatisch ein /forget anfügen dürfen.

[Johennes]

Gemeint ist hier, dass Clients nachdem sie selbst auf Befehl des Nutzers hin /leave aufgerufen haben automatisch auch ein /forget senden dürfen. Das scheint mir in A_5 hinreichend beschrieben zu sein.

Nicht gemeint ist, dass ein Client, wenn er den Membership-Status leave in einem Raum antrifft ohne ihn selbst per /leave herbeigeführt zu haben, ein /forget aufrufen darf. Hierfür könnte man vielleicht noch eine zusätzliche DARF NICHT Anforderung einführen.

[denis-loh]

Das halte ich dahingehend auch für eine gute Idee, als dann der Client dem Nutzer eine Abfrage anbieten kann, ob der Raum infolge eines serverseitig getriggerten leave auch endgültig mit forget entfernt werden soll. Hier kann man den Nutzer dann noch auf die client-seitigen Archivierungsmöglichkeiten hinweisen, bevor er das tut.

[mlangguth]

Und warum genau wollen wir erlauben, dass ein TIM-ePA-Client einer Krankenkasse (also genau der eine, den der Versicherte nehmen MUSS) eine Lösung umsetzt, die es einem Versicherten unmöglich macht, einen Raum zu verlassen aber das bisher ausgetauschte für ihn weiterhin im Zugriff zu behalten (aka Archiv)?
Welcher Grund spricht dafür, dass ein Client einen solchen "Löschzwang bei Verlassen" gegen den Versicherten durchsetzen darf?

[denis-loh]

Und warum genau wollen wir erlauben, dass ein TIM-ePA-Client einer Krankenkasse (also genau der eine, den der Versicherte nehmen MUSS) eine Lösung umsetzt, die es einem Versicherten unmöglich macht, einen Raum zu verlassen aber das bisher ausgetauschte für ihn weiterhin im Zugriff zu behalten (aka Archiv)? Welcher Grund spricht dafür, dass ein Client einen solchen "Löschzwang bei Verlassen" gegen den Versicherten durchsetzen darf?

Das verstehe ich nicht. Ich sehe das Matrix-Protokoll nicht als geeignetes Archivierungssystem an, welches insbesondere für ePA-Nutzer nachhaltig verwendet werden kann. Ich finde, dass der Export des Chats in ein eigenes System (z.B. als PDF) jederzeit gewährleistet sein sollte. Wenn der Nutzer seine Daten vorher auf die Archivierungsmöglichkeiten hingewiesen wird und seine Chats einfach exportieren kann, sehe ich es gerechtfertigt, dass der Client beim leave auch automatisch ein forget auslöst. Über A_6 und A_7 ist gewährleistet, dass der Nutzer das auch immer noch tun kann, wenn er serverseitig entfernt wurde.

[Johennes]

Wenn man die gleichzeitige Benutzung mehrerer Clients erlaubt, müsste man also wahrscheinlich in regelmäßigen Abständen so einen Initial Sync ausführen. So ein Sync ist teurer deswegen machen Clients das normalerweise nur direkt nach dem Login oder in speziellen Fällen wie z. B. wenn ein Nutzer ignoriert wird.

Genau das wäre ja die Lösung. Der Client könnte das z.B. in regelmäßigen Abständen tun. Es ist in jedem Fall aber ein für den Client lösbares Problem. Daher muss man die Nutzung dieser Funktion nicht verbieten.

Genau, es gibt quasi eine "best effort" Lösung, die wahrscheinlich akzeptabel funktionieren wird. Im Text ist dieser Sachverhalt auch schon angemerkt.

Die Frage ist aber eigentlich nicht ob wir das verbieten sondern ob wir er es verpflichtend machen. Da tendiere ich ehrlich gesagt immer noch eher zu erlauben aber nicht erzwingen. Ihre Argumente für das Erzwingen finde ich nachvollziehbar aber gleichzeitig auch nicht stark genug um ein hier MUSS zu erzwingen. Ich freue mich aber über weitere Meinungen zu diesem Thema.

[benkuly]

Wenn man die gleichzeitige Benutzung mehrerer Clients erlaubt, müsste man also wahrscheinlich in regelmäßigen Abständen so einen Initial Sync ausführen. So ein Sync ist teurer deswegen machen Clients das normalerweise nur direkt nach dem Login oder in speziellen Fällen wie z. B. wenn ein Nutzer ignoriert wird.

Genau das wäre ja die Lösung. Der Client könnte das z.B. in regelmäßigen Abständen tun. Es ist in jedem Fall aber ein für den Client lösbares Problem. Daher muss man die Nutzung dieser Funktion nicht verbieten.

Das ist absolut keine Lösung. Ein initial sync dauert im worst case gut und gerne mal ein paar Minuten und ist mehrere 10MB groß. In der Zeit ist ein Client nicht sinnvoll nutzbar. Hersteller zu verpflichten irgendwelche nutzerfeindlichen workarounds einzubauen ist schlecht. Einen MSC sehe ich als einzigen Lösungaweg.

[mlangguth]

Das ist absolut keine Lösung. Ein initial sync dauert im worst case gut und gerne mal ein paar Minuten und ist mehrere 10MB groß. In der Zeit ist ein Client nicht sinnvoll nutzbar. Hersteller zu verpflichten irgendwelche nutzerfeindlichen workarounds einzubauen ist schlecht. Einen MSC sehe ich als einzigen Lösungaweg.

Danke für die Hinweise auf die Ausführungszeiten. Dann bleibt immer noch als Lösung einen "Re-Sync" manuell auslösen zu können.
Wir sprechen hier vom Edge-Case der Nutzung mutlitpler Geräte. Ja, das MultiDevice-Feature IST sehr wichtig, nur wird es von den Versicherten vermutlich eher selten genutzt werden. In diesen Fällen könnte man - wenn es vorübergehend nicht besser lösbar ist - den User anzubieten, dass er im Zweifel einen resync ausführen kann.

Diese "Krücke" für den Edge-Case ist für die Versicherten in jedem Fall besser, als auf den Standard-UseCase "TIM zur Archivierung nutzen können" erzwungenermaßen verzichten zu müssen.

[mlangguth]

Die Frage ist aber eigentlich nicht ob wir das verbieten sondern ob wir er es verpflichtend machen. Da tendiere ich ehrlich gesagt immer noch eher zu erlauben aber nicht erzwingen. Ihre Argumente für das Erzwingen finde ich nachvollziehbar aber gleichzeitig auch nicht stark genug um ein hier MUSS zu erzwingen. Ich freue mich aber über weitere Meinungen zu diesem Thema.

Es geht weniger darum, etwas per MUSS zu erzwingen, als etwas durch DARF NICHT zu unterbinden. 😉

Da wir uns gerne sehr nah an der Matrix-Spec orientieren, möchte ich gerne von der dortigen Beschreibung zu /forget zitieren:

In general, history is a first class citizen in Matrix. After this API is called, however, a user will no longer be able to retrieve history for this room.

D.h. Matrix stellt in seiner Spec selbst heraus, dass es etwas besondere ist, einen Raum nicht nur per /leave zu verlassen, sondern anschließend auch per /forget zu vergessen. Es keine Kombi-Operation, vielmehr muss der Client für ein /forget bei bestehendem /join zuvor ein /leave senden.
In meinen Augen schon sehr deutlich, dass auch die Community anerkennt, dass die History - auch bei verlassenen Räumen - etwas wertvolles ist, was man explitzit (zwei Call) aufgeben muss, bevor man es verliert.

Ich plädiere nur dafür, dass dem Versicherten (ohne Wahlfreiheit) hier nicht etwas wichtiges weggenommen werden kann, was für ihn gemäß Matrix-Client-Spec eigentlich vorgesehen ist.

[Johennes]

Es geht weniger darum, etwas per MUSS zu erzwingen, als etwas durch DARF NICHT zu unterbinden. 😉

Ok, richtig. Es geht beides, je nachdem von welcher Seite aus man es betrachtet. Man DARF /leave und /forget nicht kombinieren und man MUSS /leave und /forget trennen. Das ist im Prinzip dasselbe.

Das Spec-Argument überzeugt mich persönlich nicht. Die Spec gibt nur in sehr seltenen Fällen das UI von Clients vor. Push Rules sind ein gutes Gegenbeispiel. Die Spec erlaubt hier unzählige Konfigurationsmöglichkeiten macht aber keine Vorgaben welche davon man in einem Client zugänglich machen muss. Jeder mir bekannte Client legt ein vereinfachtes Konfigurations-UI über die kompliziertere Push-Rule-API.