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 jetztAlso fügen Sie es in den ersten Online-Unserialisierer ein, den Google Ihnen gibt. Ich habe das lange Zeit gemacht, ohne darüber nachzudenken - bis zu dem Tag, an dem ich mir ansah, was I' d gerade eingefügt hat Es war ein Kunde's 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. That's der beunruhigende Teil - ich habe keine Möglichkeit zu wissen. There's keine Benachrichtigung für " Ihr Einfügen wurde protokolliert." Die Daten saßen entweder in jemandem's Zugriffsprotokolle oder es war 't und I' werden nie herausfinden, welche.

Dieser Vorfall ist ein großer Teil der Gründe, warum Toolz.dev so funktioniert, wie es funktioniert. Jedes der 50 Tools auf der Website verarbeitet Ihre Eingabe in Ihrem Browser. Not " 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 jeden anderen und wie man ein Tool überprüft. & #39;s behauptet sich selbst in etwa 30 Sekunden. Und da ich diesen Kundenklumpen schließlich an einem sicheren Ort eingefügt habe, ist der PHP-Untergeordneter Das hat meine schlechte Angewohnheit ersetzt.

tl; dr: Serverseitige Tools übertragen Ihre Eingaben an eine andere Person' s-Maschine, wo sie protokolliert, aufbewahrt, durchbrochen oder geteilt werden können - und Sie können ' t verifizieren irgendetwas davon Clientseitige Tools liefern Ihnen den Code und verarbeiten alles lokal; die Verifizierung erfordert eine DevTools Network-Tab-Prüfung. 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 einmal das Tool' s JavaScript herunter, und dann passiert alles - Eingabe, Verarbeitung, Ausgabe - in einem Tab auf Ihrem Computer Das Einzige, was jemals das Netzwerk durchquert hat, 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 nutzen & #39; t steuern Sie kann in Zugriffsprotokollen und Anwendungsprotokollen landen Sie kann von Fehlertrackern wie Sentry erfasst werden, welcher Snapshot-Anfragekontext, wenn etwas wirft Es kann in Backups lange nach dem Operator "deleted" es kann von jedem Mitarbeiter mit Protokollzugriff gelesen werden Es kann in einer Bresche nach oben gekehrt werden Und mit mehreren & quot; free tool" Betreibern kann es das eigentliche Produkt sein - durch Analysen monettiert oder als Schulungsdaten verkauft werden.

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. You' Wenn Sie eine Integration debuggen, kopieren Sie die gesamte Antwort - Header enthalten - 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-Verpflichtungen aufgedeckt wurden. Niemand veröffentlicht gleichwertige Zahlen für Online-Tools, denn im Gegensatz zu GitHub sind Tooloperatoren' Protokolle sind't öffentlich scannbar. That's ist nicht beruhigend - es bedeutet, dass die Leckoberfläche unsichtbar ist.

JWTs. Ein JSON Web Token ist base64url-kodiert, 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 der Ort, an dem Anmeldeinformationen leben. I' hat YAML-Dateien validiert, die jedes Geheimnis enthielten, das meine Laravel-App hatte. That's ein Paste, das Sie durch eine Client-Seite 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, sie zu unserialisieren - 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. Einfügen einiger erkennbarer Testdaten - MY-SECRET-TEST-12345 Funktioniert - und das Tool ausführen.
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 Anfrage beim Drücken der Konvertieren/Format/Prozess-Taste ausgelöst wird, filtern Sie die Anfragen und prüfen Sie die Nutzlasten auf Ihre Testzeichenfolge Gefunden? serverseitig Fertig - das hat eine halbe Minute gedauert, und Sie wissen jetzt mehr über dieses Tool, als es Ihnen seine Datenschutzerklärung 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 Tool wurde - für Nutzungsgrenzen - verwendet, aber nie was Sie setzen in es Führen Sie die Netzwerkprüfung selbst; die Eingabe erscheint nie in einer Anfrage Zweitens, Client-Seite hat eine echte Einschränkung: Ihr Browser macht die Arbeit, so dass ein 4 GB Video-Transcode ist' nicht in einem Tab passiert Für die Formatierer/Konverter/Encoder Kategorie von Tools, obwohl, modernes JavaScript ist mehr als schnell genug - normalerweise schneller als serverseitig, weil dort's überhaupt keinen Upload-Rundtrip.

Server- und Client-Seite: Der gerade Vergleich

Was sagt die DSGVO dazu aus?

I' Ich bin Entwickler und kein Anwalt. Betrachten Sie dies also eher als technischen Kontext als als Rechtsberatung - aber die Gliederung ist für jeden wichtig, der mit EU-Benutzerdaten umgeht.

unter Verordnung (EU) 2016/679 (DSGVO), wenn Sie personenbezogene Daten - einen Kunden' s unterstützen den Export, eine API-Antwort mit Benutzerdatensätzen - und durch einen Server eines Dritten pushen's, dass ein Dritter personenbezogene Daten in Ihrem Namen verarbeitet Artikel 28 besagt, dass eine Datenverarbeitungsvereinbarung erforderlich ist Fragen Sie sich, wie viele kostenlose Online-Formatierer eine DPA anbieten Ich habe noch nie eine gesehen.

