Clientseitige Tools und Datenschutz: Wohin Ihre Paste tatsächlich geht

Jahrelange WordPress-Plugin-Unterstützung lehrte mich eine schlechte Angewohnheit. Ein Kunde sendet Ihnen einen defekten serialisierten Optionsblob. Sie müssen ihn lesen jetzt, So fügen Sie es in den ersten Online-Unterserializer ein, den Google Ihnen gibt. Ich habe das lange gemacht, ohne darüber nachzudenken - bis zu dem Tag, an dem ich mir das angesehen habe, was ich gerade eingefügt habe. Es war ein Kunde wp_options exportieren Es enthielt ihr SMTP-Passwort, einen MailChimp-API-Schlüssel und einen Lizenzschlüssel. Alles war gerade auf einen Server postiert, von dem ich nichts wusste, von jemandem geführt, den ich nicht nennen konnte, in einem Land, das ich nicht erraten konnte.

Soweit ich weiß, ist nichts Schlimmes passiert. Das ist der beunruhigende Teil - ich habe keine Möglichkeit zu wissen. Es gibt keine Benachrichtigung für "Ihre Einfügung wurde protokolliert". Die Daten befanden sich entweder in den Zugriffsprotokollen oder nicht, und ich werde nie herausfinden, welche.

Dieser Vorfall ist ein großer Teil dessen, warum Toolz.dev so funktioniert. Jedes der 50 Tools auf der Website verarbeitet Ihre Eingaben in Ihrem Browser. Nicht "Wir versprechen, dass wir es nach der Verarbeitung löschen" - es wird nie übertragen. Dieser Leitfaden erklärt den Unterschied zwischen diesen beiden Architekturen, warum es für Entwickler wichtiger ist als für fast alle anderen und wie man sich in etwa 30 Sekunden selbst behauptet. Und da ich diesen Kundenfleck schließlich an einem sicheren Ort eingefügt habe, PHP-Untergeordneter Das hat meine schlechte Angewohnheit ersetzt.

tl; dr: Serverseitige Tools übertragen Ihre Eingaben an die Maschine eines anderen, auf der sie protokolliert, aufbewahrt, verletzt oder freigegeben werden kann - und Sie können keine davon überprüfen. Client-seitige Tools senden Ihnen den Code und verarbeiten alles lokal, die Überprüfung erfolgt über eine DevTools-Netzwerk-Registerkarte. Für alles, was Anmeldeinformationen enthält - JWTs, wp-config Werte, Verbindungszeichenfolgen, API-Antworten – Verwenden Sie clientseitige Tools wie die JSON-Formater, JWT-Decoder, SQL-Formater, und YAML-Validatordrohen Alles auf toolz.dev läuft im Browser.

Was passiert eigentlich, wenn Sie in ein Online-Tool einfügen?

Es gibt genau zwei Architekturen, und jedes Online-Tool verwendet eine davon.

Serverseitig: Ihre Eingabe wird von Ihrem Browser zum Server des Tools übertragen, dort verarbeitet und das Ergebnis zurückgegeben. Fünf Schritte, und Ihre Daten sind während dreier von ihnen auf der Infrastruktur einer anderen Person vorhanden.

Your browser → network → their server → network → your browser
   (input)     (transit)  (processing,    (transit)   (result)
                           logging?,
                           retention?)

Kundenseitig: Ihr Browser lädt das Tool einmal Javascript herunter, und dann geschieht alles - Eingabe, Verarbeitung, Ausgabe - in einer Registerkarte auf Ihrem Computer. Das einzige, was jemals das Netzwerk durchquerte, war der Code.

Their server → your browser
   (code)       (input + processing + result, all local)

Die Unterscheidung klingt akademisch, bis Sie auflisten, was mit Daten auf einem Server passieren kann, den Sie nicht steuern. Es kann in Zugriffsprotokollen und Anwendungsprotokollen landen. Es kann von Fehler-Trackern wie Sentry erfasst werden, die den Kontext des Snapshot-Anforderungskontexts beim Auslösen von etwas auslösen. Es kann in Backups lange nach dem "gelöschten" Benutzer gespeichert werden. Es kann von jedem Mitarbeiter mit Log-Zugriff gelesen werden. Es kann in einem Bruch überwältigt werden. Und mit mehreren "kostenlosen Tool"-Betreibern kann es sich um das eigentliche Produkt handeln - durch Analytik monetarisiert oder als Trainingsdaten verkauft.

