GSC291: Löschkonzept v2 #291
Conversation
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
| auf die Föderation nicht klar benannt. Unterschiedliche Interpretationen | ||
| können zu unterschiedlichen Implementierungen und im schlimmsten Fall zu | ||
| Inkompatibilitäten führen. | ||
| - Die Anforderungen entsprechen teilweise nicht den Bedürfnissen und Erwartungen |
There was a problem hiding this comment.
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.
| gruppierten User Stories und die daraus abgeleiteten Änderungsvorschläge | ||
| vorgestellt. | ||
|
|
||
| Ausgangspunkt der Vorschläge ist, dass alle aktuellen Anforderung zum Löschen |
There was a problem hiding this comment.
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.
|
|
||
| **Story 1** | ||
|
|
||
| - Als Anbieter |
There was a problem hiding this comment.
Wir glauben, dass verschiedene Anbieter verschiedene Ziele verfolgen und dass die Löschung von Daten nicht so pauschalisiert werden kann.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Ein Problem bei der Verwendung von State Events ist, dass man zum Senden dieser Events ein bestimmtes Power Level benötigt. Insbesondere ist nach Matrix das Default-Level für Nutzer 0 und für State Events 50. Power Level werden durch die TI-M Spezifikation aktuell gar nicht behandelt, was schon ein Problem an sich ist. In jedem Fall würden vorab nötige Festlegungen die Sache hier aber verkomplizieren.
Dieses Problem ließe sich eventuell vermeiden wenn man unverschlüsselte Raum Events anstelle von State Events verwendet oder vielleicht ein unverschlüsseltes Feld im content desjenigen Events, das das Medium verwendet.
Prinzipiell muss man bei diesem Vorgehen aber auch ähnliche Fragen beantworten wie bei MSC3911. Was passiert z. B. wenn ein Event mit Medium editiert oder in einen anderen Raum geforwarded wird?
Was mir nicht gefällt ist, dass wir gewissermaßen eine Krücke bauen, die versucht MSC3911 ohne Eingriffe am Server umzusetzen. Das wird uns jetzt Zeit sparen, die wir dann in Zukunft aber wieder einbüßen wenn wir auf MSC3911 oder eine ähnliche Lösung migrieren müssen.
Ich plane noch die Vorhaltung von verschlüsselten Medien ohne Löschung rechtlich bewerten zu lassen. Das wird allerdings nicht vor kommender Woche passieren. Sofern das nicht möglich ist, tendiere ich momentan eher dazu eine automatische Löschung von Medien vorzugeben und MSC3911 voranzutreiben.
There was a problem hiding this comment.
Ich kann nur noch einmal betonen, dass eine automatische Löschung von Medien unser in der Diskussion erreichtes Ziel vollständig dem Erdboden gleich mach!
TIM ist für den Versicherten der einzige Ort, in dem er und an dem er med. Informationen mit seinem Arzt austauschen kann. Dies schließt Anhänge wie Laborbefunde und Bescheinigungen regelhaft mit ein.
Wir DÜRFEN diese med. Inhalte einem Versicherten nicht unaufgefordert entziehen.
Es würde sicherlich auch niemand akzeptieren, wenn der eigene Mailprovider (gmail, web.de, xyz) in den IMAP-Postfächer zwar die Mails selbst belässt, die Anhänge aus den Mails aber unaufgefordert löscht!
Das KANN und WIRD von keinem Versicherten akzpetiert werden. Wir beschädigen mit diesem Vorgehen die Akzeptanz von TIM nachhaltig.
Ich kann gar nicht eindringlich genug vor diesem Schritt warnen!
There was a problem hiding this comment.
Es steht außer Frage, dass das keine schöne Lösung ist. Ich sehe das aber vor dem Kontext, dass dieses Problem wegen der aktuellen Spezifikation zum Start von TI-M ohnehin bestehen wird. Wir haben heute schon zugelassene Clients und Fachdienste, die nach aktueller Spezifikation nicht nur Medien sondern auch Events automatisch löschen dürfen. Wer zum 15.7. noch zulassen möchte, hat die Zulassung nach der aktuellen Version schon beantragt oder besitzt sogar schon einen Slot. Wer dann seine Zulassung hat, wird sich wahrscheinlich nur für das neue Löschkonzept nicht direkt wieder eine neue Zulassung holen.
Die Änderungen, die wir mit diesem Proposal machen kommen für den Start von TI-M also leider ohnehin zu spät. Deswegen würde ich eher auf eine inkrementelle Verbesserung abzielen und das Problem der Medien danach nur einmal aber dafür richtig lösen.
There was a problem hiding this comment.
Ich verstehe die Sichtweise, jedoch wird das automatische Löschen - sowohl von Chats als auch von Medien - durch konfigurierbare Dauern ausgelöst. Wenn wir also gemeinsam zu dem Schluss kommen, dass eine automatischen Löschung (sowohl von Chats als auch von Medien) kontraproduktiv für die Akzeptanz und den Nutzen von TIM-ePA ist, kann problemlos eine Vorgaben hinsichtlich der vorzunehmenden Konfiguration festgelegt werdern (Löschfrist unendlich). Somit wäre das Löschen auch ohne Änderung und Neuzulassung faktisch ausgeschaltet und könnte dann mit der nächsten Version und passenden MSCs korrekt aufgenommen werden.
Diese Option steht und frei und kostet nichts.
Ich schlage daher ausdrücklich vor, diesen Weg einzuschlagen.
There was a problem hiding this comment.
Wenn ich es richtig verstanden habe, dann werden automatisch Medien gelöscht. Das finde ich aus Usersicht unerwartet. Im Medizinischen Kontext fände ich es besser, wenn ich als User das selbst unter Kontrolle habe. Es darf nicht sein, dass jemand anderes mir meine Medien löscht. Besser werde eine Art Quota, wo ich dann selbst Medien löschen kann. Wichtig ist, dass es unter die Kontrolle der User ist und nicht fremdbestimmt.
|
|
||
| - Als Endnutzer | ||
| - möchte ich von mir gesendete Nachrichten für alle Gesprächsteilnehmer löschen | ||
| - damit ich schwerwiegende Fehler korrigieren kann. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
|
||
| TI-M ePA Fachdienste DÜRFEN Rauminhalte und damit verbundene Medien NICHT ohne | ||
| vorige Einwilligung aller lokalen Teilnehmer des Raumes löschen. Redactions sind | ||
| von dieser Regelung ausgenommen. **\[\<=\]** |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
| Clients steht es frei nach dem Verlassen eines Raumes durch [`/leave`] | ||
| automatisch auch ein Vergessen per [`/forget`] auszuführen. Tun sie das nicht, | ||
| ermöglichen sie ihren Nutzern damit die Verwaltung einer Zwischenablage für | ||
| historische Räume. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Der Spec-Verweis sollte nur aufzeigen, welche Bedeutung die Differenzierung von /leave und /forget für Matrix hat.
Es geht auch nicht um UI, sondern um die Frage, welche Funktionen bereitgestellt und welche nicht - allerdings nicht WIE die Funktionen bereitgestellt wird.
Die Historie IST in jedem Fall für die Versicherten von essentieller Bedeutung. Darauf verzichten kann er nicht, er MUSS diese Möglichkeit haben.
Proposal