Tools aan de clientzijde en gegevensprivacy: waar uw pasta daadwerkelijk naartoe gaat

Jarenlange ondersteuning voor WordPress-plug-ins heeft me een slechte gewoonte geleerd. Een klant stuurt u een kapotte geserialiseerde optie-blob, u moet het lezen alsidd, dus je plakt het in de eerste online unserializer die Google je geeft Ik deed dit lang zonder erover na te denken - tot de dag dat ik keek naar wat I' net geplakt had Het was een klant' s wp_options exporteren. Het bevatte hun SMTP-wachtwoord, een MailChimp API-sleutel en een licentiesleutel. Het was allemaal net op een server gepost waar ik niets van wist, gerund door iemand die ik niet kon noemen, in een land dat ik niet kon raden.

Er is niets ergs gebeurd, voor zover ik weet. Dat' is het verontrustende deel - ik kan het niet weten. There' is geen melding voor "uw pasta is gelogd." De gegevens stonden ofwel in iemand's toegangslogboeken of het deed't, en I' zullen nooit ontdekken welke.

Dat incident is een groot deel van de reden waarom Toolz.dev werkt zoals het werkt Elk van de 50 tools op de site verwerkt uw invoer in uw browser Niet & quot; we beloven dat we het verwijderen na verwerking" - het wordt nooit verzonden in de eerste plaats Deze gids legt het verschil uit tussen die twee architecturen, waarom het belangrijker is voor ontwikkelaars dan voor bijna iedereen, en hoe je een tool kunt verifiëren's beweert jezelf in ongeveer 30 seconden En, aangezien ik uiteindelijk die klantenknop ergens veilig heb geplakt, beweert de PHP-onserializer Dat verving mijn slechte gewoonte.

tl;dr: Hulpmiddelen aan de serverzijde verzenden uw invoer naar iemand anders's machine, waar deze kan worden gelogd, bewaard, geschonden of gedeeld - en u kunt ' t een van deze controleren Hulpmiddelen aan de clientzijde verzenden u de code en verwerken alles lokaal; verificatie neemt één DevTools Network-tabbladcontrole voor alles wat inloggegevens bevat - JWT's, wp-config waarden, verbindingsreeksen, API-reacties - gebruik tools aan de clientzijde zoals de JSON-formatter, JWT-decoder, SQL-formatter, en YAML-validator. Alles op Toolz.dev wordt uitgevoerd in de browser.

Wat gebeurt er eigenlijk als je in een online tool plakt?

Er zijn precies twee architecturen en elke online tool gebruikt er een.

Server-side: Uw invoer reist van uw browser naar de server van de tool, wordt daar verwerkt en het resultaat reist terug. Vijf stappen en uw gegevens bestaan ​​in de infrastructuur van iemand anders tijdens drie van hen.

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

Klantenkant: uw browser downloadt de tool' s JavaScript één keer, en dan gebeurt alles - invoer, verwerking, uitvoer - in een tabblad op uw machine Het enige dat ooit het netwerk heeft gekruist was de code.

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

Het onderscheid klinkt academisch totdat je opsomt wat er kan gebeuren met gegevens op een server die je don' t-besturing Het kan terechtkomen in toegangslogboeken en applicatielogboeken Het kan worden vastgelegd door fouttrackers zoals Sentry, welke snapshot-verzoekcontext wanneer iets gooit Het kan lang na de operator "deleted" het. Het kan door elke medewerker met logtoegang worden gelezen. Het kan in een inbreuk worden meegesleurd. En met verschillende "gratis tool" operators, het kan het daadwerkelijke product zijn - in geld uitgedrukt via analyses of verkocht als trainingsgegevens.

Geen van deze vereisten kwaadaardigheid. Alleen standaard logboekconfiguraties alleen doen het meeste. De operator van die unserializer die ik gebruikte, heeft waarschijnlijk nooit naar het SMTP-wachtwoord van mijn klant gekeken. Maar "waarschijnlijk" is geen veiligheidshouding.

Waarom is dit een grotere deal voor ontwikkelaars dan voor iemand anders?

vanwege wat we plakken. Een gemiddelde gebruiker plakt een alinea tekst in een woordteller. Een ontwikkelaar pasta:

