Hi!

My previous/alt account is [email protected] which will be abandoned soon.

  • 1 Post
  • 553 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2024

help-circle







  • Simultaneously, you lose all rights to the site and risk a hostile takeover with no possible recourse.

    It’s also significantly more effort to retain this level of anonymity from a state actor. I don’t even think there’s a single Lemmy instance which follows all those steps.

    The thing is, as of right now German censorship doesn’t warrant this. Yes, it sucks you cannot freely speak about Israel. But frankly, since it only requires you to adjust your wording minimally without changing the message (“Israel should be destroyed” => “I support a one state solution where everyone in current-day Israel and Palestine can live freely, similar to how South Africa abolished apartheid.”) it’s really not worth it.

    Should Germany turn fascist and ban all opposition, it is too late for feddit.org and their moderators anyways. If Germany doesn’t, feddit will be fine like this and reduce the strictness of these rules as German sentiment towards Israel slowly worsens over the coming years.




  • I mean German fairy tales try to maximize Schadenfreude. Bad things happen to bad people - which is fun. Sure, the “bad things” are horrific but children don’t mind that usually.

    I definitely remember reading a bunch of gruesome children stories as a child (and they were great)! Struwwelpeter and Max und Moritz are two funny children books with a couple of deaths.





  • Daran hab ich auch gedacht, dies ließe sich durch eine zentrale Speicherung der Schlüssel beheben. Im Falle des Verlusts der Karte bzw. bei Wechsel der Krankenkasse - und nur dann - darf der jeweilige Schlüssel von der Datenbank gelesen werden.

    So etwas sicher zu gestalten ist nicht sonderlich schwer, da der Zugang ausschließlich einer einzigen Partei - der Krankenkasse - ermöglicht werden muss. Somit kann man sämtliche Hardware, Software und Mitarbeiter kontrollieren und sicher aufsetzen. Z.B. könnte man die Server in einem Intranet der jeweiligen Krankenkasse aufstellen und den Zugang lediglich bestimmten, direkt verbundenen PCs erlauben. Selbst die größten deutschen Krankenkassen hätten nur eine handvoll Zugriffe pro Tag auf die Server; dies lässt sich sehr leicht absichern und überwachen.


  • Ignoriert wurde es nicht, zudem der Prüfungsraum ca. 10 Meter von einem ebenerdigen Ausgang entfernt lag. Die Evakuation hätte höchstens eine Minute gedauert, das Risiko war also akzeptabel.

    Auf einer Risikomatrix wären wir im gelben Bereich: Praktisch unmögliche Schadenswahrscheinlichkeit mit kritischem Schadensausmaß. Wäre der Prüfungsraum z.B. m dritten Stock, wäre die Schadenswahrscheinlichkeit durch die längere Evakuationsdauer höher und somit das Risiko, die Evakuation zu verzögern, inakzeptabel.

    Aufpasser an Feueralarmknöpfen hätten in diesem Fall ja auch nichts gebracht.

    Ich fand es relativ harmlos, da sehr schnell klar war, dass es sich um einen Fehlalarm hielte. Gäbe es Restunklarheit, auch nach wenigen Minuten, so hätte der Raum evakuiert werden müssen.



  • Ich seh einige Probleme, vor allem da Sicherheit (Security) und Bedienbarkeit leider stark im Konflikt stehen.

    Als relativer Laie würde ich als Design einen Hardware-Schlüssel in alle Krankenkarten packen, mit dem die jeweilige EPA verschlüsselt ist. Zugriff auf die verschlüsselte EPA erhalten Arztpraxen überhaupt erst durch das existierende Verifizierungsgedöns mit dem auch Abrechnungen gemacht werden.

    Problem hierbei ist, dass ein Programmierer aber keine Hardware-Entscheidungen treffen kann. Wenn also die Grundbedingungen Schrott sind, kann man höchstens so viel Schaden begrenzen. Wenn also im Ausschreiben vom Bund drinsteht, dass haufenweise Akteure leicht massenhaft Zugriff haben sollen (privatwirtschaftliche Forschung und so) kannst du nicht viel machen.