Keines davon erfordert Bosheit. Allein Standard-Protokollierungskonfigurationen erledigen das meiste. Der Betreiber dieses Untererializers, den ich benutzt habe, hat sich wahrscheinlich nie das SMTP-Passwort meines Kunden angesehen. Aber "wahrscheinlich" ist keine Sicherheitslage.

Warum ist das für Entwickler eine größere Sache als für andere?

Wegen dem, was wir einfügen. Ein durchschnittlicher Benutzer fügt einen Textabsatz in einen Wortzähler ein. Ein Entwickler-Pasten:

API-Antworten mit Live-Token. Wenn Sie eine Integration debuggen, kopieren Sie die gesamte Antwort - einschließlich der Überschriften - und formatieren sie, um sie zu lesen. das Authorization: Bearer ... Der Header ging einfach überall dort, wo der Formatierer lebt. Gitguardian Zustand der Geheimnisse Untersuchungen ergaben, dass allein im Jahr 2023 etwa 12,8 Millionen Geheimnisse in öffentlichen GitHub-Begehen offengelegt wurden. Niemand veröffentlicht äquivalente Nummern für Online-Tools, da Tool-Operatoren im Gegensatz zu GitHub nicht öffentlich scannbar sind. Das ist nicht beruhigend - es bedeutet, dass die Leckoberfläche unsichtbar ist.

JWTs. Ein JSON-Web-Token ist base64URL-codiert, nicht verschlüsselt — RFC 7519 ist diesbezüglich explizit. Die Nutzlast jedes Tokens, den Sie in einen serverseitigen Decoder einfügen, übergibt die Benutzer-ID, E-Mail, Rollen und den Ablauf. Wenn der Token noch gültig ist, haben Sie möglicherweise einen Arbeitssitzungsnachweis übergeben. Dekodieren Sie sie lokal mit dem JWT-Decoder stattdessen.

SQL mit echten Daten darin. Die Abfrage, die Sie formatieren, hat eine WHERE email = '[email protected]' Klausel darin und die Tabellennamen skizzieren Ihr gesamtes Schema. der SQL-Formater Hält das in Ihrer Registerkarte.

Konfigurieren von Dateien. wp-config.php Werte, .env Inhalt, Kubernetes-Manifeste, database.yml — Konfiguration ist dort, wo die Anmeldeinformationen wohnen. Ich habe YAML-Dateien validiert, die jedes Geheimnis enthielt, das meine Laravel-App hatte. Das ist eine Paste, die Sie durch eine Kundenseite gehen möchten YAML-Validator, kein Formularbeitrag.

serialisierte WordPress-Daten. Mein persönlicher Untergang, laut Intro. WordPress speichert Optionen und Metadaten als PHP-serialisierte Zeichenfolgen und das Debuggen bedeutet, dass sie nicht serialisiert werden - die PHP-Untergeordneter Geht es ohne die Daten Ihres Kunden, die Ihre Maschine verlassen.

Eine unvorsichtige Paste aus einer dieser Kategorien ist ein Sicherheitsvorfall, den niemand jemals erkennen, melden oder bereinigen wird.

Wie überprüfen Sie, ob ein Tool tatsächlich clientseitig ist?

Dies ist der Teil, den ich am meisten an der clientseitigen Architektur mag: Sie müssen nicht auf die Datenschutzrichtlinie von jemandem vertrauen. Der Anspruch ist mechanisch nachprüfbar.

1. Öffnen Sie die Seite des Tools.
2. DevTools (F12) öffnen → Netz Tabulator Überprüfen Sie "Protokoll" aufbewahren.
3. Fügen Sie einige erkennbare Testdaten ein — MY-SECRET-TEST-12345 funktioniert - und führen Sie das Tool aus.
4. Sehen Sie sich die Anfrageliste an.

