March 2026 - nexa - server-nexa.polito.it

Re: [nexa] R: R: keep android open

by Giacomo Tesio

Ciao Marco, On Thu, 5 Mar 2026 22:31:33 +0000 Marco Ricolfi wrote: > Quando dici che Google vincola contrattualmente i produttori di > smartphone affinché limitino gli acquirenti di tale hardware, cosa > vuoi dire esattamente? nulla di nuovo, in realtà: https://dazeinfo.com/2023/11/16/google-samsung-8-billion-deal-stay-default-… Google stabilisce contratti stringenti con i produttori di cellulari che includono i suoi software proprietari (necessari al funzionamento di un android, che è solo parzialmente open source): è grazie a questi contratti che può far limitare a livello hardware la scelta degli acquirenti, costringendoli a mantenere i propri prodotti come Google Play, GMail o i Google Play Services. Software che possono essere disabilitati (forse...), ma non rimossi. A meno di rootare il cellulare, un processo fuori dalla portata della maggioranza degli acquirenti e che tipicamente invalida la garanzia dell'hardware acquistato. Analogamente, è e sarà sempre più difficile installare software che Google non vuole si diffondano (NewPipe, Tabular, PipePipe etc...). Tutto quel "ecosistema" che descrivi, si basa su questi accordi commerciali anti-concorrenziali fra Google e i produttori hardware. Per far venir giù il castello di carte sarebbe sufficiente imporre ai produttori di hardware (inclusi smartphone e tablet) che vendono in Unione Europea l'obbligo di garantire agli acquirenti il pieno possesso dei dispositivi venduti, con la ovvia possibilità di installare, sostituire o disinstallare qualsiasi software di proprio gradimento. Esattamente come avviene per qualsiasi desktop PC. Insomma, mentre Apple si fabbrica gli iPhone su cui mette il proprio sistema operativo e le proprie barriere di ingresso, per gli altri smartphone e table esiste un mercato "tradizionale", il cui funzionamento viene alterato da queste pratiche anti concorrenziali di Google. Giacomo

March 6, 2026

R: R: keep android open

by Marco Ricolfi

Grazie Giacomo, grazie; ci sono tante cose che non capisco (ne avevo accennato a Stefano Borioni ma non ci sono ancor arrivato). Per il momento, solo una domanda. Quando dici che Google vincola contrattualmente i produttori di smartphone affinché limitino gli acquirenti di tale hardware, cosa vuoi dire esattamente? Grazie ancora m Da: nexa <nexa-bounces(a)server-nexa.polito.it> Per conto di Giacomo Tesio Inviato: mercoledì 4 marzo 2026 19:53 A: nexa(a)server-nexa.polito.it Oggetto: [nexa] R: keep android open Buona sera Marco, grazie per la tua analisi. Ho però un obiezione: esiste un mercato "tradizionale" degli smartphone. In altri termini una differenza sostanziale fra Apple e Google è che la prima fabbrica (o meglio, fa fabbricare in Cina) l'hardware che vende con iOS preinstallato, mentre la seconda vincola contrattualmente i produttori di smartphone affinché limitino gli acquirenti di tale hardware. In tale mercato (dei sistemi operativi per smartphone), Google è un monopolista. È su tale monopolio che fonda il suo "ecosistema". Ora Google ha deciso di restringere ulteriormente la poca libertà degli utenti Android, per poterli spiare e manipolarr meglio. Se l'UE fa finta di niente, non è per una distinzione legale fra mercato ed ecosistema, ma per totale mancanza di sovranità. Giacomo 4 Mar 2026 17:26:45 Marco Ricolfi <marco.ricolfi(a)weigmann.it>: > *La conclusione avrebbe tuttavia un senso, se iOS e l’Android di > Google operassero su di un mercato e si trovassero in un rapporto di > concorrenza con altri operatori.* *Cercando di ragionare su questo > punto, si può osservare che però sia A sia G operano all’interno dei > loro ecosistemi; gli ecosistemi, a loro volta, non sono mercati e > tantomeno mercati concorrenziali: non abbiamo vetture prodotte da > Stellantis piuttosto che da General Motors fra cui l’utente sceglie. > Il modello di business di chi gestisce un ecosistema è quello di > creare uno spazio a cavallo tra molti mercati, su cui operano plurime > imprese che offrono molti beni e servizi, per ottenere una percentuale > (un cut) sui beni e servizi intermediati. Una volta entrato in un > ecosistema, il più delle volte per effetto delle esternalità di rete, > nel caso di Google anche per l’illusione che Android sia open, > l’utente, lo sviluppatore e ogni altro operatore economico è > assoggettato alle regole imposte dall’orchestratore dell’ecosistema; > regole da lui accettate proprio per accedere a quel sistema operativo. > Se non le segue viola il contratto che ha dovuto accettare.*

March 5, 2026

Re: [nexa] Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale

by antonio

> 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-o… ] 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.

March 5, 2026

Re: [nexa] She Came Out of the Bathroom Naked, Meta Employee Says

by Andrea Trentini

e c'è chi vende "snake oil": https://www.futuroprossimo.it/2026/03/spectre-i-il-jammer-che-zittisce-i-di… On 05/03/2026 11:50, 380° via nexa wrote: > On 2026-03-04, Giacomo Tesio wrote: > > [...] > >> The workers describe videos where people’s bank cards are visible by mistake, and people watching porn while wearing the glasses. Clips that could trigger “enormous scandals” if they were leaked. > > vorrei tanto mettere in piedi un progetto per disattivare (o guastare permanentemente se non è possibile temporaneamente) questi dispositivi nel raggio di 5m : > > 1. microfoni (tipo Alexa & Co.) in modo tale che registrino solo rumore (ultrasuoni?) > > 2. telecamere (tipo "smart" glasses & Co.) in modo tale che registrino solo bianco (ultravioletti?) > > altrimenti anche un generatore di impulsi EMP in caso di emergenza può andare. > > ...echecc%"£$"& > > Saluti, 380° > -- Andrea Trentini ⠠⠵ - http://atrent.it - public key ID: 0xA7A91E3B - Dip.to di Informatica - Università degli Studi di Milano Cittadinanza Digitale e Tecnocivismo - https://www.ledizioni.it/prodotto/cittadinanza-digitale-tecnocivismo - https://edizionithemis.it/catalogo/digitale-e-societa/dal-tecnocivismo-alla… Sistemi Embedded - https://www.ledizioni.it/prodotto/a-carraturo-a-trentini-sistemi-embedded-t… [se vedete un allegato OpenPGP_0x72C15962A7A91E3B.asc e non riuscite ad aprirlo NON preoccupatevi, è la mia firma digitale, alcuni programmi di posta elettronica (outlook, gmail, ...) non sanno gestirla]

March 5, 2026

Re: [nexa] Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale

by Maurizio Napolitano

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.

March 5, 2026

Re: [nexa] Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale

by Maurizio Napolitano

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.

March 5, 2026

Re: [nexa] Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale

by Maurizio Napolitano

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.

March 5, 2026

Re: [nexa] Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale

by Maurizio Napolitano

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(a)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.

March 5, 2026

Re: [nexa] Il caso OpenStreetMap: proxy residenziali e la nuova "Tragedia dei Commons" digitale

by Giacomo Tesio

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

March 5, 2026

il problema di Stefano

by Angelo Raffaele Meo

II problema sollevato da Stefano Borrone Barale potrebbe essere affidato a Leonrdo Favario per un approfondimento nel quadro del nuovo Progetto Comunitario che si dice gli venga presto affidato. Raf Meo

March 5, 2026