u/pgtaboada

nicht per E-Mail. Telefonisch. Und wir werden eine Ausweiskontrolle per Zoom vereinbaren.

Melde dich doch bitte einfach beim Support.
Wir können aktuell keine neue Konten ohne Validierung freischalten.

Die Ironie ist angekommen – und deine Sorge nehmen wir ernst. Danke auch für deine Bereitschaft, für mehr Unabhängigkeit höhere Kosten mitzutragen.

Ja, aktuell speichern wir die Daten bei AWS in Deutschland. Der Standort ist ein wichtiger Baustein, aber für sich allein keine Garantie für Datenhoheit.

Wir treffen die notwendigen Vorkehrungen zur Verschlüsselung. Die Schlüssel sind durch Hardware-Sicherheitsmodule geschützt und lassen sich auch von uns nicht einfach auslesen. Wer eine Festplatte aus dem Rechenzentrum mitnimmt, kann die darauf gespeicherten Daten deshalb nicht einfach lesen. Einen Angriff „von innen“ kann man nie zu hundert Prozent ausschließen – unsere Architektur setzt ihm aber hohe technische Hürden. Dass der US-Präsident nur ein Wort sagen müsste und damit sämtliche PatientInnendaten auf dem Bildschirm hätte, greift deshalb deutlich zu kurz.

Auch ein rein deutsches Rechenzentrum wäre nicht gegen jedes denkbare Szenario gefeit. Die hypothetischen „Endgegner“ wären dann eben der BND oder das Finanzamt – um deine Ironie aufzugreifen. Auch hier können Behörden unter bestimmten Voraussetzungen Hardware beschlagnahmen. Genau deshalb gehört Verschlüsselung unabhängig vom Standort dazu. Eine Infrastruktur, die garantiert jedem gezielten Angriff eines Nachrichtendienstes standhält, können wir allerdings weder seriös versprechen noch mit vertretbarem Aufwand finanzieren.

Was uns aktuell konkret beschäftigt, ist der geopolitische Druck: Was passiert, wenn politische Entscheidungen den Betrieb amerikanischer Cloud-Dienste in Europa einschränken oder ihre Verfügbarkeit gefährden? Dieses Risiko haben wir bereits zu Beginn der aktuellen Trump-Amtszeit identifiziert und ein größeres Migrationsprojekt angestoßen.

Nach längerer Recherche haben wir uns für die AWS European Sovereign Cloud entschieden. Dahinter steckt mehr als ein anderes Rechenzentrum: Die grundlegende Technik und die Verschlüsselungsverfahren bleiben vergleichbar, aber der organisatorische, rechtliche und betriebliche Rahmen wird stärker in Europa verankert. Die Infrastruktur ist von den bisherigen AWS-Regionen getrennt, wird durch Gesellschaften in Deutschland betrieben und liegt operativ in den Händen von Personal in der EU. Sie ist darauf ausgelegt, ohne kritische Abhängigkeiten von Infrastruktur außerhalb der EU weiterzulaufen.

Die Zugehörigkeit zu Amazon bleibt bestehen. Es ist also keine vollständige Unabhängigkeit von einem US-Konzern, aber aus unserer Sicht eine deutliche Verbesserung gegenüber der heutigen Situation.

Der Umzug ist auf etwa zwei Jahre geschätzt. Unser Ziel ist, bis Ende 2027 fertig zu sein. Ein großer Teil der Arbeit besteht darin, die Anwendung überhaupt umzugsfertig zu machen. Rund 110 Millionen Objekte, knapp acht Terabyte Daten und Millionen Datenbankeinträge schiebt man nicht mal eben auf eine neue Infrastruktur. Gleichzeitig muss der Praxisbetrieb weiterlaufen. Mehrere Tage offline zu sein, können wir uns nicht leisten – und genau das macht die Migration so aufwendig.

Wir haben auch eine vollständig deutsche Alternative geprüft. Nach unserer Kalkulation wären der dafür notwendige Umbau und der anschließende Betrieb allerdings so teuer, dass wir unsere Gebühren ungefähr verdreifachen müssten, um kostendeckend zu arbeiten.

Aber auch der gewählte Weg ist finanziell alles andere als einfach: Für die European Sovereign Cloud rechnen wir mit etwa 50 Prozent höheren Infrastrukturkosten – zusätzlich zu den Kosten der Migration. Das bedeutet nicht automatisch 50 Prozent höhere Gebühren, aber es ist für uns eine erhebliche zusätzliche Belastung. Wie wir das wirtschaftlich auffangen, macht uns heute noch echte Bauchschmerzen.

Deine Bereitschaft, dafür mehr zu bezahlen, wissen wir deshalb sehr zu schätzen. Wir nehmen das Thema ernst und investieren bereits konkret in den Umzug. Darauf, dass politische Entscheidungsträger unsere Datenhoheit schon respektieren werden, möchten wir uns jedenfalls nicht verlassen.

There are many ways to troll… :)

And I won’t lose any sleep over it. ;)

Yes, and on the browser side it gets even messier: we depend on end users keeping things updated, and we all have stories about how well that goes.

On the server side, there’s at least the hope that updates get deployed faster, just as with PHP. But that’s still only a hope. The larger the installed base, the more systems there will be whose operators simply don’t update them.

