Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale
Ciao, scrivo per condividere con voi questa storia. La notizia è passata (anche) su LinkedIn: https://www.linkedin.com/feed/update/urn:li:share:7422084149332647936/ Si tratta di un’evoluzione preoccupante che sta colpendo OpenStreetMap (OSM) e che solleva interrogativi urgenti sulla sostenibilità dei beni comuni digitali. Il progetto sta subendo un attacco di scraping senza precedenti. Se in passato era possibile mitigare il fenomeno bloccando pochi IP sospetti, oggi l’attacco è estremamente distribuito: oltre 100.000 indirizzi IP diversi effettuano pochissime richieste ciascuno, rendendo i filtri tradizionali totalmente inefficaci. L'aspetto più critico è l'uso di reti SDK (proxy residenziali): sistemi nascosti dentro app comuni (giochi, utility, VPN) che monetizzano la connessione degli utenti a loro insaputa, trasformando i dispositivi domestici in "ponti" per il traffico bot. Siamo di fronte a un paradosso tecnico e politico: - Inutilità tecnica: I dati di OSM sono già liberi e scaricabili in bulk. Lo scraping selvaggio dei tile è un metodo inefficiente che genera solo danni. - Costi reali: Il carico infrastrutturale grava direttamente su un’organizzazione no-profit gestita da volontari, traducendosi in costi operativi non indifferenti. - Implicazioni per i Commons: questo scenario riapre con forza il dibattito sulla tragedia dei beni comuni nell'era digitale. Se attori commerciali (spesso legati all'addestramento di IA) sfruttano intensivamente una risorsa gratuita senza contribuire alla sua manutenzione - o peggio, rendendola inutilizzabile a causa del sovraccarico - il rischio è il collasso. Cosa ne pensate? -- -- Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
Se in passato era possibile mitigare il fenomeno bloccando pochi IP sospetti, oggi l'attacco è estremamente distribuito: oltre 100.000 indirizzi IP diversi effettuano pochissime richieste ciascuno, rendendo i filtri tradizionali totalmente inefficaci.
Non so se è il caso di OSM ma, come ho già segnalato in passato, spesso questi accessi non sono attacchi ma "legittime" operazioni di scraping di voraci bot AI con lo scopo, ovviamente, di tenere quanto più aggiornati i vari LLM. Prendiamo i bot Google, se prima "passavano" dai siti ogni tot giorni per indicizzarne una parte, oggi sono decine, centinaia di bot da IP diversi che scaricano migliaia di pagine al giorno, in pratica si tirano giù ogni sito ogni giorno. Tutto per permettere al loro Gemini di essere quanto più aggiornato possibile (che non si dica che l'AI restituisca notizie vecchie). Ovviamente, stesso discorso vale per gli altri LLM, con il risultato che gli utenti "umani" sono ormai ridotti e pochi punti percentuali. 100000 indirizzi IP diversi possono sembrare tanti ma non sono nemmeno due classi B (65536 IP ognuna). Certo, se provenissero tutti dalla stessa classe B, <code> iptables -I INPUT -s x.y.0.0/16 -p tcp --dport 443 -j DROP </code> e non passa più nessuno. Purtroppo questi soggetti si sono comprati mezza numerazione Internet e quindi gli IP possono provenire da qualsiasi classe rendendo di fatto vano ogni tentativo di bloccarli. A.
Ciao Antonio, concordo che molto del traffico che si osserva oggi su vari servizi non sia necessariamente un “attacco”, ma scraping massivo spesso legato all’ecosistema AI. Nel caso che stiamo discutendo però c’è un elemento ulteriore: molte richieste sembrano provenire da reti di residential proxy o SDK di bandwidth-sharing (ad esempio BrightData, Honeygain, Infatica, PacketStream, Pawns, ecc. [1]). Queste infrastrutture distribuiscono le richieste su dispositivi reali o IP domestici e fanno rotazione continua degli indirizzi. Questo spiega perché si vedono numeri molto alti di IP diversi con poche richieste ciascuno: l’uso dei proxy moltiplica artificialmente le sorgenti e rende inefficaci sia i blocchi per singolo IP sia quelli per subnet. Tra l’altro, nel caso di OpenStreetMap questo tipo di scraping ha anche utilità limitata: i dati sono già disponibili tramite dump completi e feed di aggiornamento (planet dump e replication diff), quindi esistono meccanismi molto più efficienti e rispettosi dell’infrastruttura per ottenere dati aggiornati. [1] https://gist.github.com/Firefishy/5e60867d2425a380cc0e28eebbbf3887 Il giorno mer 4 mar 2026 alle ore 19:08 antonio <antonio@piumarossa.it> ha scritto:
Se in passato era possibile mitigare il fenomeno bloccando pochi IP sospetti, oggi l'attacco è estremamente distribuito: oltre 100.000 indirizzi IP diversi effettuano pochissime richieste ciascuno, rendendo i filtri tradizionali totalmente inefficaci.
Non so se è il caso di OSM ma, come ho già segnalato in passato, spesso questi accessi non sono attacchi ma "legittime" operazioni di scraping di voraci bot AI con lo scopo, ovviamente, di tenere quanto più aggiornati i vari LLM.
Prendiamo i bot Google, se prima "passavano" dai siti ogni tot giorni per indicizzarne una parte, oggi sono decine, centinaia di bot da IP diversi che scaricano migliaia di pagine al giorno, in pratica si tirano giù ogni sito ogni giorno. Tutto per permettere al loro Gemini di essere quanto più aggiornato possibile (che non si dica che l'AI restituisca notizie vecchie).
Ovviamente, stesso discorso vale per gli altri LLM, con il risultato che gli utenti "umani" sono ormai ridotti e pochi punti percentuali.
100000 indirizzi IP diversi possono sembrare tanti ma non sono nemmeno due classi B (65536 IP ognuna). Certo, se provenissero tutti dalla stessa classe B, <code> iptables -I INPUT -s x.y.0.0/16 -p tcp --dport 443 -j DROP </code> e non passa più nessuno. Purtroppo questi soggetti si sono comprati mezza numerazione Internet e quindi gli IP possono provenire da qualsiasi classe rendendo di fatto vano ogni tentativo di bloccarli.
A.
-- FBK - Fondazione Bruno Kessler Trento - Italy tel +39 0461 314341 https://osm.org/go/0CvouFIm6 <https://osm.org/go/0CvouFIm6?m=> http://dcl.fbk.eu you can schedule a call with me here https://tinyurl.com/booknapo <https://bit.ly/booknapo> -- -- Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
Nel caso che stiamo discutendo però c’è un elemento ulteriore: molte richieste sembrano provenire da reti di residential proxy o SDK di bandwidth-sharing (ad esempio BrightData, Honeygain, Infatica, PacketStream, Pawns, ecc. [1]). Queste infrastrutture distribuiscono le richieste su dispositivi reali o IP domestici e fanno rotazione continua degli indirizzi.
Grazie Maurizio, sempre esaustivo :) chi vuole seguire gli sviluppi: [ https://en.osm.town/@osm_tech/116052113368747355 ] E qui [ https://www.opendemocracy.net/en/ai-chatbots-scraper-bots-chatgpt-website-of... ] un articolo su openDemocracy che commenta la vicenda. A. p.s. ma qualcuno di questi 100000 indirizzi IP si potrebbe avere? Per fare una ricerca più approfondita sul funzionamento di questi sistemi.
Ciao Maurizio, il problema è serissimo e non vedo soluzioni semplici. Il problema qui non è la tragedia dei commons, ma il saltare di regole internazionali solidamente accettate. Robots.txt era la regola che ha permesso ad Internet di crescere e prosperare. Ora qualche mostruoso Golia ha deciso che non ha bisogno di regole, perché tanto lui fa "diplomazia sulla forza" (suona familiare?). Mi pare l'esatto inverso della tragedia dei commons. Ora: soluzioni semplici non ne vedo, mi viene solo da appellarmi a esperienze passate, che non so quanto siano riproducibili nel contesto attuale. Per esempio: è pensabile che uno "sciopero del servizio OpenStreetMap" (magari a singhiozzo) possa portare la controparte a sedersi al tavolo della trattativa per parlare di nuove regole, tipo un Agents.txt che funzioni alla maniera del vecchio Robots.txt? Magari sto dicendo una fesseria, ma non vedo molte alternative che non siano: a) una legislazione draconiana (ma andrebbe fatta rispettare da un governo che è ormai in mano a chi viola le regole); b) la costruzione di una rete alternativa in cui i Golia di cui sopra fossero accolti ... ehm... come nella Internet degli esordi (con costi che una comunità senza l'appoggio di governi o grandi entità non potrebbe sostenere). Stefano Il 04/03/26 14:49, Maurizio Napolitano via nexa ha scritto:
Ciao, scrivo per condividere con voi questa storia. La notizia è passata (anche) su LinkedIn: https://www.linkedin.com/feed/update/urn:li:share:7422084149332647936/ Si tratta di un’evoluzione preoccupante che sta colpendo OpenStreetMap (OSM) e che solleva interrogativi urgenti sulla sostenibilità dei beni comuni digitali. Il progetto sta subendo un attacco di scraping senza precedenti. Se in passato era possibile mitigare il fenomeno bloccando pochi IP sospetti, oggi l’attacco è estremamente distribuito: oltre 100.000 indirizzi IP diversi effettuano pochissime richieste ciascuno, rendendo i filtri tradizionali totalmente inefficaci. L'aspetto più critico è l'uso di reti SDK (proxy residenziali): sistemi nascosti dentro app comuni (giochi, utility, VPN) che monetizzano la connessione degli utenti a loro insaputa, trasformando i dispositivi domestici in "ponti" per il traffico bot. Siamo di fronte a un paradosso tecnico e politico:
- Inutilità tecnica: I dati di OSM sono già liberi e scaricabili in bulk. Lo scraping selvaggio dei tile è un metodo inefficiente che genera solo danni. - Costi reali: Il carico infrastrutturale grava direttamente su un’organizzazione no-profit gestita da volontari, traducendosi in costi operativi non indifferenti. - Implicazioni per i Commons: questo scenario riapre con forza il dibattito sulla tragedia dei beni comuni nell'era digitale. Se attori commerciali (spesso legati all'addestramento di IA) sfruttano intensivamente una risorsa gratuita senza contribuire alla sua manutenzione - o peggio, rendendola inutilizzabile a causa del sovraccarico - il rischio è il collasso.
Cosa ne pensate?
-- -- Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente.
-- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
On Thu, Mar 5, 2026 at 9:28 AM Stefano Borroni Barale <s.barale@erentil.net> wrote:
il problema è serissimo e non vedo soluzioni semplici.
Una soluzione semplice esiste e sono i rate limits: si stima quante richieste al secondo fatte da umani con strumenti "standard" sono accettabili e si blocca tutto quello che va oltre la soglia. Diranno: Ma così si blocca anche chi usa Perplexity, alcuni degli utenti commerciali "virtuosi" o altro accrocchio? Spurchia, dice il salentino! Blocca tutto e poi si negozia. Se Perplexity e Google necessitano di più, paghino la OSM Foundation Enterprise, la nuova for-profit che la fondazione metterà in piedi all'uopo. Semplice e indolore. Il modello Wikimedia Enterprise sia da esempio.
Magari sto dicendo una fesseria, ma non vedo molte alternative che non siano: a) una legislazione draconiana (ma andrebbe fatta rispettare da un governo che è ormai in mano a chi viola le regole);
Decenni di palesi violazioni di GDPR, con condanne!, e ancora speri che saranno le leggi a risolvere sti problemi?
b) la costruzione di una rete alternativa in cui i Golia di cui sopra fossero accolti ... ehm... come nella Internet degli esordi (con costi che una comunità senza l'appoggio di governi o grandi entità non potrebbe sostenere).
Che l'internet dei vecchi tempi sia morto è un fatto, ma nessuno se n'è ancora reso conto.
il rate limiting è sicuramente uno degli strumenti disponibili, ma nei casi che si stanno osservando recentemente il traffico non arriva più da pochi IP molto attivi: spesso è distribuito su centinaia di migliaia di IP diversi (anche tramite reti di residential proxy), con pochissime richieste per sorgente. In questi scenari il rate limit per IP diventa meno efficace perché ogni sorgente resta sotto soglia ma il volume complessivo rimane molto alto. Sul tema degli accessi “enterprise”, credo valga anche la pena ricordare che OpenStreetMap non è completamente priva di interlocuzione con il mondo industriale: diverse aziende siedono già nell’OSM Advisory Board e partecipano alla discussione sull’evoluzione dell’ecosistema [1] Inoltre, nel caso di OSM esistono già strumenti pensati proprio per usi intensivi (planet dump e replication diff), che permettono di ottenere dati aggiornati senza gravare sui servizi live Il gruppo che si occupa della gestione dei server sta dialogando anche con Wikimedia Foundation. [1] https://osmfoundation.org/wiki/Advisory_Board -- -- Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
Ciao Stefano, visto che menzioni i robots.txt, vorrei condividere un approccio che si sta diffondendo molto nella resistenza. Poiché gli scapers non rispettano il robots.txt e se metti un Disallow su un path, loro lo visitano sistematicamente, alcuni burloni hanno iniziato a mettere contenuti falsi su quelle url. C'è tutta una "narrativa" divertentissima progettata per inquinare gli LLM, in cui compaiono caffé corretti con candeggina, martellate afrodisiache, miliardari assetati di metanolo, etc etc... Qualcuno li genera con LLM locali (esistono anche software che lo fanno al volo), ma i migliori che ho visto erano scritti (e condivisi) da persone ben consapevoli del funzionamento di questi software, studiati per agganciarsi a sequenze probabili ed alterarne le probabilità dei token successivi. In questo modo, chi viola il robot.txt si trova su mondi paralleli. E chi comprimesse i contenuti serviti da tali path dentro un LLM, si ritroverebbe output surreali in fase di decompressione. È uno delle tecniche di resistenza più semplici, e sembra stia funzionando egregiamente, avvelenando anche LLM blasonati. Naturalmente funziona tanto meglio quanti più siti lo adottano. OpenStreetMap dovrebbe fare semplicemente lo stesso: spostare Washington in Iran, Gaza al Vaticano, Mosca a New York, Pechino a Bruxelles e così via... Basterebbe un paio di settimane, magari in modo pseudo-casuale, nel t% delle risposte servite agli IP sospetti, in modo che gli scrapers non si accorgano subito dell'avvelenamento. Giacomo
Ciao Giacomo capisco l’idea e ho visto anch’io esempi di queste tecniche di “data poisoning” pensate per confondere gli scraper che ignorano robots.txt. Ho però qualche dubbio che un approccio del genere sia compatibile con un progetto come OpenStreetMap. Il valore principale di OSM è proprio l’affidabilità dei dati e l’idea di servire intenzionalmente informazioni false, anche solo a una parte delle richieste, rischierebbe di creare effetti collaterali difficili da controllare (cache, mirror, downstream users, ecc.). Inoltre - come già detto - OSM offre già meccanismi pensati per usi intensivi (planet dump e replication diff), quindi il problema non è tanto l’accesso ai dati quanto l’uso scorretto dei servizi live. Per questo tenderei a vedere con più favore soluzioni che lavorino su accesso, incentivi e buone pratiche piuttosto che sull’alterazione dei dati. -- -- Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
Ciao Stefano, sullo “sciopero del servizio” ho qualche dubbio sull’efficacia: gran parte di questi sistemi sono automatizzati e probabilmente riprenderebbero semplicemente a scaricare appena il servizio torna disponibile. Nel caso specifico di OpenStreetMap, rimane il paradosso che i dati sono già disponibili tramite planet dump e replication diff, proprio per permettere usi intensivi senza gravare sui servizi live. Quando qualcuno sceglie lo scraping distribuito invece di questi canali, il problema è più di incentivi e buone pratiche che di disponibilità dei dati. Forse la questione più ampia è capire come aggiornare le regole di convivenza dell’ecosistema web in un contesto in cui il consumo automatizzato su larga scala è diventato la norma. -- -- Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
participants (5)
-
antonio -
Giacomo Tesio -
Maurizio Napolitano -
Stefano Borroni Barale -
Stefano Maffulli