Quindi, è successo. L’ennesimo grafico che ci fa pensare che la rete mondiale stia finalmente respirando meglio. Google ha pubblicato i numeri e ha notato che la percentuale di traffico che transita su IPv6 ha superato il 50%. Su carta, è una vittoria epica. Significa che la crociata per liberarsi dalle carenze del maledetto IPv4 sta guadagnando terreno.

Ma fermiamoci un attimo. Voi che ci siete, e che passate notti a smanettare con protocolli che fanno sembrare l’IoT un gioco da ragazzi, sapete bene che i numeri, da soli, non bastano. Guardare un grafico ‘verde e ascendente’ è romantico, ma è come vedere un render di un circuitino senza aver mai saldato un singolo componente. La vera arte, come sempre, è l’implementazione.

Quando pensiamo all’IPv6, pensiamo al mega-salvataggio degli anni ’90. Il motivo è semplice e vitale: l’IPv4 è arrivato a mancare di indirizzi, e con l’esplosione dei dispositivi (e dei nerd che li collegano a un router inutilmente sofisticato), era una questione di tempo. IPv6 ha portato con sé quella sbalorditiva quantità di spazio di indirizzamento che ci permette di *non* preoccuparci, per almeno un secolo, di dove mettere il prossimo sensore IoT, o il prossimo piccolo server che gireremo su un Raspberry Pi dimenticato in un angolo del garage.

Detto questo, la storia della transizione è sempre la stessa commedia all’opera: il *vendor lock-in* e l’eccessiva complessità del mondo corporate. Tanti sistemi legacy (quelli che non si vogliono far toccare perché ‘funzionano’) sono ancora bloccati nel paradigma IPv4. Non è che il protocollo sia il nemico; è l’inerzia burocratica e il timore di dover rimettere a funzionare un firewall che sembra disegnato da un gatto ubriaco.

Cosa significa per noi, i *tinkerer*? Significa che, a livello di protocollo, abbiamo di nuovo spazio per giocare. Meno vincoli di subnet, meno calcoli di *CIDR* da fare per un progetto folle. Più spazio per la sperimentazione. È come passare da un set di matite colorate a un armadio intero di matite che non si sono mai finite. È liberatorio.

Per chi ci pensa da un punto di vista del *maker* o dello sviluppatore che butta ore a fare un gioco con Godot o a far girare un modulo CNC via rete, questo è un segnale che l’infrastruttura sta maturando verso un modello più scalabile e meno “patch-based”. Non significa però che domani smetteremo di dover fare un po’ di *troubleshooting* su uno stack di rete vecchio di dieci anni. Lontano dagli hype dei comitati che amano parlare di ‘sinergie’ e ‘ecosistemi’ che nulla ha a che fare con la realtà fisica di un cavo Ethernet.

In conclusione: se un grafico di traffico è un’iniezione di adrenalina per i project manager, per noi è un promemoria che i fondamenti stanno cambiando, e questo, mio caro amico, è sempre un argomento da smontare per capire dove e come stiamo *realmente* migliorando. Passate pure i numeri, noi continueremo a farli girare per vedere se resistono a un overflow di pacchetti malconci.

Source: IPv6 traffic crosses the 50% mark

Se c’è una cosa che mi fa sudare freddo da hacker, è quando un colosso come Google decide che sa come funziona la navigazione web. Siamo abituati a smontare le cose, a vedere il codice che c’è sotto il bel resto, ma a volte sembra che ci stiano mettendo delle cinghie per i polsi digitali.

L’ultima notizia è arrivata da Google Search: stanno rafforzando le policy anti-spam per un fenomeno che chiamano «back button hijacking». Spoiler: è una roba che fa impazzire chiunque abbia mai provato a fare un *tinkering* sul codice di un sito. In soldoni, si tratta di siti che interferiscono con il pulsante Indietro del tuo browser, rompendo l’aspettativa fondamentale dell’utente: clicchi Indietro e torni esattamente dove eri.

Il concetto è semplice, ma il dibattito è pesante. Questi siti, per qualche motivo (forse vogliono venderti un NFT che non ti serve, o magari vogliono che tu guardi una pubblicità su un argomento che non ti interessa), ti deviano la rotta. Invece di tornare alla pagina A, ti buttano sulla pagina B, o ti bombardano di raccomandazioni che non hai chiesto. Google dice che questo è un comportamento manipolatorio e, perciò, un’infrazione di «malicious practices».