Wenn das Tool clientseitig ist, sehen Sie das anfängliche Laden der Seite und statische Assets und dann nichts Wenn Sie verarbeiten. Wenn eine Anforderung ausgelöst wird, wenn Sie die Schaltfläche Konvertieren / Formatieren / Prozessieren, filtern Sie die Anfragen und überprüfen Sie die Nutzlasten für Ihre Testzeichenfolge. Fund es gefunden? Serverseitig. Fertig - Das hat eine halbe Minute gedauert, und Sie wissen jetzt mehr über dieses Tool, als Ihnen die Datenschutzrichtlinie jemals sagen würde.

Zwei Ehrlichkeitshinweise über toolz.dev, da dies in beide Richtungen schneidet. Zunächst lädt die Website Analysen für die Seitenansicht und verfolgt das Ein Werkzeug wurde verwendet - für Nutzungsgrenzen - aber nie was du hast es eingelegt. Führen Sie die Netzwerkprüfung selbst aus, der Eingang erscheint nie in einer Anfrage. Zweitens hat die Client-Seite eine echte Einschränkung: Ihr Browser erledigt die Arbeit, sodass ein 4-GB-Videotranscode in einem Tab nicht geschieht. Für die Formatierung/Konverter/Encoder-Kategorie von Tools ist modernes JavaScript jedoch mehr als schnell genug – normalerweise schneller als serverseitig, da es überhaupt keine Upload-Rundfahrt gibt.

Server- und Client-Seite: Der gerade Vergleich

Was sagt die DSGVO dazu aus?

Ich bin ein Entwickler, kein Anwalt. Behandeln Sie dies eher als technischer Kontext als als Rechtsberatung - aber die Gliederung ist für jeden wichtig, der mit den EU-Nutzerdaten umgeht.

unter Verordnung (EU) 2016/679 (DSGVO), wenn Sie personenbezogene Daten – den Support-Export eines Kunden, eine API-Antwort mit Benutzerdatensätzen – nehmen und diese über einen Server eines Drittanbieters übertragen, verarbeitet dieser Dritte in Ihrem Namen personenbezogene Daten. Artikel 28 besagt, dass eine Datenverarbeitungsvereinbarung erforderlich ist. Fragen Sie sich, wie viele kostenlose Online-Formateure eine DPA anbieten. Ich habe noch nie einen gesehen.

Client-seitige Tools umgehen die ganze Frage, nicht durch cleveres Rechtszeichnen, sondern durch Architektur: Keine Daten erreichen den Anbieter, so dass keine Verarbeitung durch Dritte auf Papier überarbeitet wird. Die Datenminimierung (Artikel 5 Absatz 1 Buchstabe c) wird so buchstäblich erfüllt – die Menge Ihrer Daten, die der Anbieter sammelt, ist Null. Die gleiche Logik hilft bei HIPAA (Health-Daten erreichen nie einen nicht-kompatiblen Server), SOC 2-Audits (kein unberechenter Subprozessor im Datenpfad) und PCI-DSS.

Um es klar zu machen: Die Verwendung von clientseitigen Tools macht nicht Ihr Produkt DSGVO-konform. Es beseitigt ein bestimmtes und überraschend häufiges Leck in Ihrem Entwicklungsworkflow - das, bei dem ein Entwickler, der versucht, auf einem Support-Ticket hilfreich zu sein, persönliche Daten in eine zufällige Website einfügt.

Welche Aufgaben sollten niemals einen Server berühren?

Meine persönliche Triage, sortiert nach, wie sehr ein Leck schmerzen würde:

Niemals serverseitig – Enthält oder impliziert Anmeldeinformationen:

• Formatieren von API-Antworten und Payloads: JSON-Formater
• Dekodierungs-Token: JWT-Decoder, Base64-Konverter
• Formatierungsabfragen: SQL-Formater
• Konfigurationen überprüfen: YAML-Validator
• Debuggen von WordPress-Daten: PHP-Untergeordneter
• Hashing und Vergleichswerte: Hash-Generator
• Anmeldeinformationen generieren: Passwort-Generator, UUID-Generator

Bevorzugt Client-Seite - proprietär, aber nicht geheim:

