• Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics
    • All categories
    • Timothy SchöttenT

      Unsolved Deaktivierung Erinnerungsmails Follow-Ups

      Fragen
      • • • Timothy Schötten
      5
      3
      Votes
      5
      Posts
      145
      Views

      A

      @JulianeS am besten in dem oben verlinkten Feature Request voten

    • gbahrG

      Unsolved Logins mit "Browser: node"

      Fragen
      • • • gbahr
      4
      0
      Votes
      4
      Posts
      108
      Views

      gbahrG

      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?