API-antwoorden met live tokens. U' debugt een integratie, u kopieert het hele antwoord - headers inbegrepen - en formatteert het om het te lezen Dat Authorization: Bearer ... Header ging gewoon waar de formatter woont. GitsGuardians Staat van geheimen Sprawl onderzoek vond ongeveer 12,8 miljoen geheimen die in openbare GitHub-toezeggingen in 2023 alleen al werden onthuld Niemand publiceert equivalente nummers voor online tools, omdat in tegenstelling tot GitHub, tool operators' logs aren't publiekelijk scanbaar zijn Dat' is niet geruststellend - het betekent dat het lekoppervlak onzichtbaar is.

JWT. Een JSON Web Token is base64url-gecodeerd, niet gecodeerd - RFC 7519 is hier expliciet over. De payload van elk token dat u in een server-side decoder plakt, geeft de gebruikers-ID, e-mail, rollen en vervaldatum. Als het token nog steeds geldig is, hebt u mogelijk een werksessie-referentie overhandigd. decodeer ze lokaal met de JWT-decoder in plaats daarvan.

SQL met echte gegevens erin. De query die u opmaakt, heeft een WHERE email = '[email protected]' clausule erin, en de tabelnamen schetsen uw hele schema. de SQL-formatter Houdt dat in je tabblad.

config-bestanden. wp-config.php waarden, .env inhoud, Kubernetes manifesteert, database.yml- configuratie is waar inloggegevens leven. I' heb YAML-bestanden gevalideerd die elk geheim bevatten dat mijn Laravel-app had. Dat' is een pasta die je door een clientzijde wilt laten gaan YAML-validator, geen formulierbericht.

Geserialiseerde WordPress-gegevens. Mijn persoonlijke ondergang, volgens de intro. WordPress slaat opties en metadata op als PHP-geserialiseerde strings, en het debuggen ervan betekent dat ze niet worden geserialiseerd - de PHP-onserializer Doet het zonder dat uw klantgegevens uw machine verlaten.

Een onzorgvuldige pasta van een van deze categorieën is een beveiligingsincident dat niemand ooit zal detecteren, rapporteren of opschonen.

Hoe verifieer je dat een tool eigenlijk client-side is?

Dit is het deel dat ik het leukst vind aan client-side architectuur: U hoeft niemands privacybeleid te vertrouwen. De claim is mechanisch verifieerbaar.

1. Open de pagina van de tool.
2. Open DevTools (F12) → netwerk Tab. Check "Behoud log."
3. Plak enkele herkenbare testgegevens in - MY-SECRET-TEST-12345 werkt - en voer de tool uit.
4. Bekijk de lijst met verzoeken.

Als de tool aan de clientzijde is, ziet u de initiële paginabelasting en statische activa, en dan helemaal niet wanneer u verwerkt Als een verzoek wordt afgevuurd wanneer u op de knop converteren/formatteren/verwerken drukt, filtert u de verzoeken en inspecteert u de payloads voor uw teststring. 'M gevonden? Serverzijde Klaar - dat duurde een halve minuut, en u weet nu meer over die tool dan het privacybeleid u ooit zou vertellen.

Twee eerlijke opmerkingen over Toolz.dev, omdat dit aan twee kanten snijdt. Ten eerste laadt de site analyses voor het aantal paginaweergaves en volgt het dat er werd een tool gebruikt - voor gebruikslimieten - maar nooit welk een je stopt het. Voer de netwerkcontrole zelf uit; de invoer verschijnt nooit in een verzoek. Ten tweede heeft de clientzijde een echte beperking: uw browser doet het werk, dus een videotranscode van 4 GB isn't gebeurt op een tabblad. Voor de categorie tools van de formatter/converter/encoder is modern JavaScript echter meer dan snel genoeg - meestal sneller dan de serverzijde, omdat er & #39; helemaal geen retourvlucht uploadt.

Server-side vs client-side: de rechte vergelijking

Wat zegt de AVG hierover?

I' Ik ben een ontwikkelaar, geen advocaat, behandel dit dus als een technische context in plaats van als juridisch advies - maar de hoofdlijnen zijn van belang voor iedereen die met EU-gebruikersgegevens omgaat.

beneden Verordening (EU) 2016/679 (AVG), als u persoonsgegevens - een klant' s export ondersteunt, een API-antwoord met gebruikersrecords - en deze door een server van een derde partij pusht' s, die derde partij verwerkt persoonsgegevens namens u Artikel 28 zegt dat een gegevensverwerkingsovereenkomst vereist Vraag uzelf af hoeveel gratis online formatters een DPA aanbieden Ik heb er nog nooit een gezien.

Client-side tools omzeilen de hele vraag, niet door slimme juridische redactie maar door architectuur: geen gegevens bereiken de provider, dus er is geen verwerking door derden om over te papier Data minimalisatie (artikel 5 (1) (c)) is voldaan op de meest letterlijke manier mogelijk - de hoeveelheid van uw gegevens die de provider verzamelt is nul Dezelfde logica helpt met HIPAA (gezondheidsgegevens bereiken nooit een niet-conforme server), SOC 2 audits (geen niet-doorgelichte subprocessor in het datapad), en PCI DSS.

Voor alle duidelijkheid: het gebruik van client-side tools maakt niet Uw product GDPR-conform Het verwijdert één specifiek en verrassend veelvoorkomend lek in uw ontwikkelingsworkflow - het lek waarbij een ontwikkelaar, die probeert behulpzaam te zijn op een supportticket, persoonlijke gegevens in een willekeurige website plakt.

Welke taken mogen nooit een server aanraken?

Mijn persoonlijke triage, gesorteerd op hoeveel een lek zou pijn doen:

Nooit server-side - bevat of impliceert inloggegevens:

• API-antwoorden en payloads opmaken: JSON-formatter
• Decoderingsfiches: JWT-decoder, Base64-converter
• Opmaakvragen: SQL-formatter
• Configuratie valideren: YAML-validator
• Debugging WordPress-gegevens: PHP-onserializer
• Hashen en vergelijken van waarden: Hash-generator
• Genereren van referenties: Wachtwoordgenerator, UUID-generator

Geef sterk de voorkeur aan de clientzijde - eigendomsrecht maar niet geheim:

• Diffing interne code of contracten: tekst diff, JSON-differentiatie
• Regex testen tegen productieloglijnen: regex-tester
• Tijdstempels converteren uit logboeken en tokens: tijdstempel converter
• Interne screenshots comprimeren: afbeeldingscompressor

Lage inzet, maar client-side is nog steeds gewoon sneller:

• Woordtellingen: woord teller
• Tijdelijke aanduiding tekst: Lorem ipsum-generator
• Kleuren en gradiënten: kleurenkiezer, Gradiëntgenerator

Er is een langere doorloop van de volledige gereedschapskist in de Handleiding voor productiviteitstools voor en de Handleiding voor coderingshulpmiddelen.

Als u echt een tool aan de serverzijde nodig heeft - een zware conversie zonder lokaal alternatief - kunt u eerst opschonen. Wissel echte sleutels in voor YOUR_API_KEY, echte e-mails voor [email protected]. Het is 60 seconden aan zoeken en vervangen die een mogelijk incident in een non-event verandert.

Waarom zijn de meeste online tools server-side eigenlijk?

Gedeeltelijk geschiedenis, deels incentives In 2010 waren browsers ' t tot aan de klus - zware verwerking moest gebeuren op een server Die beperking is verdwenen: moderne JavaScript-engines en WebAssembly verwerken formattering, conversie, hashing en beeldcompressie met snelheden die niet te onderscheiden zijn van native, en browser-API's (File, Canvas, Web Crypto) dekken de I/O.

De prikkels zijn het lastiger probleem Met verwerking aan de serverzijde kan een operator het gebruik in detail zien, limieten nauwkeurig afdwingen, de verwerkingslogica bedrijfseigen houden en - in het ergste geval - de gegevens zelf als inkomsten behandelen Een tool die uw gegevens nooit ontvangt, kan & # 39; t geld verdienen met uw gegevens, en dat is precies de reden waarom sommige operators & # 39; de architectuur niet willen, ook al is het & # 39; nu technisch eenvoudig.

Toen ik de tools voor Toolz.dev bouwde, was de client-side eigenlijk de eenvoudiger Engineeringkeuze, niet alleen de meer privé: geen verwerkingsservers op schaal, geen uploads naar beveiligd, geen bewaarbeleid om te schrijven, en elke tool werkt identiek in de web-app en de desktop-app omdat de logica gewoon platformonafhankelijk Typescript is. Het privacyverhaal en het technische verhaal wijzen in dezelfde richting. Het is zeldzaam als dat gebeurt; pak de overwinning.

Veelgestelde vragen

Wat betekent "cliënt-side verwerking" eigenlijk?

Alle berekeningen gebeuren in uw browser, in JavaScript (of WebAssembly), op uw apparaat. De enige rol van de server is het leveren van de tool's code wanneer de pagina wordt geladen. Uw invoer verschijnt nooit in een netwerkverzoek, dat u kunt bevestigen op het tabblad DevTools Network.