• Unterschiede in internen Codes oder Verträgen: Textdiff, json diff
• Testen von Regex gegen Produktionsloglinien: Regex-Tester
• Konvertieren von Zeitstempel aus Protokollen und Token: Zeitstempelkonverter
• Komprimieren von internen Screenshots: Bildkompressor

Geringe Einsätze, aber clientseitig ist immer noch schneller:

• Wortzählungen: Wortzähler
• Platzhaltertext: Lorem Ipsum Generator
• Farben und Farbverläufe: Farbpflücker, Gradientengenerator

Es gibt eine längere Komplettlösung des vollen Werkzeugkastens in der Handbuch für Entwicklerproduktivitätstools und das Anleitung für die Coding-Toolsdrohen

Wenn Sie wirklich ein serverseitiges Tool benötigen - eine schwere Konvertierung ohne lokale Alternative - müssen Sie zuerst bereinigen. Tauschen Sie echte Schlüssel gegen YOUR_API_KEY, echte E-Mails für [email protected]drohen Es sind 60 Sekunden des Findens und Ersetzens, die einen potenziellen Vorfall in ein Nichtereignis verwandelt.

Warum sind die meisten Online-Tools überhaupt serverseitig?

Teils Geschichte, teils Anreize. Im Jahr 2010 waren Browser nicht auf dem neuesten Stand - auf einem Server musste eine schwere Verarbeitung stattfinden. Diese Einschränkung ist weg: Moderne JavaScript-Engines und WebAssembly-Handle Formatierung, Konvertierung, Hashing und Bildkomprimierung mit Geschwindigkeiten, die von nativen und Browser-APIs (Datei, Canvas, Web-Krypto) nicht zu unterscheiden sind, decken die E / A ab.

Die Anreize sind das klebrigere Problem. Die serverseitige Verarbeitung ermöglicht es einem Bediener, die Verwendung im Detail zu sehen, Grenzen genau zu erzwingen, die Verarbeitungslogik proprietär zu halten und - im schlimmsten Fall - die Daten selbst als Umsatz zu behandeln. Ein Tool, das Ihre Daten niemals erhält, kann Ihre Daten nicht monetarisieren, genau deshalb möchten einige Betreiber die Architektur nicht, obwohl sie jetzt technisch einfach ist.

Als ich die Tools für toolz.dev baute, war Client-Seite eigentlich die einfacher Engineering Choice, nicht nur privater: Keine skalierten Server, keine Uploads zu sicheren, keine Aufbewahrungsrichtlinien zu schreiben, und jedes Tool funktioniert in der Web-App und in der Desktop-App identisch, da die Logik ein einfaches plattformunabhängiges TypeScript ist. Die Datenschutzgeschichte und die technische Geschichte weisen die gleiche Richtung. Es ist selten, wenn das passiert; gewinne den Sieg.

Häufig gestellte Fragen

Was bedeutet eigentlich "Client-Side-Bearbeitung"?

Alle Berechnungen erfolgen in Ihrem Browser, in Javascript (oder WebAssembly), auf Ihrem Gerät. Die einzige Rolle des Servers ist die Bereitstellung des Tools-Codes beim Laden der Seite. Ihre Eingabe erscheint nie in einer Netzwerkanforderung, die Sie auf der Registerkarte DevTools Network bestätigen können.

Wie prüfe ich, ob ein Tool clientseitig ist?

Öffnen Sie DevTools (F12) → Registerkarte Netzwerk, aktivieren Sie "Protokoll" und fügen Sie erkennbare Testdaten in das Tool ein und verarbeiten Sie es. Wenn keine Anfrage, die Ihre Testzeichenfolge enthält, ausgelöst wird, ist das Tool clientseitig. Auf Chrome können Sie auch DevTools nach dem Laden der Seite auf "Offline" umstellen - ein echtes clientseitiges Tool funktioniert weiter.

Sind clientseitige Tools langsamer als serverseitige Tools?

Für typische Entwickleraufgaben sind sie schneller - es gibt keinen Upload, keine Warteschlange, keinen Download. Die lokale Verarbeitung einer JSON-Datei mit 2 MB ist nahezu sofort, während eine Server-Rundfahrt bei jedem Schritt die Latenz erhöht. Die Ausnahme ist eine starke Berechnung (große Videotranscodes, Gigabyte-Dateien), bei denen ein leistungsstarker Server einen Browser-Tab übertrifft.

