\\ Home Page : Storico : Linux e Open Source (inverti l'ordine)
Di seguito gli interventi pubblicati in questa sezione, in ordine cronologico.
Di Alex (del 14/05/2026 @ 14:00:00, in Linux e Open Source, letto 402 volte)
Organic Maps: La Rivoluzione Cartografica Offline e la Difesa della Privacy
[🔍CLICCA PER INGRANDIRE ]
In un’epoca in cui le infrastrutture di navigazione satellitare sono monopolizzate da colossi tecnologici che scambiano i servizi di mappe per dati di telemetria e sorveglianza comportamentale, l’applicazione Organic Maps emerge come un’ancora di salvezza per l’autonomia digitale. Questa utility di navigazione offline per Android e iOS basa il suo modello tecnico ed etico su OpenStreetMap, il database geospaziale wiki-style più grande al mondo, ed esclude per principio algoritmi di tracciamento, pubblicità e raccolta occulta di dati personali. LEGGI TUTTO L’ARTICOLO
🎧 Ascolta questo articolo
Storia e genesi del fork comunitario
Le origini dell’app affondano in una cronaca turbolenta di acquisizioni e conflitti ideologici nel mondo del software libero. Il suo DNA tecnico deriva da MapsWithMe, un’app fondata nel 2011 da Yuri Melnichek, Viktor Havaka e Alexander Borsuk. Rinominata MAPS.ME nel 2014, l’applicazione fu venduta al colosso internet russo Mail.ru Group, periodo durante il quale il codice sorgente fu reso open-source con licenza Apache 2.0. La crisi scoppiò nel novembre 2020: Mail.ru liquidò il progetto a una holding finanziaria (CryptoFinTech) che decise di monetizzare i milioni di utenti. La nuova proprietà riscrisse interamente l’app, tornando a una licenza proprietaria, integrando wallet digitali, pubblicità aggressive e alterando il motore di rendering locale. La reazione della comunità open-source fu immediata: Roman Tsisyk, ex sviluppatore, insieme ad altri membri storici, recuperò l’ultima versione libera e creò un fork chiamato inizialmente OMaps, che poco dopo mutò nome in Organic Maps.
Architettura offline e formato .mwm
Dal punto di vista architetturale, Organic Maps risolve il problema computazionale del mapping tramite un motore di rendering proprietario (ora reso open-source) noto come “Drape”, scritto in C++ per massimizzare la fluidità e minimizzare i carichi sul processore. Al centro del suo ecosistema offline c’è il formato file binario proprietario .mwm. Piuttosto che generare le mappe sul cloud durante l’uso, un processo lato server estrae ciclicamente terabyte di dati topologici XML grezzi di OpenStreetMap e li comprime ad altissima efficienza in questi pacchetti binari. L’utente finale scarica tali file a livello regionale o nazionale. Poiché tutte le topologie stradali, le curve di livello e gli indici dei punti di interesse sono memorizzati in locale, l’algoritmo di routing per auto, biciclette o percorsi pedonali avviene interamente on-device, appoggiandosi solo alle coordinate raw del chip GPS e garantendo sia zero latenza che zero dispersione dei dati.
Il mantenimento di questa utopia open-source non è però privo di logoramenti interni legati alla trasparenza dell’infrastruttura. Nel 2024 è divampata una controversia riguardante la scoperta di un server “meta-routing” chiuso, utilizzato dai creatori per bilanciare i carichi durante il download dei map-file dai server cloud come Mythic Beasts, il cui codice era stato silenziosamente passato da licenza MIT a proprietaria e in cui erano stati abilitati temporaneamente log di richieste utente. Questo evento, percepito come un tradimento della trasparenza totale promessa, unito ai dissidi sulla governance finanziaria, ha spinto alcuni programmatori radicali a frammentare nuovamente il codice, fondando il progetto CoMaps.
Quest’ultimo punta non solo al codice client aperto, ma alla liberalizzazione completa della toolchain di generazione server delle mappe, sottolineando come l’infrastruttura geografica pubblica sia divenuta uno dei terreni geopolitici più sensibili nel controllo dell’indipendenza digitale.
Â
Organic Maps navigazione offline privacy
In un’epoca in cui le infrastrutture di navigazione satellitare sono monopolizzate da colossi tecnologici che scambiano i servizi di mappe per dati di telemetria e sorveglianza comportamentale, l’applicazione Organic Maps emerge come un’ancora di salvezza per l’autonomia digitale. Questa utility di navigazione offline per Android e iOS basa il suo modello tecnico ed etico su OpenStreetMap, il database geospaziale wiki-style più grande al mondo, ed esclude per principio algoritmi di tracciamento, pubblicità e raccolta occulta di dati personali. LEGGI TUTTO L’ARTICOLO
Video Approfondimento
Storia e genesi del fork comunitario
Le origini dell’app affondano in una cronaca turbolenta di acquisizioni e conflitti ideologici nel mondo del software libero. Il suo DNA tecnico deriva da MapsWithMe, un’app fondata nel 2011 da Yuri Melnichek, Viktor Havaka e Alexander Borsuk. Rinominata MAPS.ME nel 2014, l’applicazione fu venduta al colosso internet russo Mail.ru Group, periodo durante il quale il codice sorgente fu reso open-source con licenza Apache 2.0. La crisi scoppiò nel novembre 2020: Mail.ru liquidò il progetto a una holding finanziaria (CryptoFinTech) che decise di monetizzare i milioni di utenti. La nuova proprietà riscrisse interamente l’app, tornando a una licenza proprietaria, integrando wallet digitali, pubblicità aggressive e alterando il motore di rendering locale. La reazione della comunità open-source fu immediata: Roman Tsisyk, ex sviluppatore, insieme ad altri membri storici, recuperò l’ultima versione libera e creò un fork chiamato inizialmente OMaps, che poco dopo mutò nome in Organic Maps.
Architettura offline e formato .mwm
Dal punto di vista architetturale, Organic Maps risolve il problema computazionale del mapping tramite un motore di rendering proprietario (ora reso open-source) noto come “Drape”, scritto in C++ per massimizzare la fluidità e minimizzare i carichi sul processore. Al centro del suo ecosistema offline c’è il formato file binario proprietario .mwm. Piuttosto che generare le mappe sul cloud durante l’uso, un processo lato server estrae ciclicamente terabyte di dati topologici XML grezzi di OpenStreetMap e li comprime ad altissima efficienza in questi pacchetti binari. L’utente finale scarica tali file a livello regionale o nazionale. Poiché tutte le topologie stradali, le curve di livello e gli indici dei punti di interesse sono memorizzati in locale, l’algoritmo di routing per auto, biciclette o percorsi pedonali avviene interamente on-device, appoggiandosi solo alle coordinate raw del chip GPS e garantendo sia zero latenza che zero dispersione dei dati.
Il mantenimento di questa utopia open-source non è però privo di logoramenti interni legati alla trasparenza dell’infrastruttura. Nel 2024 è divampata una controversia riguardante la scoperta di un server “meta-routing” chiuso, utilizzato dai creatori per bilanciare i carichi durante il download dei map-file dai server cloud come Mythic Beasts, il cui codice era stato silenziosamente passato da licenza MIT a proprietaria e in cui erano stati abilitati temporaneamente log di richieste utente. Questo evento, percepito come un tradimento della trasparenza totale promessa, unito ai dissidi sulla governance finanziaria, ha spinto alcuni programmatori radicali a frammentare nuovamente il codice, fondando il progetto CoMaps.
| Caratteristica Tecnica/Etica | Modello Corporativo (es. MAPS.ME v2) | Modello Community (Organic Maps) |
|---|---|---|
| Licenza e Gestione Codice | Sorgente proprietaria e chiusa dal 2020. | Open-Source (Apache 2.0 per client core). |
| Logica di Routing e Motore | Architettura dipendente da API cloud per generazione percorsi. | Routing 100% offline basato su engine Drape e format binari.mwm. |
| Modello di Monetizzazione | Annunci in-app, integrazione pagamenti digitali, rivendita dati. | Supporto donazioni, apposizione di pulsanti hotel senza export ID. |
| Privacy Validation | Tracciatori di telemetria standard attivi. | Validato Exodus Privacy Project: 0 tracker, 0 telemetria. |
Quest’ultimo punta non solo al codice client aperto, ma alla liberalizzazione completa della toolchain di generazione server delle mappe, sottolineando come l’infrastruttura geografica pubblica sia divenuta uno dei terreni geopolitici più sensibili nel controllo dell’indipendenza digitale.
Di Alex (del 16/05/2026 @ 08:00:00, in Linux e Open Source, letto 411 volte)
Telefono cellulare che mostra un lucchetto digitale fratturato su sfondo di codice crittografico, con impronte digitali umane sovrapposte.
Il bisogno di controllo crittografico genera soluzioni matematicamente titaniche ma psicologicamente labili. Aegis Authenticator è un'applicazione open-source per la gestione dei token 2FA, progettata per gli algoritmi TOTP e HOTP. Si pone come roccaforte zero-knowledge in reazione all'egemonia di cloud provider come Authy, ma la sua forza crittografica sposta semplicemente il punto di rottura dalla macchina all'utente. LEGGI TUTTO L'ARTICOLO
Bonus Video
L'architettura di sicurezza zero-knowledge
Aegis Authenticator rappresenta una risposta radicale al problema della sicurezza dei token di autenticazione a due fattori, progettata per utenti che non si fidano dei servizi cloud e preferiscono mantenere il controllo esclusivo dei propri segreti crittografici. L'applicazione, disponibile esclusivamente per piattaforme Android, blinda i token TOTP e HOTP confinandoli in un database criptato, chiamato Vault, che viene archiviato strettamente in locale sul dispositivo dell'utente, senza alcuna sincronizzazione automatica su server di terze parti. Questo approccio zero-knowledge si contrappone esplicitamente all'egemonia di provider come Authy, Google Authenticator e Microsoft Authenticator, i quali, per comodità dell'utente, sincronizzano automaticamente copie dei segreti di autenticazione sui propri server cloud, creando un ulteriore potenziale vettore d'attacco per gli hacker che potrebbero compromettere queste infrastrutture centralizzate. L'algoritmo di cifratura utilizzato da Aegis per proteggere il Vault è il rinomato standard AES-256, che opera in modalità GCM, acronimo di Galois Counter Mode, una modalità operativa che combina la cifratura dei dati con un meccanismo di autenticazione che assicura sia la riservatezza che l'integrità delle informazioni memorizzate. L'AES-256 è considerato militarmente robusto e attualmente inviolabile con le tecnologie esistenti, poiché una ricerca esaustiva della chiave di duecentocinquantasei bit richiederebbe un numero di tentativi talmente elevato da essere computazionalmente impossibile anche utilizzando tutti i computer del mondo combinati. La modalità GCM aggiunge un ulteriore strato di protezione, generando un tag di autenticazione che permette di rilevare qualsiasi manomissione del database, impedendo ad un attaccante di modificare i token anche se riuscisse a ottenere accesso fisico al file criptato. La chiave di sblocco del Vault può essere generata in due modi differenti: tramite l'impronta biometrica, sfruttando l'Android Keystore che memorizza in modo sicuro le chiavi crittografiche nell'hardware del dispositivo, oppure tramite una Master Password scelta dall'utente. Nel caso della Master Password, la stringa inserita dall'utente subisce una pesante trasformazione attraverso l'algoritmo di derivazione della chiave scrypt, progettato specificamente per essere computazionalmente costoso e resistente agli attacchi a forza bruta condotti con hardware specializzato come gli ASIC o le GPU. L'algoritmo scrypt richiede una quantità significativa di memoria e potenza di calcolo per derivare la chiave dalla password, rendendo proibitivi gli attacchi che tentano milioni di combinazioni al secondo, e proteggendo così anche password relativamente deboli da tentativi di cracking automatizzati.
La trappola della disciplina umana
L'esame chirurgico di questa architettura apparentemente inattaccabile mostra come la forza crittografica esasperata, spinta ai suoi estremi teorici, sposti semplicemente il punto di rottura dalla macchina alla biologia fallibile dell'utente, creando un nuovo vettore di vulnerabilità basato sulla psicologia umana anziché sulle debolezze algoritmiche. I puristi della privacy applaudono con entusiasmo l'assenza del cloud automatico, vedendo in questa scelta progettuale l'unico modo per garantire che i propri segreti di autenticazione non finiscano mai nelle mani di terze parti potenzialmente malevole o di governi intrusivi. Tuttavia, questa stessa scelta delega integralmente la sopravvivenza dell'identità digitale dell'utente alla sua disciplina personale nel gestire backup manuali del database criptato, un compito che richiede conoscenze tecniche non banali e un'attenzione costante che la stragrande maggioranza degli utenti non possiede o non è disposta a mantenere nel tempo. Il backup dei token 2FA in Aegis deve essere eseguito manualmente dall'utente, esportando il Vault criptato in un file che deve poi essere trasferito su un supporto di storage sicuro e separato dal dispositivo principale, come un'unità USB criptata, un NAS ridondante con protezione RAID, o un servizio di cloud storage di fiducia, contraddicendo in parte la filosofia zero-knowledge originale. Nel mondo reale, governato dall'entropia termodinamica e dall'imprevedibilità degli eventi, l'atto distrattivo o la sfortuna agiscono inesorabilmente. Se il dispositivo mobile su cui è installato Aegis cade in mare, viene distrutto in un incidente, subisce un corto circuito fatale per un'infiltrazione d'acqua, o semplicemente smette di funzionare per un guasto hardware della scheda madre o della memoria flash, e l'utente ha trascurato o procrastinato la complessa catena di backup locale, il lucchetto matematico dell'AES-256 si trasforma istantaneamente da strumento di protezione in una tomba algoritmica dalla quale i token non possono essere più estratti. L'utente si ritrova improvvisamente escluso da tutti i servizi che proteggevano con l'autenticazione a due fattori: account email, social media, servizi bancari online, piattaforme di lavoro, criptovalute, e qualsiasi altro servizio che richiedeva il secondo fattore per l'accesso. Il recupero di questi account, se possibile, richiede procedure lunghe e complesse di verifica dell'identità , spesso con tempi di attesa di settimane e con il rischio che alcuni account vadano persi definitivamente se i servizi non prevedono meccanismi di recupero alternativi efficaci.
La vulnerabilitĂ biometrica e il lockout permanente
Inoltre, molti utenti, consapevoli della fragilità del sistema basato sulla Master Password che richiede di ricordare una stringa complessa e potenzialmente lunga, mascherano questa vulnerabilità utilizzando lo sblocco biometrico, basato sulle impronte digitali o sul riconoscimento facciale, per comodità quotidiana, delegando all'hardware del telefono la gestione della chiave di cifratura del Vault. I dati biometrici, tuttavia, non possiedono l'entropia revocabile che caratterizza le password tradizionali, poiché un'impronta digitale compromessa, catturata da un attaccante tramite una fotografia ad alta risoluzione o tramite un sensore falso, o resa inaccessibile a causa di un incidente che danneggia le dita dell'utente con ustioni o tagli profondi, non può essere semplicemente "reimpostata" o modificata come si farebbe con una password dimenticata. L'impronta digitale è una caratteristica biologica immutabile dell'individuo, e una volta che la sua riservatezza è compromessa o che l'accesso ad essa viene meno per ragioni fisiche, la chiave di cifratura del Vault diventa permanentemente inaccessibile senza possibilità di recupero, a meno che l'utente non abbia preventivamente configurato un metodo di backup alternativo basato su password. L'impalcatura crittografica di Aegis è impeccabile contro gli attacchi di uno stato-nazione con risorse immense, o contro un hacker remoto che cerca di violare il sistema dall'esterno, ma è strutturalmente cieca alla principale causa di disastro logico nel mondo reale: la negligenza ordinaria, la procrastinazione, la distrazione, l'incidente fortuito. Chi abbraccia questa applicazione nella speranza di massimizzare la propria sicurezza digitale baratta il rischio statisticamente minimo di un'esfiltrazione dei propri token dai server cloud di Authy o Google con l'enorme, silente e spesso sottovalutato rischio di un lockout auto-inflitto e permanente, causato dalla perdita o dal guasto del dispositivo fisico su cui i token sono custoditi.
La sicurezza perfetta è un miraggio, un'illusione matematica che non tiene conto della fragilità umana. Aegis rappresenta un'estremizzazione affascinante del principio di autosufficienza crittografica, ma la sua stessa perfezione tecnica diventa la sua più grave debolezza sistemica, poiché concentra tutto il rischio nell'anello più debole della catena: la memoria, la disciplina e la fortuna dell'utente, elementi che nessun algoritmo potrà mai rendere inviolabili.




Microsmeta Podcast
Feed Atom 0.3
Visite guidate a Roma








(p)Link
Commenti
Storico
Stampa