diff --git a/proposals/291-loeschkonzept-v2.md b/proposals/291-loeschkonzept-v2.md index d3c858d2..3be7695c 100644 --- a/proposals/291-loeschkonzept-v2.md +++ b/proposals/291-loeschkonzept-v2.md @@ -90,7 +90,8 @@ Löschung MUSS server-lokal und ohne direkten Einfluss auf die Föderation erfolgen. **\[\<=\]** Da sich, abgesehen von Raum-Avataren, Medien in Matrix aktuell nicht mit Räumen -verlinken lassen, impliziert die obige Formulierung die Verwendung von [MSC3911]. +verlinken lassen, impliziert die obige Formulierung die Verwendung von +[MSC3911]. ### Clientseitiges Löschen @@ -141,8 +142,8 @@ Zwischenablage für historische Räume. Clients MÜSSEN Nutzern erlauben Räume über die Nutzung der APIs [`/leave`] und [`/forget`] vom Client zu löschen. **\[\<=\]** -_Hinweis: Clients steht es frei die Operationen [`/leave`] und [`/forget`] zu -trennen um dem Nutzer zu ermöglichen ein Archiv verlassener Räume zu erstellen._ +*Hinweis: Clients steht es frei die Operationen [`/leave`] und [`/forget`] zu +trennen um dem Nutzer zu ermöglichen ein Archiv verlassener Räume zu erstellen.* Eine regelmäßige Erinnerung an das clientseitige Löschen von Räumen ist nicht erforderlich. Zum Einen ist der überwiegende Teil der Kommunikation in TI-M @@ -156,32 +157,43 @@ und diese dem Nutzer zur Löschung anzubieten. **Story 7** -- Als Organisation im Gesundheitswesen -- möchte ich zentral vorgeben ob meine Nutzer einzelne Nachrichten per Redaction - löschen dürfen -- damit ich die medizinische Dokumentation sicherstellen kann. +- Als Endnutzer +- möchte ich von mir gesendete Nachrichten für alle Gesprächsteilnehmer löschen +- damit ich schwerwiegende Fehler korrigieren kann. Die Matrix-Spezifikation ermöglicht die (Selbst-)Moderation von Events mittels [Redactions]. Redactions sind eine invasive Form des Löschens da sie über die Föderation propagieren und letztendlich zu einer irreversiblen Löschung von -Inhalten auf allen beteiligten Servern und Clients führen. Der sinnvollen -Nutzung von Redactions zur Moderation gegenüber steht also das Problem des -unerwarteten Verlusts von Nachrichten für alle Gesprächsteilnehmer. Da letzteres -schwerwiegender erscheint müssen TI-M Fachdienste Redactions grundsätzlich -unterbinden. +Inhalten auf allen beteiligten Servern und Clients führen. + +Dieses Verhalten ist in bestimmten Fällen wünschenswert. Man stelle sich z. B. +vor es wurden Daten eines Patienten versehentlich an einen anderen Patienten +gesendet. Hier erscheint es sinnvoller den Versender diesen Fehler direkt per +Redaction korrigieren zu lassen anstatt einen langsameren Eskalationsprozess mit +Löschung durch einen Administrator zu verwenden. + +Gleichzeitig führen Redactions bei Fehlbenutzung aber zu einem unerwarteten +Verlusts von eigentlich relevanten Nachrichten für andere Gesprächsteilnehmer. +Als Kompromiss werden Redactions daher zwar erlaubt. Sie müssen im Client aber +stets mit einem Warnhinweis versehen werden[^1]. -Unabhängig davon können TI-M Clients bei Bedarf visuelles Löschen für z. B. -`m.room.message` Events auch über [Event Replacements] implementieren. Diese -Form des Löschens ist reversibel und transparent da Replacements separate Events -sind und die gesamte Historie von Events erhalten bleibt. Story 7 wird somit -gegenstandslos, da es bei dieser Art des "Löschens" keinen Grund für -Organisationen gibt die Nutzung einzuschränken. +**A_4 - Nachrichtenbasiertes Löschen per Redaction** -**A_4 - Verbot von Redactions** +Clients MÜSSEN ihren Nutzern erlauben eigene Nachrichten per Redaction zu +löschen. Dabei MUSS der Nutzer vor jedem Auslösen einer Redaction per +Warnhinweis darauf hingewiesen werden, dass die Nachricht irreversibel und für +alle Gesprächsteilnehmer gelöscht wird. **\[\<=\]** -Homeserver müssen Requests am Endpunkt -[`/_matrix/client/v3/rooms/{roomId}/redact/{eventId}/{txnId}`] mit einer HTTP -403 Response und dem Fehlercode `M_FORBIDDEN` quittieren. **\[\<=\]** +**A_5 - Kennzeichnung gelöschter Nachrichten** + +Clients MÜSSEN `m.room.redaction` Events analog zu Servern anwenden und +gelöschte Nachrichten mit Datum, Uhrzeit und löschendem Akteur kennzeichnen. +**\[\<=\]** + +Unabhängig von Redactions können TI-M Clients bei Bedarf visuelles Löschen für +z. B. `m.room.message` Events auch über [Event Replacements] implementieren. +Diese Form des Löschens ist reversibel und transparent da Replacements separate +Events sind und die gesamte Historie von Events erhalten bleibt. ### DSGVO & Datenschutz @@ -215,7 +227,7 @@ Dies ergibt sich insbesondere daraus, dass das Verlassen eines Raumes nach Karenzzeit dient daher dazu die Wahrscheinlichkeit eines unerwarteten Verlustes von Rauminhalten für den Nutzer zu reduzieren. -**A_5 - Serverseitiges Löschen nach `/forget`** +**A_6 - Serverseitiges Löschen nach `/forget`** Homeserver MÜSSEN einen Raum und dessen Inhalte lokal löschen, wenn: @@ -228,7 +240,7 @@ Homeserver MÜSSEN einen Raum und dessen Inhalte lokal löschen, wenn: Diese Löschung MUSS innerhalb von 7 Tagen ab letztem [`/forget`] erfolgen. **\[\<=\]** -**A_6 - Serverseitiges Löschen ohne `/forget`** +**A_7 - Serverseitiges Löschen ohne `/forget`** Homeserver MÜSSEN einen Raum und dessen Inhalte für mindestens 7 Tage vorhalten, wenn: @@ -297,7 +309,7 @@ in dieselben Kategorien wie im vorigen Abschnitt "Änderungsvorschlag" gruppiert > der Nutzer zu, so wird er aus dem Raum entfernt, was auch zu einer > Benachrichtigung des Servers führt. **\[\<=\]** -> **[A_25492] - Löschfunktion des Clients[^1]** +> **[A_25492] - Löschfunktion des Clients[^2]** > > Der TI-M Client MUSS Löschfunktionen implementieren, die es dem Akteur > ermöglichen, Daten sowohl lokal auf dem Client zu löschen, bspw. durch @@ -328,7 +340,10 @@ in dieselben Kategorien wie im vorigen Abschnitt "Änderungsvorschlag" gruppiert > löschenden Akteur, das Datum und die Uhrzeit der Löschung enthalten. > **\[\<=\]** -[^1]: Der zweite Teil dieser Anforderung ist redundant zu [A_25575] und gehört +[^1]: Dieses Verhalten wird in ähnlicher Form auch bei der Löschung von Dokument + aus der ePA verwendet. Siehe hierzu [A_20103]. + +[^2]: Der zweite Teil dieser Anforderung ist redundant zu [A_25575] und gehört daher eigentlich auch in die Kategorie "Redactions". [TI-M Basis]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Basis/gemSpec_TI-M_Basis_V1.1.1 @@ -340,7 +355,6 @@ in dieselben Kategorien wie im vorigen Abschnitt "Änderungsvorschlag" gruppiert [`/forget`]: https://spec.matrix.org/v1.13/client-server-api/#post_matrixclientv3roomsroomidforget [Redactions]: https://spec.matrix.org/v1.13/client-server-api/#redactions [Event Replacements]: https://spec.matrix.org/v1.13/client-server-api/#event-replacements - [`/_matrix/client/v3/rooms/{roomId}/redact/{eventId}/{txnId}`]: https://spec.matrix.org/v1.13/client-server-api/#put_matrixclientv3roomsroomidredacteventidtxnid [A_26348]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_ePA/latest/#A_26348 [A_26463]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Pro/latest/#A_26463 [A_25318]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Basis/gemSpec_TI-M_Basis_V1.1.1/#A_25318 @@ -352,3 +366,4 @@ in dieselben Kategorien wie im vorigen Abschnitt "Änderungsvorschlag" gruppiert [A_25575]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Basis/gemSpec_TI-M_Basis_V1.1.1/#A_25575 [A_25576]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Basis/gemSpec_TI-M_Basis_V1.1.1/#A_25576 [A_25577]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_TI-M_Basis/gemSpec_TI-M_Basis_V1.1.1/#A_25577 + [A_20103]: https://gemspec.gematik.de/docs/gemSpec/gemSpec_ePA_FdV/latest/#A_20103