Sammelt toolz.dev überhaupt etwas?

Seitenansicht-Analysen und anonyme Nutzung pro Werkzeug (für Tarifbeschränkungen verwendet) – aber niemals die Inhalte, die Sie verarbeiten. Eingegebene, ausgegebene und hochgeladene Dateien bleiben in Ihrem Browser. Dies ist mit der Registerkarte "Netzwerk" überprüfbar und nicht etwas, das Sie im Glauben annehmen müssen.

Ist das Einfügen eines JWT in einen Online-Decoder wirklich riskant?

Ja, mehr als die meisten Entwickler vermuten. Gemäß RFC 7519 werden JWT-Nutzdaten verschlüsselt und nicht verschlüsselt. Jeder, der den Token hält, kann die Ansprüche lesen, und wenn der Token nicht abgelaufen ist, kann er als Live-Anmeldeinformationen verwendet werden. Einfügen in einen serverseitigen Decoder überträgt einen möglicherweise gültigen Sitzungstoken an einen unbekannten Dritten. Verwenden Sie einen clientseitigen Decoder.

Macht es mich DSGVO-konform, clientseitige Tools zu verwenden?

Keine einzelne Werkzeugauswahl macht Sie konform. Was clientseitige Tools beseitigen, ist ein besonderes Risiko: Personenbezogene Daten von Ihren Systemen, die einen nicht überprüften Verarbeiter von Drittanbietern erreichen (was einen Datenverarbeitungsvertrag in Artikel 28 erfordern würde, den Sie mit ziemlicher Sicherheit nicht mit einer kostenlosen Tool-Website haben würden). Die Verpflichtungen Ihres eigenen Produkts bleiben unberührt.

Kann mein Arbeitgeber sehen, was ich in clientseitigen Tools verarbeite?

Network Monitoring sieht, welche Websites Sie besuchen, nicht die, die Sie in ein clientseitiges Tool eingeben - es gibt keine Anfrage, die Ihre Eingaben zu beobachten ist. Endpoint Monitoring auf dem Gerät selbst (Screen Capture, Keylogger) sieht unabhängig von der Werkzeugarchitektur alles, so dass die ehrliche Antwort lautet: nicht über das Netzwerk, möglicherweise über den Endpunkt.

Was ist, wenn es keine clientseitige Alternative für meine Aufgabe gibt?

Vor dem Einfügen desinfizieren: Ersetzen Sie Anmeldeinformationen durch Platzhalter (YOUR_API_KEY), tauschen Sie echte persönliche Daten gegen Dummy-Werte, Strip-Hostnamen und interne URLs aus. Überprüfen Sie dann die Datenschutzrichtlinie des Tools auf die Protokollierungs- und Aufbewahrungssprache, bevor Sie Open-Source-Tools, die Sie einsehen können, und behandeln Sie "Free, Closed-Source, Server-Side" als die risikoreichste Kombination.

Was ist der Unterschied zwischen clientseitigen und serverseitigen Tools?

Client-seitige Tools senden Code an Ihren Browser und führen ihn dort aus; serverseitige Tools senden Ihre Daten an einen Computer, den Sie nicht steuern und dort ausführen. Funktional kann die Ausgabe identisch sein - der Unterschied geht ausschließlich darum, wer Ihre Eingaben hält. Mit einem serverseitigen Tool sind Ihre Daten jedoch kurz auf der Festplatte eines anderen, in ihren Protokollen und in ihren Backups vorhanden.

Sind Online-JSON-Formateure und Verschönerer sicher zu verwenden?

Es kommt auf die Implementierung an, nicht auf die Kategorie. Das Formatieren von JSON ist in JavaScript trivial, daher hat ein clientseitiger Formatierer keinen Grund, etwas zu übertragen - und die Registerkarte "Netzwerk" regelt dies in zehn Sekunden. Seien Sie hier vorsichtiger als üblich, da die JSON-Entwickler in Formatierer überproportional API-Antworten enthalten, die Token, E-Mail-Adressen und interne IDs enthalten.