Il caso BrowserGate ha generato la solita reazione a catena: comunicato stampa degli attivisti, articoli con titolo allarmante, dichiarazione difensiva dell’azienda, attesa del pronunciamento regolatorio. Un copione rodato, che produce visibilità e produce poco altro.
Il problema non è che LinkedIn tracci. Il problema è come lo fa e cosa questo dice sulla direzione che le piattaforme digitali stanno prendendo — non come eccezione, ma come logica di sistema.
BrowserGate potrebbe non essere un incidente. Potrebbe essere un sintomo. Preso isolatamente, non è sufficiente a dimostrare un trend. È però coerente con una serie di segnali deboli che indicano una progressiva integrazione tra piattaforme e ambiente di navigazione — e questa coerenza è già abbastanza per meritare un’analisi che vada oltre il singolo caso.
La tesi che si tende a leggere in casi come questo è semplice: una grande piattaforma ha fatto qualcosa di scorretto, probabilmente violando il GDPR, ed è opportuno che le autorità indaghino. È una tesi corretta. È anche, in larga misura, irrilevante rispetto al problema strutturale che il caso porta alla luce.
Quello che BrowserGate mostra non è che LinkedIn abbia violato una norma. Mostra che il modello di controllo dell’ambiente digitale dell’utente è tecnicamente già disponibile, funzionante e progressivamente esteso — e che il dibattito giuridico fatica a renderlo visibile nella sua dimensione sistemica. Non necessariamente perché le norme manchino: il GDPR è technology-neutral by design, e combinato con la Direttiva ePrivacy e il Digital Markets Act potrebbe già coprire molti degli aspetti tecnici qui descritti.
Il problema è un altro: le norme tendono a ragionare su condotte specifiche, le piattaforme costruiscono architetture che rendono difficile isolare la singola condotta dal sistema che la produce.
Vale la pena chiarire fin dall’inizio la tensione interna a questa analisi: non è dimostrato che LinkedIn stia deliberatamente costruendo un’infrastruttura di sorveglianza competitiva. È dimostrato che ha costruito un sistema che ha quella capacità. La distinzione non è secondaria. Confonderla trasforma un’analisi in un atto d’accusa — e un atto d’accusa senza sentenza è solo propaganda.
1. Il fatto tecnico, senza sensazionalismo
Partiamo da ciò che sappiamo con ragionevole certezza, perché i fatti tecnici — una volta compresi — sono più inquietanti di qualsiasi sovrastruttura narrativa.
Ogni volta che un utente accede a LinkedIn tramite un browser basato su Chromium (Chrome, Edge), la piattaforma carica automaticamente un bundle JavaScript di circa 2,7 MB.
Questo script contiene un database interno di oltre 6.000 identificatori di estensioni — i manifest-ID dei plugin Chrome — e ne verifica la presenza tramite una catena a tre stadi.
La ricostruzione tecnica, documentata da Fairlinked/BrowserGate nell’analisi del codice sorgente, descrive questa progressione:
- prima attraverso il campo externally_connectable del manifest dell'estensione;
- poi tramite probing diretto di risorse esposte con richieste verso URL di tipo chrome-extension://<extension-id>;
- infine, come fallback passivo, tramite DOM (Document Object Model, cioè la struttura interna con cui il browser rappresenta e aggiorna il contenuto della pagina) mutation detection — l'ispezione della pagina renderizzata alla ricerca di modifiche o elementi iniettati dall'estensione.
I primi due stadi falliscono se l'estensione non espone risorse pubbliche; il terzo funziona comunque, rendendo il sistema, nella configurazione descritta, difficilmente eludibile per un utente medio.
Vale precisare che Fairlinked è un'organizzazione attivista, non un laboratorio di sicurezza indipendente: la ricostruzione è dettagliata e ancorata al codice, ma chi volesse contestarla lo farebbe esattamente da questa angolazione.
Il contenuto tecnico, pur non essendo stato oggetto di una validazione indipendente pubblica completa, è coerente con il comportamento osservabile lato client e con il codice analizzato.
Il risultato di questo processo viene consolidato in parallelo tramite Promise.allSettled() — una struttura asincrona che attende il completamento di tutti i controlli senza bloccare il resto della pagina — e poi inviato ai server di LinkedIn, associato all'identità reale dell'utente: nome, azienda, ruolo professionale.
Il sistema va oltre la semplice rilevazione. I ricercatori di Fairlinked hanno documentato la costruzione di un fingerprint persistente (sistema APFC — Advanced Persistent Fingerprinting Code) composto da 48 tratti hardware e software, inclusi parametri di configurazione del browser, risoluzione dello schermo, fuso orario e preferenze di sistema.
Questo identificatore, aggiornato in tempo reale, è progettato per sopravvivere alla cancellazione dei cookie e ad altre misure di privacy adottate dall’utente.
Il trattamento della preferenza Do Not Track (DNT) è emblematico: raccolta come tratto n. 23, viene sistematicamente esclusa dal calcolo dell’hash finale.
Secondo la documentazione di Fairlinked, la ragione tecnica è precisa — includere il DNT renderebbe l’identificatore instabile ogni volta che l’utente cambia quella preferenza.
L’esclusione non è un errore: è una scelta di progettazione che garantisce la persistenza del fingerprint indipendentemente dalle scelte di privacy dell’utente.
Questi dati non provengono da analisi esterne indirette: sono estratti dall’analisi diretta del modulo Webpack 75023 del codice sorgente in produzione di LinkedIn, documentata da Fairlinked e.V.
Qui il primo punto critico: questo è un sistema, non una funzione.
La progressione dal 2024 al 2026 — da 461 estensioni monitorate a oltre 6.000, con un incremento del 1.252% — è difficilmente spiegabile come risposta proporzionata a una minaccia crescente.
È vero che in sicurezza informatica la superficie di attacco cresce insieme alla minaccia, e che un’espansione del database non implica automaticamente una strategia di dominio.
Ma la tipologia delle estensioni monitorate — inclusi tool religiosi, applicazioni per la neurodiversità, software di privacy — suggerisce un perimetro di osservazione che va ben oltre gli strumenti di scraping di cui LinkedIn dichiara di occuparsi.
Vale la pena segnalare una possibile chiave interpretativa, anche se non è un movente accertato.
L’art. 6(10) del DMA impone ai gatekeeper di dare ai business user e ai terzi autorizzati accesso gratuito, di alta qualità e in tempo reale ai dati generati dalle loro attività sulla piattaforma.
Per LinkedIn, questo obbligo introduce un possibile incentivo strutturale a sorvegliare quali strumenti terzi accedono ai propri dati — e potenzialmente a tracciare l’espansione di quell’ecosistema.
Che la progressione numerica sia una risposta diretta a quell’obbligo è ancora un’inferenza, non un dato ufficialmente accertato. Ma rende la traiettoria più leggibile di quanto non faccia la sola spiegazione “anti-scraping”.
La discrepanza tra finalità dichiarata e capacità dispiegata è il dato che conta. Questa discrepanza, da sola, non prova un uso improprio — ma sposta l’onere della giustificazione su chi quella capacità la esercita. Non dimostra l’intenzionalità. Dimostra una traiettoria. La differenza conta.
2. Il fraintendimento collettivo
La narrativa dominante su BrowserGate è costruita attorno a una domanda sbagliata: LinkedIn sta violando il GDPR?
È una domanda legittima. Non è la domanda più utile.
Il GDPR è uno strumento progettato per regolare il trattamento dei dati personali: definisce basi giuridiche, obblighi di trasparenza, diritti degli interessati.
Applicato a BrowserGate, il GDPR pone domande serie:
- l’utente è informato della scansione delle proprie estensioni?
- La finalità dichiarata — sicurezza contro lo scraping — è coerente con il volume e la tipologia delle estensioni monitorate?
- Il rilevamento di estensioni legate a orientamenti religiosi, politici o a condizioni neurologiche costituisce trattamento di categorie particolari di dati ai sensi dell’art. 9?
Queste domande hanno risposte plausibili nella direzione della violazione. Ma fermarcisi significa perdere il livello più rilevante del problema.
Quello che BrowserGate mostra non è solo un problema di privacy. È un problema di potere: chi controlla l’ambiente in cui avviene la navigazione controlla l’osservazione, la profilazione e, in ultima analisi, la capacità di influenzare i mercati che in quell’ambiente operano.
Il concetto che rende visibile questo livello non è “violazione del GDPR”.
È platform-controlled browsing: la capacità di una piattaforma di osservare e modificare il contesto tecnico in cui l’utente interagisce con servizi terzi, senza passare da intermediari indipendenti — trasformando l’ambiente di navigazione in uno strato di osservazione gestito, senza che l’utente ne abbia percezione o controllo.
Vale però una distinzione tecnica importante, perché il fraintendimento è facile. Quando si parla di in-app browser — il meccanismo con cui Meta, TikTok o altri aprono i link esterni all’interno della propria app mobile — si descrive un fenomeno reale e documentato, ma diverso da BrowserGate.
Il sistema di scansione di LinkedIn opera specificamente su browser desktop basati su Chromium: il codice contiene una funzione isUserAgentChrome() che attiva lo script solo in presenza di Chrome, Edge o Brave. Le estensioni monitorate sono estensioni desktop, non ambienti mobili.
Questo rende BrowserGate, se possibile, più significativo della questione in-app browser: LinkedIn non ha creato un browser proprietario. Ha trasformato un browser tradizionale — Chrome, percepito come neutrale rispetto alle piattaforme che vi operano — in un ambiente parzialmente controllato, semplicemente iniettando JavaScript nel proprio front-end. La neutralità del browser non è stata aggirata costruendo un’alternativa. È stata aggirata dall’interno.
In questo senso il caso suggerisce una direzione, non certamente già consolidata, verso cui altre piattaforme potrebbero muoversi: non sostituire il browser, ma colonizzarlo.
3. Il cuore del problema: architettura del potere, non condotta aziendale
Alzare il livello di analisi significa spostare il fuoco dall’azienda al modello.
Le piattaforme non stanno semplicemente raccogliendo più dati. Stanno ridefinendo il perimetro di ciò che possono osservare, e lo fanno costruendo infrastruttura tecnica che espande quel perimetro in modo progressivo e difficilmente reversibile.
BrowserGate ha una dimensione specifica che non dovrebbe passare in secondo piano: il monitoraggio di oltre 200 prodotti concorrenti — strumenti di sales enablement, piattaforme di recruiting, tool di analisi dati — attraverso la rilevazione delle estensioni installate dagli utenti.
Questo significa che LinkedIn non raccoglie solo informazioni sugli utenti.
Raccoglie informazioni sul mercato attraverso gli utenti, mappando quali strumenti competitivi vengono adottati da quali organizzazioni, con quale frequenza e in quale contesto professionale.
L’art. 6(2) del Digital Markets Act proibisce ai gatekeeper di usare dati non accessibili al pubblico generati dagli utenti commerciali per competere con quegli stessi utenti.
LinkedIn è stata designata formalmente come gatekeeper dalla Commissione Europea nel 2023, per il servizio di social network professionale.
Gli obblighi DMA si applicano dunque direttamente — e la condotta documentata non è un rischio teorico futuro, ma una potenziale violazione attuale del divieto.
Qui emerge però la seconda tensione interna a questa analisi. LinkedIn sostiene che la scansione serve a rilevare strumenti di scraping che violano i propri termini di servizio. Sul piano del GDPR, il Considerando 49 riconosce la sicurezza delle reti come legittimo interesse del titolare del trattamento — e questa è la base difensiva più solida disponibile a LinkedIn.
Vale però notare che l’art. 6(7) del Digital Market Act (DMA) — che consente misure proporzionate per garantire l’integrità del sistema — riguarda esplicitamente sistemi operativi e assistenti virtuali.
LinkedIn è stata designata come online social networking service, non come OS o virtual assistant: quella disposizione non si applica direttamente. La difesa tecnica di LinkedIn, sul versante DMA, deve quindi appoggiarsi su basi diverse, e per ora non è chiaro su quali.
Se la giustificazione GDPR reggesse integralmente, BrowserGate sarebbe difesa tecnica, non abuso di mercato. Il problema è il test di proporzionalità: un database di 6.167 estensioni che include tool religiosi, strumenti per la neurodiversità e software di privacy fatica a qualificarsi come strettamente necessario alla difesa dallo scraping. Non impossibile — ma l’onere argomentativo è significativo.
La contraddizione più eloquente è interna agli stessi documenti prodotti da LinkedIn. In un affidavit depositato il 6 febbraio 2026 davanti a un tribunale tedesco, Milinda Lakkam — Senior Engineering Manager responsabile dei sistemi anti-abuso di LinkedIn — ha dichiarato, nello stesso paragrafo, che i modelli usati “non prendono in considerazione l’uso di alcuna particolare estensione del browser” e che l’azienda aveva agito contro utenti che “avevano [XXXXXX] installato”. Una contraddizione in una dichiarazione giurata non è un dettaglio tecnico. È un problema di coerenza istituzionale — e pesa diversamente da qualsiasi comunicato stampa.
4. Il layer giuridico: tensioni, non sentenze
Tradurre BrowserGate in termini giuridici richiede rigore su ciò che sappiamo e ciò che non sappiamo ancora.
Sappiamo che la scansione avviene senza consenso esplicito e senza che l’informativa privacy di LinkedIn descriva in modo trasparente questa pratica.
Sul piano del GDPR, la base giuridica invocabile è il legittimo interesse (art. 6(1)(f)), ma quel fondamento richiede il superamento del bilanciamento degli interessi — un test che difficilmente regge quando la scansione include categorie di estensioni che possono rivelare orientamenti religiosi, politici o condizioni di salute.
Qui si apre un’ambiguità interpretativa non ancora risolta: il rilevamento della presenza di un software sul dispositivo costituisce trattamento di categorie particolari di dati ai sensi dell’art. 9 GDPR?
La risposta non è ovvia.
Il software stesso non è dato sensibile. Ma se la sua presenza è univocamente associabile a un orientamento religioso o a una condizione neurologica, la giurisprudenza UE suggerisce di guardare al dato di destinazione, non solo al dato di partenza.
La Corte di Giustizia, nel caso C-252/21 (Meta v Bundeskartellamt), ha chiarito che dati di utilizzo e navigazione possono rientrare nelle categorie particolari quando permettono di rivelare informazioni come religione, salute o orientamenti — un’analogia forte con BrowserGate, anche se il passaggio dall’estensione installata all’inferenza sensibile rimane un’operazione interpretativa che una controparte contesterebbe.
La direzione dell’analisi è segnata; la conclusione non è ancora chiusa.
Sul piano dei precedenti specifici, il Verbraucherzentrale Bundesverband ha ottenuto dal Landgericht Berlin, con sentenza del 30 ottobre 2023, il divieto di alcune pratiche privacy di LinkedIn — incluso il disconoscimento dei segnali Do Not Track degli utenti.
Quella sentenza non riguarda l’architettura APFC descritta in questo articolo, che è emersa successivamente dalla documentazione tecnica di Fairlinked.
Ma come precedente sul DNT è direttamente rilevante: il tratto n. 23 del sistema APFC è esattamente la preferenza che il tribunale ha già considerato tutelata.
Esiste poi una zona di incertezza tecnico-giuridica che merita attenzione: la DOM mutation detection — terzo stadio della catena di rilevamento — opera su una pagina già renderizzata nel browser dell’utente.
Questo potrebbe configurare un accesso alle “informazioni archiviate nell’apparecchiatura terminale” ai sensi della Direttiva ePrivacy.
È una lettura plausibile e per certi versi persuasiva; presentarla come definitiva sarebbe però eccessivo allo stato attuale, in assenza di pronunciamenti specifici su tecniche di osservazione passiva di questo tipo.
L’unica affermazione giuridicamente solida che si può fare oggi è questa: la condotta di LinkedIn crea una asimmetria invisibile tra ciò che l’utente percepisce di stare facendo — navigare su un sito web — e ciò che tecnicamente accade nel suo ambiente digitale.
Quella asimmetria è il cuore del problema di trasparenza. Il resto è ancora oggetto di valutazione.
5. Le implicazioni strategiche che nessuno discute
Fin qui l’analisi ha seguito un percorso prevedibile: fatto tecnico, inquadramento giuridico, tensioni normative. Vale la pena uscire da quel percorso per un momento.
Le piattaforme non stanno competendo solo per i contenuti o per gli utenti. Stanno competendo per il controllo dell’infrastruttura attraverso cui gli utenti accedono al web.
Esistono due vettori distinti per farlo:
- costruire un browser proprietario (la logica dell’in-app browser mobile), oppure
- colonizzare un browser esistente dall’interno (la logica di BrowserGate).
Il secondo è più sottile, e per questo più rilevante come segnale.
BrowserGate non richiede che l’utente scarichi nulla. Non richiede che accetti condizioni aggiuntive. Richiede solo che visiti LinkedIn con Chrome.
A quel punto, il codice è già lì. Il browser che l’utente considera neutrale — uno strumento di terze parti, indipendente dalla piattaforma — diventa, parzialmente, uno strumento di osservazione della piattaforma stessa.
Questo è il punto strategico che il dibattito sulla privacy non cattura.
Non si tratta di dati raccolti: si tratta di chi controlla il contesto in cui i dati vengono generati. E se questo pattern si consolidasse — se altre piattaforme adottassero logiche simili, con o senza le stesse finalità di LinkedIn — il browser tradizionale come standard di neutralità diventerebbe progressivamente meno rilevante.
Non perché scomparirà, ma perché la neutralità che garantisce potrebbe essere svuotata dall’interno, sito per sito, script per script.
La domanda che ne consegue non riguarda la sanzione a LinkedIn.
Riguarda se il quadro regolatorio europeo — GDPR, DMA, ePrivacy — sia attrezzato a rispondere a un problema di architettura distribuita con strumenti nati per rispondere a problemi di condotta singola.
La risposta, al momento, non è ovvia.
Conclusione: non è un problema di LinkedIn
BrowserGate finirà probabilmente con un’istruttoria, forse con una sanzione, quasi certamente con una modifica ai termini di servizio di LinkedIn e un aggiornamento dell’informativa privacy.
Tutto questo è appropriato. Tutto questo è anche, in larga misura, marginale rispetto al problema che il caso illumina.
Il problema non è che LinkedIn abbia fatto qualcosa di scorretto.
Il problema è che il meccanismo tecnico che ha dispiegato è logicamente disponibile, in forme analoghe, a ogni piattaforma che gestisce una presenza web rilevante — e che nessuno ha ancora stabilito con chiarezza dove finisce la sicurezza legittima e dove inizia la sorveglianza sistematica dell’ambiente digitale dell’utente.
La distinzione tra capacità tecnica e condotta effettiva — che ho cercato di mantenere nel corso di questa analisi — non è una distinzione rassicurante.
È una distinzione che pone una domanda più scomoda di qualsiasi accusa diretta: se il sistema può farlo, e se nessuno lo ha impedito, quanto a lungo possiamo ragionevolmente aspettarci che non lo faccia?
Se il browser diventa opzionale — se l’accesso al web avviene sempre più attraverso ambienti controllati da piattaforme — chi controlla davvero l’esperienza digitale? E chi controlla i controllori?
Queste non sono domande retoriche. Sono le domande che il quadro regolatorio europeo dovrà rispondere nei prossimi anni, con strumenti che sono stati progettati per un web diverso da quello che si sta costruendo.