Clientseitige Tools umgehen die ganze Frage, nicht durch geschicktes juristisches Redaktionsschreiben sondern durch Architektur: keine Daten gelangen zum Anbieter, es gibt also keine Verarbeitung durch Dritte zum Überpapieren Datenminimierung (Artikel 5 (1) (c)) wird auf möglichst wörtliche Weise befriedigt - die Menge Ihrer Daten, die der Anbieter erhebt, ist gleich Null Die gleiche Logik hilft bei HIPAA (Gesundheitsdaten erreichen nie einen nicht konformen Server), SOC 2-Audits (kein ungeprüfter Subprozessor im Datenpfad), und PCI DSS.

Um es klar zu machen: Die Verwendung von clientseitigen Tools macht nicht Ihr Produkt DSGVO-konform Es entfernt ein spezifisches und überraschend häufiges Leck in Ihrem Entwicklungsworkflow - das, bei dem ein Entwickler, der versucht, auf einem Support-Ticket hilfreich zu sein, personenbezogene 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

Ziehen Sie die Client-Seite stark vor - 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 umfangreiche Konvertierung ohne lokale Alternative - bereinigen Sie zuerst 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?

Teilweise Geschichte, teilweise Anreize Im Jahr 2010 waren Browser & #39; t bis zum Auftrag - auf einem Server musste eine umfangreiche Verarbeitung erfolgen Diese Einschränkung ist weg: Moderne JavaScript-Engines und WebAssembly verarbeiten Formatierung, Konvertierung, Hashing und Bildkomprimierung mit Geschwindigkeiten, die nicht von nativen zu unterscheiden sind, und Browser-APIs (Datei, Leinwand, Web-Krypto) decken die E/A ab.

Die Anreize sind das Stickier-Problem Durch die serverseitige Verarbeitung kann ein Bediener die Nutzung im Detail sehen, Grenzen präzise durchsetzen, die Verarbeitungslogik proprietär halten und - im schlimmsten Fall - die Daten selbst als Einnahmen behandeln Ein Tool, das Ihre Daten nie empfängt, kann & #39; t Ihre Daten monetarisieren, weshalb einige Betreiber die Architektur nicht wollen & #39; obwohl it& #39; s 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) → Netzwerk-Tab, aktivieren Sie & quot; Protokoll bewahren, & quot; fügen Sie erkennbare Testdaten in das Tool ein, und verarbeiten Sie diese Wenn keine Anfrage mit Ihrer Testzeichenfolge ausgelöst wird, ist das Tool clientseitig Auf Chrome können Sie DevTools auch auf & quot; Offline" nach dem Laden der Seite - ein echtes clientseitiges Tool funktioniert weiter.

Sind clientseitige Tools langsamer als serverseitige Tools?

Für typische Entwickleraufgaben sind sie' schneller - da' s kein Upload, keine Warteschlange, kein Download Die lokale Verarbeitung einer 2-MB-JSON-Datei ist nahezu sofort möglich, während ein Server-Roundtrip bei jedem Schritt Latenz hinzufügt. Die Ausnahme bildet eine umfangreiche Berechnung (große Videotranscodes, Dateien im Gigabyte-Maßstab), bei der ein leistungsstarker Server einen Browser-Tab schlägt.

Sammelt Toolz.dev überhaupt etwas?

Seitenansicht-Analysen und anonyme pro-Tool-Nutzungszahlen (wird für Ratenbegrenzungen verwendet) - aber niemals der Inhalt, den Sie verarbeiten Eingabe, Ausgabe und hochgeladene Dateien bleiben in Ihrem Browser Dies ist mit der Registerkartenprüfung 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 annehmen Per RFC 7519 sind JWT-Nutzlasten codiert, nicht verschlüsselt - jeder, der das Token hält, kann die Ansprüche lesen, und wenn das Token ' t abgelaufen ist, kann es als Live-Anmeldeinformation verwendet werden Einfügen eines in einen serverseitigen Decoder überträgt ein möglicherweise gültiges 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?

Die Netzwerküberwachung sieht, welche Websites Sie besuchen, nicht, was Sie in ein clientseitiges Tool eingeben - dort's keine Anfrage, die Ihre Eingaben zur Beobachtung enthält Die auf dem Gerät selbst installierte Endpunktüberwachung (Bildschirmerfassung, Keylogger) sieht alles unabhängig von der Toolarchitektur, daher lautet die ehrliche Antwort: 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 versenden Code an Ihren Browser und führen ihn dort aus; serverseitige Tools versenden Ihre Daten an eine Maschine, die Sie don' t steuern und dort ausführen Funktionell kann die Ausgabe identisch sein - der Unterschied besteht ausschließlich darin, wer Ihre Eingabe am Ende hält Mit einem serverseitigen Tool existieren Ihre Daten, wie kurz auch immer, auf einer anderen'-Festplatte, in deren Protokollen und in deren Backups.

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

Es kommt auf die Implementierung an, nicht auf die Kategorie, JSON zu formatieren ist in JavaScript trivial, daher hat ein clientseitiger Formatierer keinen Grund, etwas zu übertragen - und die Registerkarte Netzwerk legt es in zehn Sekunden fest Seien Sie hier vorsichtiger als sonst, denn die JSON-Entwickler fügen in Formatierer unverhältnismäßig viele API-Antworten ein, die Token, E-Mail-Adressen und interne IDs enthalten.