-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Umgang mit room-history-visibility #163
Comments
Kleine Notiz dazu: Streng genommen ist es mit der v1.5 gar nicht möglich vergangene Nachrichten zu entschlüsseln, egal, wie die history visibility eingestellt ist. Es gibt aktuell aber ein MSC, welcher das ändern soll. |
Danke für die Info. Gibt es einen Zeithorizont für den MSC? |
matrix-org/matrix-spec-proposals#3061 Sieht sehr weit aus. Setzt dann aber eine neue Matrix-Version voraus oder aber eine Art "cherry-pick" durch die gematik, was ich persönlich aber eher kritisch sehe. |
Hallo @mlangguth , wie Du weißt, handelt es sich hier um ein derzeit noch unterspezifiziertes, und daher von Clients noch nicht vollständig richtig umsetzbares Feature, siehe PR matrix-org/matrix-spec-proposals#3061. Auch hier hast Du recht, dass dieses durch die gematik in Bezug auf TI-M geregelt werden sollte. Wir stellen zunächst erst einmal fest, dass es sehr stark vom Use Case abhängig ist, ob das Teilen der Room History mit dem Invitee sinnvoll oder gar notwendig ist. Gleiches gilt für den Zeitpunkt des Teilens. Da die Menge der Use Cases aber groß ist und ständig wächst, ist eine statische Vorgabe je Use Case kaum sinnvoll darstellbar. Stattdessen passiert folgendes: in den nächsten Tagen startet durch unser Business Team die fachliche Discovery zur Eruierung und weiteren Ermittlung von Use Cases. In diesem Rahmen werden wir ermitteln, welche die diesbzgl. Präferenzen der Discovery-Teilnehmer sind pro Use Case. Darüber werden wir ein Mengengerüst ermitteln und abhängig von diesem Mengengerüst eine Vorgabe für die veränderliche Default-Option von m.room.history_visibility machen. Die Veränderlichkeit selbst wird also erhalten bleiben. Daher ist es umso wichtiger, dass User ein Bewusstsein für die Folgen dieser veränderlichen Einstellung entwickeln. |
Hallo zusammen, der MSC hat es mittlerweile in die Aufgabenliste der Spec-Fortschreibung gebracht: Spätestens für die Kommunikation mit Versicherten, also TIM 2.0, wird eine funktionierende history visibility notwendig sein (wenn z.B. ein Vertreter nachträglich in den Raum geholt wird oder ein Arzt für eine Zweitmeinung etc.). Entsprechend sollte TIM 2.0 dann auf der Matrix-Version aufsetzen, die MSC3061 enthält. |
MSC3061 wurde angenommen aber noch nicht in die Matrix-Spezifikation überführt. Grund dafür ist, dass in den Implementierungen, die zur Annahme des MSCs geführt haben nachträglich Sicherheitslücken entdeckt wurden. Weitere Details wurden bisher nicht veröffentlicht. Ich habe diese Woche nochmal mit dem SCT verifiziert, dass die Sache noch in Bearbeitung ist. Dieses Problem können wir aktuell leider nur schwer von unserer Seite aus lösen. Ohne öffentlich zugängliche Informationen erzeugen wir hier unter Umständen nämlich ähnliche Sicherheitsrisiken. Aktuell können wir daher nur garantieren, dass mit der History Visibility "invited", Nachrichten ab der Einladung (auch vor dem Betreten eines Raumes) entschlüsselt werden können. Sobald MSC3061 bzw. eine Alternative in der Matrix-Spec landet, übernehmen wir die Änderungen über die geplante regelmäßige Erhöhung der Matrix-Version in die TIM-Spec. Da es daher auf TIM-Ebene hier aktuell nichts weiter zu tun gibt, schließe ich dieses Ticket. |
Ein fachliches Thema, was wir vermutlich noch ausarbeiten müssen:
Wann sollen alte Chateinträge für neu hinzugekommene User sichtbar sein?
Besteht ein Raum mit Chateinträgen und wird eine neue Person dazu genommen, kann diese Person die Alteinträge sehen (default=shared). Will man das? Immer? Oder steuerbar pro Person?
(Änderung an der Festlegung für einen Raum gelten nicht rückwirkend für ältere Nachrichten in dem Raum).
https://spec.matrix.org/v1.5/client-server-api/#room-history-visibility
Aus Gründen der Interoperabilität und um einrichtungsübergreifende Prozesse auf Basis abgestimmter Funktionsumfänge aller unterschiedlichen Anbieter erstellen zu können, sollte dieses Thema in den gematik-Vorgaben geregelt werden.
Vermutlich sollte die Unterstützung und Pro-Raum-Konfigurierbarkeit von den TIM-FdVs verlangt werden. Das sollte aber noch einmal fachlich in der Runde besprochen werden.
The text was updated successfully, but these errors were encountered: