Strumenti per sviluppatori

Cosa incolla la gente in un decodificatore Base64, in ordine di frequenza: un JWT, un’intestazione di Basic Auth, il payload di un webhook, un file di configurazione. Tre casi su quattro sono credenziali o le contengono. Una pagina che decodifichi tutto questo su un server le ha già viste, e le ha nei log delle richieste, che qualcuno lo volesse o no.

Non è un’obiezione teorica. È il motivo per cui questo intero genere di siti è bloccato dal proxy in parecchie aziende, e per cui dove non lo è di solito esiste una policy che nessuno legge. Tutto quello che sta in queste pagine è aritmetica che un browser sa fare da solo; portarla altrove è una scelta, ed è quella sbagliata.

La pagina è HTML statico servito da una CDN. Al primo tasto premuto viene caricato un piccolo modulo JavaScript, una volta e poi dalla cache, e il lavoro avviene nella tua scheda. Nessuna richiesta porta con sé quello che hai scritto, e questo si verifica nel pannello di rete invece di crederci sulla parola.

Due limiti detti per intero. La pagina in sé è una richiesta, quindi il fatto che tu sia stato qui è visibile a noi e alla tua rete. E il sito ha pubblicità e, se accetti, statistiche: nessuna delle due vede il contenuto di un campo di testo, ma entrambe sono richieste verso terzi. La differenza è quella fra quello che scrivi e il fatto che tu sia qui: la prima cosa non si muove mai, la seconda per forza sì.

Se i dati non escono dal dispositivo non c’è comunicazione verso di noi e quindi nemmeno un trattamento affidato a un responsabile esterno per quello che incolli. Nella pratica è il punto decisivo quando nel campo finiscono un’anagrafica cliente, un ticket di assistenza o un payload con dati personali, ed è il motivo per cui questi strumenti si possono usare dove una versione con server non si potrebbe.

Quello che invece succede sta nell’informativa e qui non viene addolcito: la visita, le richieste di pubblicità e statistiche, il consenso. Che uno strumento calcoli in locale non rende neutro l’intero sito — toglie soltanto la parte che pesa di più, che è anche l’unica su cui il Garante avrebbe qualcosa da dire riguardo al contenuto di un campo.

Una pagina sola che risolvesse Base64, URL e HTML nei due sensi dietro un selettore sarebbe meno pagine e peggiori. Codificare e decodificare falliscono in modi diversi, si spiegano in modo diverso e si cercano in modo diverso: chi ha davanti una sequenza percentuale rotta e chi sta montando una query non hanno quasi niente da dirsi.

Così ogni verso ha la sua pagina, con gli errori che le appartengono: cosa fare quando il Base64 si scioglie in byte che non sono testo, perché `encodeURIComponent` lascia passare il punto esclamativo e cosa combina questo a una firma OAuth. Da lì esce una pagina che merita di essere letta, e succede solo perché non parla a sei pubblici insieme.

Una volta caricata la pagina di uno strumento, tutto avviene in locale: funziona in treno, in aereo e dietro un proxy aziendale che blocchi il dominio un’ora dopo. Non viene installato nessun service worker e non c’è niente da configurare; una pagina che non chiama mai fuori semplicemente non ha niente da perdere quando la connessione sì.

In concreto vuol dire che questi strumenti servono proprio nelle situazioni in cui uno strumento online sarebbe la scelta sbagliata: su una macchina non tua, su una rete di cui non ti fidi, con dati che in realtà non dovresti spostare. È per quel caso che sono fatti.

Non c’è niente da registrare perché non c’è niente da amministrare. Gli strumenti non conservano nulla fra due visite: chiudere la scheda cancella quello che avevi scritto, perché non è mai esistito da nessun’altra parte se non in quella scheda.

Non c’è nemmeno un limite di quantità, e non per generosità: il tuo tempo di calcolo non lo paghiamo noi, quindi non c’è niente da razionare. L’unico tetto è quanto testo il tuo browser è disposto a tenere in un campo.

In queste pagine c’è scritto payload, token, hash, query string e Base64 — non carico utile, gettone, impronta o stringa di interrogazione. Non è pigrizia: è la lingua in cui si parla di queste cose nei team italiani e quella in cui si cerca su Google.

Dove invece la parola corrente è italiana, si usa quella: carattere, riga, colonna, rientro, a capo, accento. La regola non è «più italiano possibile» ma «la parola che si dice davvero a voce»; qualunque altra scelta produce una pagina tradotta correttamente e che non trova nessuno.

Non c’è nessun formattatore di HTML, CSS o JavaScript, ed è una decisione, non un buco. Uno fatto bene ha bisogno di un parser vero; le librerie che si usano per questo pesano diversi megabyte e sarebbero una scelta di licenza e di tempo di caricamento a sé stante, mentre una fatta in casa rovina input in silenzio. Il formattatore JSON è innocuo solo perché quel parser il browser ce l’ha già dentro.

Manca anche un’anteprima di Markdown o di HTML. Entrambe vorrebbero dire renderizzare markup altrui dentro questa pagina, che è esattamente ciò che la pagina per decodificare le entità HTML rifiuta di fare, con le sue ragioni, perché un parser del genere può provocare richieste di rete. Un argomento valido su una pagina non si può ignorare su quella dopo.