Sorry, I probably wasn’t clear enough. My point isn’t about PHP, JavaScript, or any particular language. I was trying to say that getting updates deployed quickly and consistently is the real challenge. I should have said that directly.

My point is that this isn’t specific to PHP. The challenge is getting updates deployed fast enough. A broad installed base simply means more systems that won’t be patched in time—or at all. As exploitation gets faster and cheaper, I expect more systems to be compromised.

It’s not as though we trust the internet today. But moving from “the internet is hostile” to “assume anything you interact with could already be compromised” is a pretty serious escalation.

No, I’m not suggesting switching languages or avoiding popular ones. PHP’s reach affects the scale of the potential fallout; popularity itself isn’t the problem.

My concern is how quickly exploitation could happen with AI assistance, combined with how casually many of us have treated updates over the years. That applies to any stack. Switching languages won’t fix it, and “just keep everything updated” understates the operational challenge.

I agree that this applies to any widely deployed stack. My point is that AI-assisted exploitation could make the window between disclosure and exploitation much smaller. Any RCE could become a serious problem very quickly.

The casual attitude many of us have taken toward updates over the years—with some notable exceptions—is what worries me. “Just keep everything updated” sounds simple, but consistently doing it fast enough is the real challenge.

That’s not the point. Nobody is claiming other languages are immune to RCE vulnerabilities. The issue is the speed and scale of AI-assisted exploitation—and how cheap it can become. PHP is everywhere, giving attackers an enormous target base.

“Other languages have bugs too” doesn’t address that, and neither does “just keep everything updated.” You can’t assume patching will always outrun exploitation.

Ich sehe sie noch...

https://preview.redd.it/i298tg24unvh1.png?width=656&format=png&auto=webp&s=09e2048be66b2daa27bcabd43de3ca0d7e37de1a

Hast du vielleicht nicht die notwendige Berechtigung?

Bei lemniscus liegt unser Fokus auf den Belegen, die direkt zu den einzelnen Transaktionen gehören. Für weitere Praxisunterlagen wie Verträge, Kontoauszüge und sonstige Dokumente braucht es ergänzend eine passende Ablage.

Eine GoBD-konforme Archivierung geht dabei deutlich über das Hochladen und Speichern von Dateien hinaus: Unterlagen müssen unter anderem vor unbemerkten Änderungen geschützt, dauerhaft verfügbar und nachvollziehbar aufbewahrt werden. Dazu gehören auch dokumentierte Abläufe. Eine einfache Cloud-Ablage allein reicht dafür also nicht aus.

Eine solche Dokumentenarchivierung wäre deshalb ein größeres, eigenständiges Projekt, das wir derzeit nicht angehen möchten. Unser Fokus bleibt auf den Funktionen rund um die Praxisverwaltung und die zugehörigen Transaktionsbelege.

Den Vorwurf, wir würden grundsätzlich die Verantwortung auf unsere Nutzenden abschieben, weisen wir zurück. Zum angesprochenen Fall möchten wir den Ablauf klarstellen:

Die ursprüngliche Frage war, ob es eine Lösung für das Problem mit Google AdWords und lemniscus gibt. Wir haben auf die entsprechende Anleitung im Helpdesk verwiesen und damit diese Frage beantwortet.

Erst anschließend wurde nach der Verfügbarkeit im Abo M gefragt. Unsere Antwort darauf war eindeutig: Die beschriebene Lösung ist ausschließlich im Abo XL verfügbar. Dass sie im Abo M nicht zur Verfügung steht, ist eine Einschränkung unseres Angebots. Dafür trägt die Kundin keine Verantwortung.

Wir haben sowohl den konkreten Vorgang als auch unsere Abläufe überprüft. Wir halten daran fest, die gestellten Fragen zu beantworten und für weiterführende Informationen auf unseren Helpdesk zu verweisen. Wir werden weder jede denkbare Anschlussfrage vorwegnehmen noch verlinkte Anleitungen zusätzlich in Tickets kopieren. Diese Arbeitsweise ermöglicht uns eine effiziente Kundybetreuung und trägt dazu bei, lemniscus zu den aktuellen Konditionen anbieten zu können.

Bei dieser Vorgehensweise kann es passieren, dass Informationen überlesen werden. Auch wir übersehen etwas oder verstehen eine Eingangsfrage ganz anders, als sie gemeint war. Nicht selten müssen wir ein zweites Mal nachfragen, um sicherzugehen, dass wir das Anliegen richtig verstanden haben. Auf beiden Seiten sitzen Menschen, und auf beiden Seiten können Missverständnisse entstehen. Entscheidend ist, dass wir sie gemeinsam klären können, ohne daraus eine Schuldfrage zu machen.

Wurde bisher nicht gefragt, da hätte man einfach auf Reddit sich anmelden müssen und kommentieren.

Hab beides eingetragen.

Wir haben nicht die Kapazitäten für Entwicklung, Test und Wartung.

https://www.reddit.com/r/lemniscus/comments/1wg348e/vorschläge_ans_lemniscusteam_eine_kurze_erinnerung/

Das ist eine Frage an ein Steueraberaty.

Blind in den Raum gerufen:

- Gewerbe
- Nummernkreis
- Eigene Rechnung