Qual è la cosa più pericolosa di una tecnologia? Non è il bug critico che fa crashare il sistema. È la comodità che ci fa ignorare completamente le fondamenta.

Se lavorate con cose che dovrebbero stare chiuse—dati finanziari, PII (Personally Identifiable Information), progetti di codici sorgenti, cosa mi dite—sapete quanto è facile che la nostra cieca fiducia nei big tech diventi un problema di sicurezza reale. E qui, c’è un caso recente che fa drizzare i peli sui polsi a chi ha mai dovuto *smontare* un servizio digitale per capire dove sta il punto debole.

Stiamo parlando di Fiverr, la piattaforma gig economy che ci mette in contatto con i bravi mestieri digitali. Il succo è questo: per processare PDF o immagini nei messaggi tra cliente e lavoratore, usano un servizio tipo Cloudinary. Il problema, ragazzi, non è che usano Cloudinary, ma *come* lo usano.

Invece di implementare URL ‘firmati’ (signed URLs) che scadono e che sono specifici per un utente e un contesto (la best practice, pensate all’analogia AWS S3!), hanno optato per URL pubblici. E non solo. I documenti sensibili – giuramenti fiscali, dati personali – sono stati serviti in modo tale da finire smistati nei risultati di Google, ricercabili con query semplicissime. Letteralmente, le tue finanze personali sono diventate contenuto web indexabile.

La cosa che mi fa sobbalzare, e che non è solo un bug da reportare, è il contesto aziendale. Parliamo di una piattaforma che sta comprando annunci su Google per la ricerca di ‘form 1234 filing’ (ad esempio), nonostante abbia chiari motivi per sapere che il work product risultante non è adeguatamente protetto, rischiando così di far violare normative come GLBA/FTC Safeguards Rule. È la perfetta miscela di negligenza finanziaria e colpevole ignoranza tecnica.

Per noi sgranocchiatori, maker e chi vive di passare le notti a debuggare circuiti o codice, questo è un classico monito. La tentazione di ‘semplicità’ e ‘zero manutenzione’ che offrono i servizi SaaS esterni è sempre un rischio. Non è che devi scrivere ogni singolo script di autenticazione, ma devi comunque capire se quel servizio, con la sua API magica, ti sta dando *effettivamente* un lucchetto da banca, o se ti sta solo dando un bel colore sulla faccia.

Il mio punto è: non farti abbindolare dalla patina di «semplicità» e «efficienza». Ogni volta che vedi una grande piattaforma che gestisce dati sensibili, chiediti con la lucidità di un ingegnere e il sospetto di un hacker: «Questo è accessibile solo con URL signed, o sono dei semplici bucket S3 aperti al mondo?». Se non sai rispondere, è un problema *loro*, non tuo.

Ricordiamoci che la sicurezza non è una funzione, è un processo. E la velocità non deve mai essere più importante della privacy. Trovate botto nel retrocomputing? Perfetto. Usatelo per qualcosa di *veramente* utile, non per far credere a tutti che i vostri dati siano in un cassaforte fatto di *cloud* generici.

Source: Tell HN: Fiverr left customer files public and searchable

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”