E qui arrivo io, con la mia solita dose di cinismo da nerd. Naturalmente, quando sento parlare di «user experience» e «malicious practices» con quel tono quasi evangelico, mi viene da fare un colpo di tosse. È il classico *corporate-speak* che maschera un semplice desiderio di controllo algoritmico. Non è tanto che il pulsante Indietro sia magico, è che rappresenta la *libertà di errore* del web. Il bello di un sito, soprattutto per noi che amiamo fare esperimenti, è che a volte rompe, a volte ti porta fuori strada per un secondo, e va bene così. È il caos che ci ispira.

Per noi maker, hacker e sviluppatori, questo significa che il confine tra «interferenza utente» e «interazione creativa» si sta assottigliando pericolosamente. Siamo costretti a scrivere codice non solo per far funzionare un’idea, ma anche per dimostrare a un algoritmo che non stiamo manipolando l’utente. È un livello di *gatekeeping* che ci fa venire voglia di rispolverare il vecchio terminale e tornare al periodo d’oro del retrocomputing, quando l’unica cosa che contava era che il codice compilasse, punto.

Quindi, cosa fare? Per chi di noi sta lavorando a qualcosa di sperimentale, che magari sfrutta un *redirect* o un *event listener* un po’ più aggressivo per un effetto visivo o un *flow* narrativo complesso, preparatevi. Dovrete rivedere ogni singola linea di codice che tocca la navigazione utente. Non si tratta solo di pulizia tecnica, è un cambio di mentalità: il codice deve essere trasparente, prevedibile e, soprattutto, *non deve nasconderti nulla*.

In sintesi: il web si sta rendendo troppo ordinato. E se c’è una cosa che amo, è l’imprevedibilità. Ci vediamo nel *terminale*, dove le regole sono solo un suggerimento, non un decreto.

Source: A new spam policy for “back button hijacking”

Se dovessi riassumere il concetto di ‘supply chain attack’ con una sola analogia, ti direi che è come comprare un kit per costruire una macchina a CNC da un venditore di mercatino, e scoprire che tra i bulloni e i cavi è stata nascosta una bomba a orologeria con un timer impostato per il tuo login.

Non è un caso che l’ecosistema WordPress sia un anfiteatro meraviglioso, ma anche un gigantesco mercato nero di componenti non certificati. E proprio qui è successo l’ultima settimana. La storia che ha fatto il giro di Hacker News è un classico, ma mai noioso: qualcuno ha comprato trenta plugin WordPress, e non li ha solo installati, li ha *infettati*. Ha piantato un backdoor in ognuno di loro.

Quando si parla di cybersecurity, l’hype ci fa credere che i sistemi complessi siano intrinsecamente più sicuri, ma la realtà è che la complessità è solo un altro vettore di attacco. Questi plugin, che sono il pane quotidiano per milioni di siti, sono la nostra dipendenza digitale. E quando la dipendenza si basa su pezzi di codice scritti da gente che probabilmente ha fatto da principiante il suo primo progetto Pi, il rischio è altissimo.

Il punto non è tanto il *cosa* è stato fatto (un backdoor, un pezzo di codice malevolo che aspetta il momento giusto per farsi notare), quanto il *come* è successo. Questo attacco sfrutta un punto debole che è strutturale: la fiducia. Ci aspettiamo che un plugin, sviluppato magari da un freelance che vive in una stanza affittata e che ha solo comprato un abbonamento Premium a un’app di grafica, sia sicuro quanto il codice che scriveremmo noi con cura e test su un ambiente isolato.

E qui arriva il mio punto da smanettone: non dobbiamo guardare solo l’attaccante, dobbiamo guardare il modello. Lo sviluppo di piattaforme massive come WordPress si è trasformato in un gigantesco ‘vendor lock-in’ di codice esterno. È comodo, è veloce, ma è come costruire un super-robot con mille pezzi di LEGO trovati in garage diversi, senza mai sapere quale pezzo non è originale.

Cosa significa per noi che amiamo mettere le mani in pasta? Significa che la paranoia non è un optional, è un requisito minimo. Non basta più ‘aggiornare’ il sistema operativo; dobbiamo iniziare ad auditare ogni singola dipendenza, ogni singolo plugin, ogni singolo script che chiamiamo ‘comodo da usare’. Dobbiamo trattare ogni repository di codice esterno come se fosse un componente che stiamo per saldare a un circuito critico: analizzarlo, testarlo e, se possibile, farlo girare in un sandbox isolato.

Se vogliamo costruire sistemi robusti, dobbiamo abbandonare l’illusione che la popolarità garantisca la sicurezza. Un sistema deve essere forte quanto il suo anello più debole, e spesso quell’anello è un plugin “gratis e comodissimo” che nessuno si è preso la briga di controllare. Meglio spendere tempo a scrivere il codice di sicurezza noi stessi, che fare affidamento sulla benevolenza di un fornitore anonimo.

Source: Someone Bought 30 WordPress Plugins and Planted a Backdoor in All of Them