Usate AdGuard su iPhone? Il rischio nascosto dietro il blocco pubblicità

Nel mondo degli ad blocker spesso ci si concentra solo sul fastidio dei banner, sulle pagine che si caricano più in fretta e sul risparmio di dati. Molto più raramente ci si ferma a chiedersi quanta fiducia stiamo concedendo a queste app, che di fatto si piazzano nel mezzo tra il browser e i contenuti dei siti.

Il caso di AdGuard per iOS, sollevato dal ricercatore Andrew Morris di GreyNoise Intelligence, rimette al centro proprio questo tema: quanto è davvero trasparente il comportamento di un ad blocker e quali sono le implicazioni quando esegue codice remoto su ogni singola pagina web che apriamo?

Vuoi ascoltare il riassunto dell’articolo?

Ascolta su Spreaker.

Gli ad blocker non si limitano a togliere i banner: molti aggiungono logiche per “riparare” le pagine, eliminando gli spazi vuoti lasciati dalla pubblicità rimossa. È qui che entra in gioco il comportamento di AdGuard su iOS, finito sotto la lente di Morris.

Secondo l’analisi tramite reverse engineering, l’app AdGuard per iOS scarica da remoto circa 20.000 righe di codice JavaScript ogni 6 ore.

Questo codice viene poi applicato automaticamente a ogni pagina Web visitata, senza intervento dell’utente e senza bisogno di aggiornare l’app tramite App Store.

Il codice sembra servire proprio a gestire la rimozione degli spazi vuoti dove sarebbero dovuti comparire i banner pubblicitari. Il punto critico, sottolineato da Morris, è la quantità di potere che questo meccanismo concentra: il codice può cambiare in qualsiasi momento, e ogni modifica si riflette immediatamente sul DOM e sui contenuti delle pagine che navighiamo.

Questo JavaScript gira con gli stessi privilegi del sito visitato, all’interno del contesto WebKit. In pratica, ha la possibilità di osservare, modificare e ristrutturare ciò che viene mostrato all’utente, su qualunque dominio, dai siti di informazione ai portali aziendali, fino alle applicazioni Web più complesse.

Uno degli argomenti usati spesso per difendere gli ad blocker riguarda l’assenza di permessi DNS a livello di sistema. L’idea è che, se un’app non controlla il DNS, allora non può intercettare o manipolare il traffico di rete in modo pericoloso.

L’analisi di Morris mostra come questa sia una semplificazione fuorviante. Nel caso di AdGuard per iOS, la manipolazione non avviene durante la risoluzione dei nomi di dominio, ma dopo il caricamento della pagina, nel livello di esecuzione JavaScript. Il DNS resta intatto, ma il risultato finale che vediamo può essere comunque modificato.

Un’app che ha accesso al contesto WebKit può quindi osservare il contenuto caricato, intervenirci sopra e presentare una versione alterata della pagina. Questo controllo sul rendering può risultare addirittura più incisivo del controllo sulla rete, perché agisce direttamente su ciò che l’utente vede e interpreta come contenuto originale.

In questo scenario, il fatto di non toccare il DNS non basta per parlare di sicurezza: il nodo vero diventa quanto controllo si concede su ciò che viene mostrato, e quanto questo controllo resta verificabile dall’esterno.

Su iOS, l’architettura di Apple non permette alle app di manipolare liberamente il traffico di rete a livello di sistema.

Per il blocco dei contenuti in Safari, Apple ha introdotto la Content Blocking API già da iOS 9, che consente di filtrare elementi DOM e risorse URL seguendo regole predefinite.

Questa API, per come è progettata, non prevede l’inserimento di codice arbitrario né la modifica diretta del DNS. In teoria, quindi, dovrebbe limitare le possibilità di intervento degli ad blocker a un insieme relativamente rigido di regole per nascondere o bloccare determinati elementi.

Il caso di AdGuard per iOS descritto da Morris mostra però un approccio diverso, basato su JavaScript scaricato da remoto e applicato alle pagine. Questo sposta il baricentro dal semplice filtro statico a una forma di esecuzione dinamica che può cambiare nel tempo, senza che l’utente ne abbia visibilità o strumenti per un controllo indipendente.

In pratica, si passa da un modello in cui il sistema operativo definisce paletti chiari a uno in cui l’app introduce una componente di logica esterna, aggiornata da un server remoto, che interviene sul contenuto mostrato al browser.

Un altro punto toccato da Morris riguarda la trasparenza del codice di AdGuard per iOS. Il ricercatore ha scaricato il progetto da GitHub, notando che non riceveva commit da circa 4 mesi: un intervallo che, per un’app con milioni di utenti, appare quantomeno insolito.

Approfondendo, Morris ha scoperto che la libreria che gestisce il DNS risulta in realtà closed source. Ha eseguito un controllo di sicurezza sul binario compilato, senza individuare comportamenti sospetti, ma resta un problema di fondo: nel modello App Store non esiste una garanzia che il codice pubblico su GitHub coincida con quello effettivamente compilato e distribuito agli utenti.

La presenza di un repository pubblico tende a generare un senso di fiducia automatica: si vede il codice, si presume che tutto sia sotto controllo. In realtà, il codice visibile può essere incompleto, non aggiornato o solo parzialmente rappresentativo del software installato sul dispositivo.

Nel mondo della sicurezza si parla spesso di reproducible build, cioè la possibilità di ricompilare un progetto e ottenere un binario identico a quello distribuito, così da verificare che non ci siano modifiche nascoste.

Con l’App Store questa pratica è sostanzialmente impraticabile: l’utente finisce per affidarsi alla catena di distribuzione senza strumenti di auditing indipendente.

Il cuore dell’analisi di Morris non è tanto l’accusa di un comportamento malevolo, quanto la messa a fuoco della concentrazione di fiducia che un ad blocker di questo tipo richiede. Milioni di utenti nel mondo consegnano di fatto il DOM di qualsiasi pagina Web a un soggetto terzo, autorizzandolo a osservare, modificare e ristrutturare contenuti provenienti da qualunque dominio.

Questo vale anche per servizi sensibili: portali di lavoro, piattaforme aziendali, strumenti di collaborazione, applicazioni web mission critical. Anche se non si ipotizzano intenzioni ostili, l’architettura stessa introduce una superficie di rischio elevata, spesso sottovalutata dall’utente finale quando installa un semplice blocco pubblicità.

Morris ricorda inoltre che AdGuard ha sede a Cipro, quindi sotto la regolamentazione europea, ma segnala che molti sviluppatori lavorano da Mosca, in Russia.

Nel settore della sicurezza informatica, le competenze sono distribuite in modo globale e la provenienza geografica non basta da sola a definire l’affidabilità di un software.

In un’analisi del rischio, però, la giurisdizione operativa e il contesto normativo diventano variabili legittime, soprattutto quando si combinano con altri fattori: esecuzione di codice remoto non verificabile, binari chiusi, impossibilità di audit indipendenti. Non è un atto d’accusa automatico, ma un tassello in più da considerare in un quadro che richiede prudenza.

Lo stesso Morris si definisce “un po’ paranoico“, e nel mondo della sicurezza questa non è una colpa ma quasi un requisito professionale: la diffidenza metodica permette di individuare problemi strutturali prima che diventino incidenti concreti. In fondo, l’interrogativo che resta sul tavolo è semplice: quanta libertà di intervento si vuole concedere a un ad blocker sul contenuto delle pagine, e quanto si è disposti a basare questa scelta su una fiducia che, per come è costruita oggi, resta in gran parte cieca.