Una delle cose che sto notando sempre più chiaramente negli ultimi anni, ogni volta che si parla di “sicurezza digitale”, è che una parte crescente del problema non viene realmente risolta dalle aziende: viene semplicemente redistribuita sugli utenti finali.
In pratica, invece di costruire sistemi che siano davvero più sicuri senza trasformare la vita quotidiana in una procedura burocratica permanente, moltissime aziende stanno scaricando il costo operativo della sicurezza direttamente su chi usa i loro servizi.
Il risultato è che mantenere “vivi” i propri account sta lentamente diventando un lavoro a tempo pieno.
Non si tratta più soltanto di ricordare una password decente, o di evitare di cliccare sull’allegato nigeriano scritto in Comic Sans.
No.
Si tratta di gestire una vera e propria infrastruttura personale di autenticazione, recovery, dispositivi fidati, codici, PIN, app, backup, procedure d’emergenza e rituali pseudo-liturgici che cambiano da piattaforma a piattaforma, senza alcuna reale standardizzazione comprensibile agli esseri umani normali.
Per esempio: andate in ferie.
Scenario teoricamente semplice. Vi portate dietro il cellulare personale, magari volete persino disintossicarvi dal lavoro, lasciate a casa il telefono aziendale, il portatile, il desktop, il tablet secondario, il vecchio numero usato solo per certi account, e per due settimane vivete come una persona quasi normale.
Errore.
Perché al ritorno potreste scoprire che il vostro ecosistema digitale ha interpretato la vostra assenza come una forma di eresia.
L’account Apple, per esempio, può decidere di guardarti con sospetto perché hai osato spegnere o ignorare un dispositivo troppo a lungo. Non necessariamente ti blocca, ma spesso inizia quella sottile guerra psicologica fatta di verifiche, conferme, codici, richieste di autenticazione e processi di recovery che sembrano progettati da qualcuno convinto che l’utente medio sia contemporaneamente un criminale internazionale e un idiota.
E lì comincia il circo.
Password.
Poi password per accedere al sistema che custodisce le password.
Poi il PIN.
Poi il secondo PIN.
Poi l’app di autenticazione.
Ma attenzione: non sempre la stessa.
Perché alcuni vogliono Microsoft Authenticator, con il numerino da inserire come se stessi disinnescando una bomba nel 1997.
Altri vogliono Google Authenticator.
Altri ancora accettano TOTP standard, forse, ma solo se Mercurio è in ascendente e il browser non ha deciso di reinterpretare il protocollo secondo una propria religione locale.
Io, ingenuamente, mi ero persino illuso che una YubiKey potesse rappresentare una sorta di soluzione elegante, una chiave fisica, uno standard, qualcosa di razionale.
Ingenuità.
Perché nel meraviglioso mondo della sicurezza contemporanea, la stessa identica tecnologia viene chiamata con nomi diversi da siti diversi, browser diversi, sistemi diversi, e spesso implementata in modi così creativi da trasformare uno standard in una lotteria semantica.
Ogni piattaforma sembra avere un proprio dialetto esoterico della parola “sicurezza”.
E naturalmente non tutti accettano un password manager normale, perché sarebbe troppo semplice.
Alcuni siti hanno problemi col copia-incolla delle password, come se impedire una funzione basilare aumentasse davvero la sicurezza invece di aumentare semplicemente il numero di bestemmie.
Altri insistono per inviare richieste a “dispositivi fidati” che in quel momento sono magari a 800 chilometri di distanza, dentro uno zaino, spenti, o chiusi in un cassetto.
Per misteriose “ragioni di compatibilità”, ovviamente.
Poi ci sono quelli come Revolut, che ogni tanto sembrano svegliarsi una mattina e decidere che, senza alcuna ragione comprensibile all’utente, tu debba dimostrare di essere di nuovo tu.
Non perché sia successo qualcosa. Non perché ci sia stato un attacco.Semplicemente perché sì.
Perché qualche algoritmo ha avuto una visione mistica.
E così eccoti di nuovo a fotografare documenti, fare selfie biometrici, confermare email, SMS, codici, notifiche push e probabilmente, presto, analisi del sangue.
Il numero dei fattori di autenticazione continua infatti a crescere.
All’inizio era una password.
Poi due fattori. Poi tre. Sembrano le lamette dei rasoi da uomo.
A questo punto siamo sulla buona strada per un sistema in cui, per controllare il saldo del conto, serviranno:
password, PIN, OTP, email, riconoscimento facciale, impronta digitale, YubiKey, certificato notarile, giuramento feudale e forse un testimone oculare.
Presto dovrò probabilmente allevare piccioni viaggiatori per supportare il nuovo Pigeon Authentication Factor, in cui un colombo certificato volerà verso la mia abitazione con un codice scritto su pergamena crittografata.
E il punto davvero grottesco non è che la sicurezza sia inutile.
La sicurezza serve.
Eccome se serve.
Il problema è quando la complessità viene trasferita quasi interamente sull’utente, trasformando la protezione in una forma di manutenzione continua, stressante, opaca e spesso arbitraria.
Perché a quel punto non stai più costruendo sistemi sicuri.
Stai semplicemente esternalizzando il costo organizzativo della tua incapacità progettuale.
E, come spesso accade, a lavorare gratis per tenere in piedi il sistema… è il cliente.
Questa tendenza si sta verificando su scala globale, e anche piuttosto bene.
Nel senso che ormai, quando apriamo qualcosa su un cellulare, non siamo mai davvero certi che si aprirà e funzionerà normalmente.
Più probabilmente, ci verrà chiesto di verificare il nostro account.
E questo non cambia nemmeno se usate dei password manager.
I browser più comuni avranno il loro menu di autenticazione, e cercheranno di salvare loro la password, col risultato di rendere spesso terribilmente difficile la digitazione, specialmente sui cellulari.
Nel frattempo, le tastiere per cellulare tenderanno a diffidare del vostro password manager, trattandolo come qualcosa di potenzialmente sospetto, quasi fosse un possibile keylogger.
Come se non bastasse, nemmeno i siti web sono sempre friendly con i password manager.
E come se non bastasse ancora, le password devono seguire criteri sempre diversi da sito a sito, cosicché il vostro password manager finisca spesso per essere ostacolato proprio nel suo compito più logico: creare credenziali sicure e pratiche.
Alla fine, il risultato rischia di essere paradossale.
Vi ritroverete con una bella agendina con tutte le password.
Scritte sulla carta.
Tutto questo è fare sicurezza?
Assolutamente no.
Perché il problema è che ogni azienda, nel nome dell’“innovazione”, tende a crearsi il proprio metodo di fare “sicurezza”.
E l’utente, a quel punto, non può fare altro che trovare da qualche parte un modo per segnarsi tutti quei requisiti strani, diversi e spesso incompatibili tra loro.
Ognuno dirà che il proprio metodo è migliore.
Ma dal punto di vista dell’utente, proprio perché sono tutti diversi, il risultato finale è semplicemente il caos.
Inutile dire che se la cybersecurity diventa un business, e il business consiste nel vendere compliance invece che risolvere problemi, allora il problema stesso non può che esplodere. Perché, a quel punto, la questione non è più rendere davvero sicuri i sistemi, ma costruire un’intera economia basata sulla certificazione del fatto che si stiano seguendo procedure formalmente corrette. Le aziende, inevitabilmente, inizieranno prima di tutto a costringere tutti, internamente, a richiedere inutili certificazioni, professionali o globali. Oggi va di moda TISAX, un tempo era ISO27001, e naturalmente ce ne sono state e ce ne saranno ancora molte altre, ma alla fine tutto quello che queste certificazioni fanno davvero è certificare che si abbia a che fare con delle good practices, o delle best practices.
Che poi queste best practices siano realmente efficaci, è tutto da vedere. Anzi, spesso non lo sono affatto, tant’è vero che gli incidenti di sicurezza continuano. I data leak continuano. Le compromissioni continuano. Le violazioni continuano. E questo, di per sé, dovrebbe suggerire che tra il seguire formalmente una checklist e il rendere davvero sicuri dei sistemi esiste una differenza piuttosto sostanziale.
E così la vera domanda aziendale diventa inevitabilmente questa: “Non abbiamo idea di come rendere sicuri i nostri sistemi, la sicurezza costa, e come se non bastasse ora ci sono pure sanzioni per i data leak, e noi non vogliamo problemi. Che facciamo?”
Spalmiamo il problema sugli utenti, dice Spahlman, il supereroe che ha il potere di spalmare il problema sulla gente, e che può raggiungere la velocità di una liberatoria.
Ed è esattamente questo il paradigma. Non si risolve davvero il problema, non si elimina la complessità, non si costruisce necessariamente un sistema migliore: si redistribuisce il costo operativo, burocratico e psicologico sugli utenti finali.
Così, quando entrate in un sito web, non entrate davvero in un sito web. Avete un popup. E poi un secondo. E poi dovete accettare le condizioni. E poi dovete dire sì ai cookie. E poi magari dovete confermare altre preferenze, altri consensi, altre eccezioni, altri partner, altri legittimi interessi, in una sequenza che spesso sembra progettata non per informarvi davvero, ma per ottenere da voi una resa amministrativa.
Ormai entrare in un sito web somiglia sempre meno all’accedere a un servizio, e sempre più a una forma di invasione burocratica ad alta velocità. Un tempo si invadeva la Polonia con blitzkrieg e carri armati. Oggi si entra online con popup, checkbox, cookie banner e liberatorie. Cambiano gli strumenti, ma il principio resta sorprendentemente simile: avanzare rapidamente, occupare spazio, travolgere la resistenza e ottenere il consenso prima che il bersaglio abbia davvero il tempo o la pazienza di capire cosa stia succedendo.
Avrete notato che per entrare in questo blog non c’è alcun banner. Il motivo è semplice: il GDPR, contrariamente a quanto ormai sembra credere mezzo internet, non prescrive affatto quel circo permanente di popup, liberatorie, finestre invasive e configurazioni degne del pannello di controllo di una centrale nucleare.
Come mai? Il GDPR? No.
Il GDPR non li prescrive.
Non sono obbligatorie liberatorie preventive onnipresenti, non sono obbligatorie schermate isteriche, non sono obbligatorie configurazioni paranoiche piazzate all’ingresso come posti di blocco amministrativi, e non è obbligatorio praticamente nulla di tutto questo, almeno non nel modo in cui oggi viene presentato.
Il punto è molto più semplice: bisogna rispettare le norme sul trattamento dei dati.
Fine.
Il che significa che, nel momento in cui l’attività non è commerciale, non raccogliete tracker, non usate sistemi pubblicitari invasivi, non salvate log superflui, non profilate utenti e non accumulate dati inutili, il problema semplicemente si riduce enormemente.
Nel mio caso, per esempio, io non salvo praticamente alcun dato.
Quindi non devo mettere alcun banner, alcun popup, alcuna richiesta teatrale di consenso costruita più per scaricare responsabilità che per proteggere davvero qualcuno.
Perché il GDPR, in sostanza, non vi impone di trasformare ogni visitatore in un reduce da checkpoint aeroportuale.
Vi impone di trattare correttamente i dati, se li trattate.
E questa differenza, apparentemente banale, viene spesso sepolta sotto tonnellate di compliance performativa.
Il problema è che molte aziende, invece di minimizzare davvero la raccolta dei dati, preferiscono costruire giganteschi apparati di consenso che spesso servono più a legittimare la raccolta stessa che a limitarla.
E così nasce il paradosso.
Vi dicono che stanno “proteggendo la vostra privacy” facendovi cliccare attraverso ventiquattro menù, trentadue eccezioni, quarantotto fornitori terzi e una quantità di opzioni abbastanza ampia da far sembrare semplice la dichiarazione dei redditi.
Alcuni social, addirittura, consentono di “configurare la privacy” in maniera estremamente dettagliata.
Che suona benissimo, finché non vi fermate un secondo a fare i conti.
Perché se avete, per esempio, 24 voci configurabili singolarmente con risposta yes/no, avete due alla ventiquattro possibili configurazioni.
Cioè 16.777.216 combinazioni.
Milioni.
Più che sufficienti non a proteggervi semplicemente, ma a trasformare il vostro insieme di preferenze in una firma distintiva, una specie di impronta caratteriale statistica. In pratica, il modo in cui rispondete alle domande sulla privacy può diventare esso stesso uno strumento di profiling.
Cioè: vi profilano anche attraverso il modo in cui cercate di non farvi profilare.
E se questa cosa non fosse così perfettamente moderna, sarebbe quasi comica.
Perché a quel punto il paradosso è completo: il rituale costruito nominalmente per difendere la vostra privacy può, in certi casi, produrre ulteriori dati utili a distinguervi come categoria specifica.
Non è ridicolo?
Anzi, a pensarci bene, è quasi il riassunto perfetto dell’intera epoca digitale: trasformare persino la fuga dal problema in un nuovo input per il sistema.
Al centro di tutto questo c’è anche un’intera serie di superstizioni legali, cioè l’idea, ormai diffusissima, che Terms & Conditions interminabili, popup, banner, liberatorie e schermate di consenso costituiscano una qualche forma di protezione reale. In realtà, in caso di violazioni accertate del GDPR, né i vostri Terms & Conditions né il vostro popup vi proteggerebbero davvero da azioni legali. Sono, nella sostanza, assolutamente inutili rispetto al problema concreto.
Se state trattando dati in modo illecito o irresponsabile, il fatto che qualcuno abbia cliccato “accetto” davanti a un muro di testo non vi salva magicamente. Eppure è stato fatto credere a tutti che queste cose servano davvero, sia perché possono risultare utili a profilare ulteriormente gli utenti che perdono tempo nei settings, sia per la catastrofica ignoranza di moltissimi gestori di siti, convinti che basti mettere una liberatoria per trasformare qualsiasi pratica discutibile in conformità. Ma non proteggono nessuno.
Ma perche' il problema sembra essere peggiorato molto negli ultimi anni, con il barocco del MFA che sta raggiungendo il ridicolo?
Succede da quest’anno in EU le cose hanno iniziato davvero a cambiare, ma va anche detto con precisione di quale norma si stia parlando, perché qui non si tratta del solito slogan burocratico: la questione centrale è la nuova Product Liability Directive, cioè la Direttiva (EU) 2024/2853, entrata formalmente in vigore nel dicembre 2024, con applicazione pratica ai prodotti immessi sul mercato dopo il recepimento nazionale previsto entro il 9 dicembre 2026. In altre parole, non è che “da domani cambia tutto”, ma il paradigma legale è già stato riscritto, e i produttori hanno ora una finestra temporale per adeguarsi.
Detta in chiaro, il punto davvero grosso è che il software, gli aggiornamenti software, certi servizi digitali integrati, sistemi AI e componenti digitali vengono trattati sempre più esplicitamente come prodotti, non come entità metafisiche sospese nel vuoto giuridico. Questo significa che il produttore di software, soprattutto quando il software è parte di un ecosistema commerciale o di un prodotto distribuito, assomiglia sempre meno a un semplice “fornitore di servizio con T&C creative” e sempre più a un produttore industriale normale, con responsabilità molto più concrete per danni causati da difetti, inclusi difetti di cybersecurity rilevanti.
Il punto che interessa davvero, e che molti stanno sottovalutando, è che questa direttiva limita enormemente il valore salvifico delle classiche clausole da “noi non siamo responsabili di nulla, cliccando accetti”. La direttiva prevede infatti che, nei confronti del danneggiato, la responsabilità prevista non possa essere semplicemente esclusa o neutralizzata tramite clausole contrattuali private o disclaimer messi in una T&C online. In sostanza, se il prodotto è difettoso e causa danno nei termini previsti dalla norma, il fatto che tu abbia scritto un disclaimer creativo non ti trasforma automaticamente in intoccabile.
Questo non significa, ovviamente, che ogni bug diventi automaticamente una causa milionaria, né che ogni software house venga demolita al primo crash. Significa però che il modello storico secondo cui bastava nascondersi dietro licenze, EULA, Terms & Conditions chilometriche e formule del tipo “as is, no warranty, use at your own risk” tende a perdere molta della sua immunità automatica quando si parla di danni reali da prodotto difettoso.
In pratica, i produttori di software diventano progressivamente più simili ai produttori di altri settori industriali: se vendi o distribuisci qualcosa che entra nella vita reale delle persone, produce danni, gestisce sicurezza, dati, processi critici o componenti digitali con effetti concreti, allora potresti non cavartela più semplicemente dicendo “eh, però avevi accettato i termini”.
Ed è qui che il cambio di paradigma diventa interessante.
Per quarant’anni il software ha spesso goduto, in molti casi, di una sorta di eccezione culturale: “si rompe”, “si patcha”, “best effort”, “nessun sistema è perfetto”, “cliccando accetti”. Adesso l’Europa sta dicendo, progressivamente, che se il software è parte sostanziale di un prodotto o di una funzione economica rilevante, allora quella leggerezza strutturale diventa meno tollerabile.
Il che, tradotto brutalmente, significa che non basterà più spalmare tutto sull’utente finale con disclaimer, popup e liberatorie se il problema reale è che il prodotto era difettoso, insicuro o progettato in modo irresponsabile.
In sostanza: il software non viene più trattato soltanto come magia astratta scritta da nerd con una EULA paranoica allegata.
Sempre di più, viene trattato come industria. E quando sei industria, almeno in teoria, non puoi cavartela sempre dicendo che il cliente “ha accettato”.
Sul tema specifico, ovvero sulle procedure di autenticazione impossibili, la cosa sembra non avere alcun effetto… ma bisogna anche capire una cosa fondamentale: queste case produttrici, molto spesso, non stanno realmente ottimizzando l’esperienza dell’utente finale nel senso in cui l’utente la intende.
Stanno ottimizzando il proprio rischio.
Ed è una differenza enorme.
Perché dal punto di vista dell’utente la domanda è semplice: “Perché devo passare attraverso questo inferno burocratico solo per accedere a qualcosa che è mio, o che pago?”
Dal punto di vista dell’azienda, invece, la domanda spesso è completamente diversa: “Come faccio a ridurre la probabilità che qualcuno possa accusarmi, sanzionarmi, farmi causa o generarmi costi?”
E a quel punto il criterio cambia radicalmente.
Non si costruisce necessariamente il sistema più elegante.
Non si costruisce quello più umano.
Non si costruisce nemmeno sempre quello più efficace sul piano assoluto della sicurezza.
Si costruisce spesso quello che consente più facilmente di dimostrare, in caso di problemi, che “sono state adottate misure”.
Ed è qui che la sicurezza smette di essere soltanto sicurezza, e diventa anche postura legale, assicurativa e burocratica.
Se poi quelle misure rendono la vita impossibile a milioni di utenti, questo viene spesso considerato un danno collaterale tollerabile, purché il produttore possa mostrare checklist, policy, procedure, audit trail, verifiche multiple e sistemi abbastanza complessi da sembrare diligenti.
In altre parole, una parte significativa di queste procedure non nasce necessariamente per proteggere meglio voi.
Nasce per proteggere meglio loro.
O, più precisamente, per proteggere loro dalle conseguenze economiche, regolatorie o reputazionali di eventuali problemi.
Il che spiega perché, nonostante l’assurdità crescente di certi processi di autenticazione, il sistema continui spesso a peggiorare invece che semplificarsi.
Perché la domanda dominante non è “come rendiamo questo accesso ragionevole?”, ma “come dimostriamo di aver fatto abbastanza da non essere accusati di negligenza?”
E finché questa resterà la logica dominante, l’utente continuerà spesso a trovarsi davanti a sistemi che non sembrano progettati per essere usati, ma per essere difesi in tribunale.
E qui capite meglio per quale ragione il peggioramento delle procedure di “sicurezza” sia diventato così marcato dal 2024 in avanti, perché il problema, sempre più spesso, non è davvero la sicurezza nel senso tecnico più concreto del termine, anche per il semplice fatto che ormai una parte enorme degli attacchi più devastanti non prende di mira il singolo login del singolo utente, ma colpisce supply chain, infrastrutture condivise, provider, middleware, piattaforme centrali e milioni di utenti alla volta, cioè esattamente quel genere di bersaglio sistemico che rende piuttosto evidente come far impazzire il singolo utente con procedure di autenticazione sempre più elefantiache non sia necessariamente la risposta più intelligente al problema reale.
Il punto, infatti, è sempre più spesso un altro: queste aziende devono soprattutto dimostrare di avere fatto tutto il possibile, e questa è una differenza enorme, perché “essere realmente sicuri” e “poter dimostrare proceduralmente di aver fatto il massimo” non coincidono affatto necessariamente, dal momento che nel primo caso si parla di efficacia tecnica reale, di architettura, di backend, di supply chain, di processi robusti, mentre nel secondo si parla anche, e spesso soprattutto, di compliance, audit, responsabilità legale, reputazione, assicurazioni, regolatori, sanzioni e capacità di presentarsi davanti a qualcuno dicendo “guardate quante cose abbiamo aggiunto”.
Ed è proprio questo che li sta rendendo progressivamente più nervosi, non necessariamente più sicuri, non necessariamente più competenti, ma più nervosi, perché ogni data leak, ogni incidente, ogni multa, ogni scandalo, ogni nuova normativa e ogni escalation regolatoria aumenta la pressione a mostrare procedure, verifiche, autenticazioni multiple, attriti, prove, sistemi ridondanti e livelli crescenti di controllo, con il risultato che il sistema raramente tende a semplificarsi, mentre tende molto più spesso ad accumulare passaggi, fattori, verifiche, selfie, documenti, conferme e ostacoli ulteriori.
E così, invece di chiedersi seriamente se il problema strutturale sia stato davvero ridotto, ci si concentra sempre di più sulla costruzione di una narrativa difensiva secondo cui, nel momento in cui qualcosa dovesse andare storto, si possa almeno sostenere di avere fatto tutto il possibile, il che significa che la sicurezza rischia di trasformarsi sempre più in teatro procedurale, dove il punto non è necessariamente eliminare la vulnerabilità alla radice, ma dimostrare formalmente di aver reagito aumentando il peso operativo sull’utente.
E quindi, di questo passo, scusatemi, ma devo andare a correre intorno all’isolato, possibilmente abbastanza da sudare, perché Revolut potrebbe improvvisamente decidere che il prossimo livello di autenticazione richiede il DNA estratto dal mio sudore, inaugurando ufficialmente lo Sweat Factor Authentication, anche se temo che il passo successivo sarà l’X-Factor Authentication, quando per completare il login non basterà più identificarsi, ma bisognerà pure cantare.
One of the things I have been noticing with increasing clarity over the past few years, every time “digital security” comes up, is that a growing part of the problem is not actually being solved by companies at all: it is simply being redistributed onto end users.