Hoe controleer ik of een tool client-side is?

Open DevTools (F12) → Netwerktabblad, schakel " logboek bewaren, & quot; plak herkenbare testgegevens in de tool en verwerk deze Als er geen verzoek met uw teststring wordt afgevuurd, is de tool client-side. Op Chrome kunt u DevTools ook overschakelen naar " Offline" na het laden van de pagina - een echte tool aan de clientzijde blijft werken.

Zijn client-side tools langzamer dan server-side tools?

Voor typische ontwikkelaarstaken zijn ze & #39; sneller - there& #39; s geen upload, geen wachtrij, geen download Het lokaal verwerken van een JSON-bestand van 2 MB is vrijwel onmiddellijk, terwijl een retourvlucht van de server bij elke stap latentie toevoegt. De uitzondering is zware berekeningen (grote videotrancodes, bestanden op gigabyteschaal), waarbij een krachtige server een browsertabblad verslaat.

Verzamelt Toolz.dev überhaupt iets?

Pagina-view analytics en anonieme per-tool gebruik telt (gebruikt voor tarieflimieten) - maar nooit de inhoud die u verwerkt Invoer, uitvoer, en geüploade bestanden blijven in uw browser Dit is verifieerbaar met de Network tab check in plaats van iets dat u moet nemen op geloof.

Is het plakken van een JWT in een online decoder echt riskant?

Ja, meer dan de meeste ontwikkelaars aannemen Volgens RFC 7519 zijn JWT-payloads gecodeerd, niet gecodeerd - iedereen die het token vasthoudt, kan de claims lezen, en als het token is verlopen't, kan het bruikbaar zijn als live-referentie. Als je er een in een decoder aan de serverzijde plakt, wordt een mogelijk geldig sessietoken naar een onbekende derde partij verzonden. Gebruik een decoder aan de clientzijde.

Maakt het gebruik van client-side tools mij GDPR-compatibel?

Geen enkele toolkeuze maakt u compliant. Wat de tools aan de clientzijde verwijderen, is een specifiek risico: persoonsgegevens van uw systemen die een niet-gevestigde externe verwerker bereiken (waarvoor een artikel 28-gegevensverwerkingsovereenkomst nodig is die u vrijwel zeker niet hebt met een gratis toolsite). Uw eigen productverplichtingen worden niet beïnvloed.

Kan mijn werkgever zien wat ik verwerk in client-side tools?

Netwerkmonitoring ziet welke sites u bezoekt, niet wat u typt in een client-side tool - there' s geen verzoek met uw invoer om te observeren Eindpuntmonitoring geïnstalleerd op het apparaat zelf (schermopname, keyloggers) ziet alles ongeacht de toolarchitectuur, dus het eerlijke antwoord is: niet via het netwerk, mogelijk via het eindpunt.

Wat als er geen alternatief voor de clientzijde is voor mijn taak?

Ontsmet voor het plakken: Vervang inloggegevens door tijdelijke aanduidingen (YOUR_API_KEY), wissel echte persoonlijke gegevens uit voor dummy-waarden, strip hostnamen en interne URL's. Controleer vervolgens het privacybeleid van het tool voor logboek- en bewaartaal, geef de voorkeur aan open-sourcetools die u kunt inspecteren en behandel "gratis, closed-source, server-side" als de combinatie met het hoogste risico.

Wat is het verschil tussen client-side en server-side tools?

Client-side tools verzenden code naar uw browser en voeren deze daar uit; server-side tools verzenden uw gegevens naar een machine die u don' t bestuurt en daar uitvoert Functioneel kan de uitvoer identiek zijn - het verschil gaat volledig over wie uiteindelijk uw invoer vasthoudt Met een server-side tool bestaan uw gegevens, hoe kort ook, op iemand anders' s schijf, in hun logs en in hun back-ups.

Zijn online JSON-formatters en verfraaiers veilig te gebruiken?

Het hangt af van de implementatie, niet van de categorie JSON formatteren is triviaal om te doen in JavaScript, dus een client-side formatter heeft geen reden om iets te verzenden - en de Network tab check regelt het in tien seconden Wees hier voorzichtiger dan gebruikelijk, want de JSON ontwikkelaars plakken in formatters is onevenredig API reacties met tokens, e-mailadressen, en interne ID's.