Ungelöst Logins mit "Browser: node"
-
Seit neuestem sehe ich im Log viele normale User-Logins mit "Browser: node". Früher war das churchtools-mobile-ios, churchtools-mobile-ios, Mozilla, ...
Was steckt dahinter? Sind da irgendwelche KI-Funktionen auf dem Smartphone/PC am Laufen, die den Traffic kapern?
Was machen diese Dinger? Gehen da ChurchTools-Daten automatisch an irgendwelche KI-Provider?
Ist das legal? Kann man das gezielt abschalten? -
@gbahr node klingt für mich erstmal nach eine node-Applikation. Node muss erstmal gar nichts mit KI zu tun habe.
ChurchTools Logins (web, app) sollten dies so eigentlich nicht anzeigen. Ich muss aber tatsächlich intern nachfragen, was sich hier in der App geändert hat.
-
@hbuerger Du hast Recht, dass das nicht unbedingt was mit KI zu tun haben muss - könnte aber. Deshalb frage ich.
Ich fand die Nennung des Browsers und Betriebssystems übrigens gar nicht so schlecht. Das habe ich für eine Browser-Statistik genutzt. Außerdem kann man bei Fehlerberichten schnell sehen, ob der User per App oder per Desktop unterwegs war. -
Inzwischen habe ich mal Claude (KI) gebeten mir mal zu erläutern, was denn der Browser "node" sein könnte.
Vermutlich Node.js - genauer gesagt die eingebaute fetch()-Funktion (basiert auf undici), verfügbar ab Node 18+. Wenn man damit einen Request ohne eigenen User-Agent-Header schickt, setzt Node standardmäßig einfach den User-Agent-String auf "node", statt der üblichen "Mozilla/5.0 ..."-Strings von Browsern.
TLS schützt zwar die Übertragung zwischen Client und Server vor Mitlesen auf dem Transportweg – aber das sagt nichts darüber aus, was die Node.js-Anwendung selbst mit den Daten macht.
Was TLS garantiert:
Verschlüsselung zwischen Node.js-Prozess und Server, solange Zertifikatsprüfung korrekt läuft.Was TLS NICHT garantiert:
Node.js selbst sieht die Daten immer im Klartext, da TLS auf Anwendungsebene terminiert. Der Node-Prozess ist kein neutraler Kanal, sondern hat vollen Zugriff auf alles, was er sendet/empfängt.
Das eigentliche Risiko bei Node.js ist der npm-Dependency-Tree: Eine typische Node-App zieht oft Hunderte transitive Abhängigkeiten. Ein kompromittiertes oder bösartiges Paket (Supply-Chain-Angriff) könnte Daten mitlesen, loggen oder an Dritte exfiltrieren - unabhängig davon, wie sauber die eigentliche TLS-Verbindung ist.
Logging, Crash-Reporter, Analytics-SDKs innerhalb der App können Daten ungewollt weiterleiten.Mobilspezifisch:
"Node.js auf dem Mobiltelefon" ist meist kein natives Node (iOS/Android haben das nicht eingebaut), sondern läuft z.B. via nodejs-mobile, Cordova/Capacitor-Plugin oder Termux (Android). Diese Umgebungen haben oft schwächere OS-Sandbox-Eigenschaften als reguläre native Apps - Zugriff auf Dateisystem, andere Prozesse etc. kann anders geregelt sein.
Zertifikatsspeicher und Pinning-Verhalten unterscheiden sich je nach Einbettung, das lohnt sich im Einzelfall zu prüfen.Bleibt für mich die Frage, wie ist das datenschutzrechtlich zu bewerten? Kann man den Usern bestimmte Auflagen bezüglich Node.js oder bezüglich KI-Nutzung machen?
-
@gbahr Inzwischen haben wir herausgefunden woran es liegt. Wenn sich die App bei dem Chat anmeldet, meldet sich der Chat einmal in dem ChurchTools-System per Login-Token an, um zu überprüfen, ob die Zugangsdaten auch stimmen. Dafür haben wir eine kleine Node.js-Anwendung geschrieben, die sich für den Chat in das ChurchTools-System einloggt und - wie Claude es sagt - bei dem fetch keinen User-Agent gesetzt und daher taucht das in den Logs mit browser: node auf. Es ist also nicht direkt die App, aber wird dadurch getriggert, dass sich die App im Chat einloggt.
Eine KI ist hier nicht im Einsatz und es ist auch sicherheitstechnisch keine Gefahr oder datenschutzrechtlich kein Problem, da es sich um unsere eigenen Systeme handelt.
In Zukunft sollte hier nicht mehr browser: node stehen, sondern
churchtools-chat-auth, damit auch klar ist, was genau das auslöst
