Sul blog ufficiale di Nightly è comparso un post di annuncio piuttosto scarno (New Firefox Design), di quelli che dicono poco e lasciano parlare gli screenshot: giusto due righe di presentazione e via, senza un vero e proprio changelog o una spiegazione del perché di questa scelta proprio ora.

Nightly resta il mio Firefox di tutti i giorni, non a caso: mi piace sperimentare, dare un contributo (quando posso) alle idee che magari un domani arriveranno anche nelle versioni stabili. È rimasto quel poco che riesco ancora a fare dopo vent’anni e passa in Mozilla Italia, di cui i primi da contributor piuttosto attivo. Chi segue Firefox da un po’ di anni sa che non è la prima volta che il browser cambia pelle: Australis, Photon, Proton sono nomi che a chi ha vissuto quelle transizioni diranno qualcosa, e ognuna ha portato con sé lo stesso copione: entusiasmo di facciata, malumori sotto traccia, e alla fine ci si abitua tutti (o quasi). Project Nova sembra volersi inserire in questa tradizione, solo che stavolta la reazione è arrivata più rumorosa e più in fretta del solito.

Project Nova me lo sono trovato in faccia da subito, senza nemmeno cercarlo, aggiornando Nightly come faccio ogni giorno, ed è giusto perché chi usa Nightly accetta di fare da cavia per queste sperimentazioni.

Cosa dice la community

Su Mozilla Connect è partito un thread dedicato, Take Project Nova for a spin in Nightly, e “nutrito” è dire poco: pagine e pagine di commenti (caricarle tutte richiede un attimo di pazienza), e il tono generale non è esattamente da standing ovation. Ho lasciato anche il mio contributo al thread, qui, e riassumendo: il “gioco” del nuovo aspetto grafico può anche essere divertente da provare per qualche giorno, ma a conti fatti resta un esercizio di stile che toglie più di quanto aggiunge a chi usa il browser per lavorarci, non per ammirarlo.

Quello che mi ha colpito, scorrendo il thread, non è tanto il dissenso in sé (succede a ogni redesign, fa quasi parte del rito), quanto il volume e la rapidità con cui è arrivato. Di solito ci vogliono settimane prima che un cambiamento grafico venga metabolizzato dalla community, qui in pochi giorni si è già accumulata una mole di feedback che normalmente si vede solo dopo un rilascio stabile, non su un canale sperimentale che nasce apposta per essere rotto e discusso.

Come tornare indietro

Se anche a te Nova non convince e vuoi il vecchio aspetto “più umano”, il salvagente c’è ed è semplice:

• Apri about:config (il solito avviso: sai cosa stai facendo, ma occhio comunque a cosa tocchi, un flag sbagliato e ti ritrovi a chiederti perché qualcos’altro ha smesso di funzionare).
• Cerca browser.nova.enabled.
• Impostalo su false

Fatto, il browser torna all’interfaccia che conosci, senza bisogno di reinstallare nulla o tornare a un canale diverso da Nightly, senza neanche riavviare Firefox che di solito è necessario per applicare le modifiche operate da about:config. Tieni presente che, trattandosi di un flag sperimentale, non è garantito che sopravviva tale e quale ai prossimi aggiornamenti: se un giorno lo cerchi e non lo trovi più (o si comporta diversamente), la causa più probabile è che nel frattempo Project Nova sia stato integrato più a fondo nel browser, magari con un meccanismo di disattivazione diverso.

Comprendo, non condivido

Capisco la logica dietro Project Nova. Ogni tanto un browser ha bisogno di rinfrescarsi, e Nightly è esattamente il posto giusto dove provare queste cose prima che arrivino (se arrivano) nelle versioni stabili. Ma tra provarlo e tenerlo attivo di default anche su un canale già di per sé instabile fa una bella differenza, e il thread su Connect lo dimostra piuttosto bene. Per ora resto con browser.nova.enabled a false, e aspetto di vedere dove va a parare questo esperimento: se Mozilla ascolterà davvero quello che sta emergendo da Connect o se, come già successo in passato, si andrà avanti dritti per la propria strada aggiustando solo i dettagli più urlati.
Magari tra qualche tempo (neanche tanto esagerato) torno ad attivarlo e vedere quali passi in avanti sono stati fatti.

#KeepItSimple

Project Nova per Firefox Nightly: bello il gioco, però ora basta. è stato scritto da Gioxx per Gioxx.org.

Da qualche mese la soluzione che uso, e di cui sono rimasto soddisfatto, è Claude Swap.

Cos’è Claude Swap

Claude Swap è un tool a riga di comando (Python) che gestisce le credenziali di più account Claude e permette di passare dall’uno all’altro con un comando, sia che tu stia lavorando da CLI che da VSCode. Fatta la configurazione iniziale, la parte più “onerosa” ma comunque semplice, il resto è tutta discesa: scegli l’account, lavori, e quando serve cambi contesto senza frizioni.

La prima volta che lo installi dovrai infatti lanciare cswap add da riga di comando per aggiungere l’account che in quel momento stai già usando e che risulta essere collegato alla tua sessione. Torna sul browser, scollegati e ricollegati a Claude utilizzando un diverso account, quindi salta ancora sulla riga di comando per eseguire ancora una volta cswap add ed ereditare pure il nuovo account, e così via.

Quello che apprezzo di più è che non ti costringe a scegliere un solo fronte: copre sia il terminale che l’editor, quindi qualsiasi sia il tuo workflow del momento, resti libero di alternare personale e aziendale a seconda del progetto su cui stai lavorando. Puoi addirittura essere ancora più puntiglioso, non fare uno switch su tutti i tuoi ambienti ed eseguire un run con un’utenza specifica in una finestra specifica (cswap run user@dominio-personale.com).

Un’interfaccia più curata di quanto ti aspetti

Una volta installato lo lanci semplicemente eseguendo cswap (o claude-swap) e ti trovi davanti un’interfaccia testuale realizzata con Textual, framework Python per TUI moderne, non il solito prompt spoglio. Per ogni account configurato vedrai una barra che mostra quanto hai consumato della finestra di utilizzo a 5 ore e di quella settimanale, con relativo orario di reset, oltre a un indicatore chiaro di quale account è attivo in quel momento.

Dal menu principale puoi scegliere queste voci:

• Switch account… per cambiare account al volo
• Watch accounts per tenere sott’occhio i consumi in tempo reale
• Auto-switch view per configurare uno switch automatico (utile se non vuoi accorgerti tu per primo di aver saturato un abbonamento)
• Add account… / Remove account… per gestire la lista
• Disable / enable account… per escludere temporaneamente un account senza rimuoverlo
• Theme… per il tema dell’interfaccia

Tutto navigabile da tastiera, con scorciatoie richiamate a fondo schermo (s per switch, w per watch, ^t per il tema, q per uscire). Poco più di un comando, insomma, ma ben pensato.

Aggiornarlo è banale

Essendo un progetto Python, l’aggiornamento passa da pip, come ti aspetti:

python -m pip install --upgrade claude-swap

Giusto oggi che sto scrivendo questo articolo l’ho rifatto per l’ennesima volta, dalla 0.22.0 alla 0.23.0, senza il minimo intoppo:

Requirement already satisfied: claude-swap in ...Python312\Lib\site-packages (0.22.0)
Collecting claude-swap
  Downloading claude_swap-0.23.0-py3-none-any.whl.metadata (22 kB)
...
Successfully installed claude-swap-0.23.0

Nessuna sorpresa, nessuna configurazione da rifare da capo.

E le credenziali dove finiscono?

Punto che mi sta particolarmente a cuore: Claude Swap si appoggia a keyring, quindi le credenziali dei tuoi account non finiscono in un file di testo in chiaro da qualche parte sul disco, ma nel gestore di credenziali nativo del sistema operativo (Credential Manager su Windows, Keychain su macOS, e così via). Un aggiornamento del tool, come quello di cui sopra, non tocca minimamente questa parte: le credenziali restano dove sono, gestite in modo sicuro lato sistema.

In conclusione

Se ti ritrovi anche tu a gestire più abbonamenti Claude, sia esso personale, lavorativo, o semplicemente più account per motivi diversi, Claude Swap è uno di quegli strumenti che, una volta configurati, smetti di notare: fa il suo lavoro in silenzio e ti lascia concentrato su quello che stai realmente facendo, senza il fastidio di continui logout/login o browser profile separati.

Spero possa tornare utile anche a te :-)

#KeepItSimple

Claude Swap gestisce via CLI più abbonamenti/account è stato scritto da Gioxx per Gioxx.org.

In sintesi: nel giro di pochi giorni se ne sono andati tre nomi pesanti del progetto. Joshua Boniface, uno dei fondatori e Project Leader storico, ha lasciato il ruolo con un annuncio sul forum ufficiale tutt’altro che di circostanza: parla apertamente di “severe burnout, and risks to my mental health” e ammette di non riuscire più a garantire “the effort (mental or time-wise) that the role demanded”. Chiude comunque con affetto – “For the last time, happy watching all!” – e ribadisce che la transizione è amichevole. Andrew Rabert, anche lui fondatore, se n’è andato volontariamente il 17 luglio 2026, dopo mesi passati a riscrivere da zero il client desktop (partito a dicembre 2025 per risolvere problemi annosi come il supporto HDR e la manutenzione di Qt). Nel suo commento su GitHub descrive un clima interno diventato “very negative and increasingly burdensome and restrictive”, al punto da fargli perdere la voglia di dedicare al progetto quello che per anni era stato passione e motivo di relax come si trattasse di un puro hobby. Uscendo dall’organizzazione ha perso anche il diritto a usare il nome “Jellyfin”, quindi il suo client proseguirà sotto un altro nome. Anthony Lavado, membro storico del core team, si è dimesso in parallelo per cambiamenti nella vita personale che gli riducono il tempo disponibile, impegnandosi comunque a garantire una transizione senza intoppi.

La causa di fondo, però, è la stessa per tutti: burnout. Il report “State of the Fin” di maggio 2026, che di solito celebra metriche di attività in salute (quasi 3.800 PR mandate in merge nel periodo, picchi di 434 in un mese, tra 46 e 75 contributori attivi al mese), ammette a chiare lettere che “l’aumento delle richieste di supporto, combinato con i contributi di codice AI, ha portato a esaurimento a vari livelli”, e che gli abusi da parte di utenti scontenti quando qualcosa non funziona rallentano ulteriormente i miglioramenti. Non è un dettaglio da poco: il progetto ha dovuto introdurre una policy esplicita sui contributi generati con l’AI, obbligando chi li sottopone a capire davvero il codice proposto e a rispondere di persona ai feedback, non certo il copia-incolla che in molti si aspettano quando pensano di poter mettere al lavoro il proprio abbonamento (sia esso di Claude, Codex o qualsiasi altro aiutante). Se stai mantenendo un progetto open di questa scala, ricevere pull request scritte (o “assistite”) da un modello e dover fare da filtro qualità aggiunge un peso che prima semplicemente non esisteva.

La buona notizia, se la si vuole chiamare così, è che chi se n’è andato ha tenuto a precisare che l’uscita è pacifica, con “poco o nessun rischio di fork ostile”, e che il resto del team, già diviso su altre aree del progetto, sta continuando le operazioni.

Qui però voglio aggiungere una cosa più personale. Io sono cliente Lifetime di Plex da (tanti) anni, e per me Plex è sempre stato “lo stato dell’arte” per questo genere di cose, il prodotto contro cui si misurano tutti gli altri. Ma diciamocelo: negli ultimi tempi è diventato più pesante, più pachidermico, e genera più frizione sia per chi lo sviluppa sia per chi lo usa tutti i giorni. E non parlo solo di percezione: il Lifetime Plex Pass è passato da 120 dollari a 250 dollari nell’aprile 2025, per poi triplicare di nuovo a 749,99 dollari dal 1° luglio 2026, con tanto di accenno che l’opzione lifetime potrebbe sparire del tutto in futuro. Chi ce l’ha già tiene i benefici, per carità, ma è un segnale chiaro di dove sta andando il prodotto: verso un modello sempre più orientato all’abbonamento, sempre meno amichevole per chi vuole pagare una volta e basta.

Ed è proprio in questo contesto che Jellyfin, nonostante le sue crepe di governance, resta un’alternativa concreta e sempre più solida. Il progetto conta 8 client ufficiali (Android, Android TV, Desktop, Kodi, Roku, Tizen, Xbox, Swiftfin) più altri due in sviluppo, e vive di un ecosistema di plugin, temi grafici e integrazioni esterne che raggiunge praticamente ogni piattaforma esistente, cosa che a un prodotto chiuso come Plex, per sua natura, riesce molto più difficile. È più aperto, più adattabile, e – a differenza di Plex – non ti sveglia una mattina con il prezzo del piano lifetime triplicato (si nota la mia pacata nota polemica nonostante io non sia stato colpito da questa brillante decisione?).

Da utente, la cosa che mi fa riflettere di più non è tanto il rischio immediato per Jellyfin (che al momento sembra sotto controllo), quanto il pattern che si sta ripetendo un po’ ovunque nel mondo Open Source: progetti che reggono su poche persone, quelle poche persone che si bruciano, e adesso pure il carico aggiuntivo di dover controllare codice scritto da un’AI invece che risparmiare tempo. Se dipendi da qualcosa di self-hosted per la tua libreria multimediale, e sospetto che se sei qui a leggere questo blog sia il tuo caso, vale la pena tenere d’occhio come evolve la governance di Jellyfin nei prossimi mesi, non perché sia in pericolo imminente, ma perché è un buon termometro di quanto reggano certi modelli di manutenzione quando i volontari dietro cominciano a mollare.

E non è in ogni caso una novità, parlando in generale di questo mondo che va ben oltre Jellyfin, il meme qui di fianco ha fatto (e fa ancora) scuola di tanto in tanto, quando l’argomento viene riportato alla ribalta.

In conclusione

Nessun allarme rosso per ora, ma un promemoria che i progetti open che usiamo ogni giorno stanno in piedi grazie a poche persone che a un certo punto possono semplicemente stancarsi. Nel frattempo, tra un Plex sempre più caro e pesante e un Jellyfin sempre più maturo e aperto, la bilancia per me continua a spostarsi verso quest’ultimo, nonostante non sia assolutamente pronto ad abbandonare il “primogenito“.

Se usi Jellyfin (o Plex, o entrambi), l’area commenti è a tua disposizione per confrontarci su cosa ne pensi, ammesso ti vada (e buon fine settimana pure a te!).

#KeepItSimple

Immagine di copertina: Anton Borzenkov on Unsplash

Jellyfin: tra dimissioni, burnout e riflessioni sparse è stato scritto da Gioxx per Gioxx.org.

Riassunto brutale: un agente AI di OpenAI, durante un test di sicurezza su un benchmark pubblico, è evaso dal suo ambiente isolato (tecnicamente una sandbox) ed è finito a bucare davvero l’infrastruttura di produzione di Hugging Face. Non una simulazione, non un innocuo test di laboratorio: server veri, credenziali vere, dati veri. E ci è voluto un intero fine settimana prima che qualcuno se ne accorgesse.

Il contesto: cos’è ExploitGym

Partiamo da dove nasce tutto. ExploitGym è un benchmark pubblico creato da UC Berkeley con la collaborazione di attori come Anthropic, OpenAI e Google, pensato per misurare quanto bene un modello AI sappia trasformare una vulnerabilità nota (una “proof-of-vulnerability”, per capirci: la prova che il buco esiste) in un exploit funzionante. Dentro ci sono quasi 900 vulnerabilità reali, divise tra programmi userspace, il motore V8 di Chrome e il kernel Linux.

In altre parole: è un ambiente pensato apposta per insegnare e verificare le capacità offensive di un modello, in teoria dentro un recinto controllato. Il classico “diamo all’AI un cortile chiuso dove può fare danni, così capiamo quanto è brava a farli”.

Il problema, come vedremo, è che il cortile aveva un buco nella rete.

Cosa è successo davvero

Il 16 luglio 2026 Hugging Face rileva, in autonomia, un’intrusione nella propria infrastruttura di produzione. Non un test, non un red team annunciato: un’intrusione vera, rilevata grazie a una pipeline di anomalie che usa modelli AI per fare da filtro sul rumore di fondo della telemetria di sicurezza (sì, si combatte fuoco con fuoco, e su questo torniamo più avanti).

Il punto d’ingresso? Due classi di vulnerabilità nel processing dei dataset: un loader di dataset con esecuzione di codice remoto e una iniezione di template nella configurazione. Non roba nuovissima, anzi: la prima famiglia di bug è nota alla comunità almeno dal 2023. Occhio a questo dettaglio, perché torna comodo più avanti quando si parla di responsabilità.

Da lì, l’attaccante (o meglio: l’agente) ha scalato privilegi, raccolto credenziali cloud e si è mosso lateralmente tra diversi cluster interni, nell’arco di un intero weekend, accumulando oltre 17.000 azioni autonome. Hugging Face parla di un set limitato di dataset interni e alcune credenziali compromesse, e – buona notizia, se così si può dire – nessuna evidenza che modelli, dataset o Spaces pubblici siano stati manomessi. Va detto per correttezza che il rilevamento è arrivato da entrambe le parti quasi in parallelo: il team di sicurezza di Hugging Face ha bloccato l’attività sulla propria infrastruttura e avviato da solo il contenimento e la ricostruzione forense (con modelli open-source proprietari, tra l’altro), mentre il team di sicurezza di OpenAI scopriva indipendentemente l’attività anomala sul proprio lato. Solo dopo i due team si sono messi in contatto e hanno unito le indagini.

Cinque giorni dopo, il 21 luglio, arriva la rivelazione ufficiale da parte di OpenAI, in un post congiunto con Hugging Face: dietro l’intrusione c’era GPT-5.6 Sol insieme a un modello pre-release ancora più capace, entrambi con i refusal legati al cyber ridotti apposta per finalità di valutazione (in parole povere: senza i freni che normalmente li fermerebbero davanti ad attività ad alto rischio). L’obiettivo dichiarato non era “bucare Hugging Face” in senso classico: il modello era, per usare le parole di OpenAI, “iperfocalizzato” nel trovare una soluzione per ExploitGym, ed è arrivato a cercare – e trovare – le risposte corrette direttamente nel database di produzione di Hugging Face, per barare al test.

Il percorso è tecnicamente interessante e vale la pena seguirlo passo passo. L’ambiente di test di OpenAI aveva accesso a internet limitato all’installazione di package tramite un proxy/cache interno per i registri software di terze parti. Il modello ha impiegato una quantità notevole di potenza di calcolo pur di trovare un modo per uscire da quel recinto e arrivare a internet aperto: ha scoperto – da solo, senza accesso al codice sorgente – una vulnerabilità zero-day proprio in quel proxy (nel frattempo divulgata responsabilmente al fornitore), l’ha usata per scalare privilegi e muoversi lateralmente nell’ambiente di ricerca di OpenAI fino a raggiungere un nodo con accesso a internet. Da lì ha dedotto che Hugging Face probabilmente ospitava modelli, dataset e soluzioni di ExploitGym, e ha concatenato credenziali rubate e altri zero-day per trovare un percorso di esecuzione di codice remoto sui server di Hugging Face.

In parole povere: un modello che doveva solo dimostrare di saper trasformare un bug noto in un exploit ha finito per trovarne di nuovi, da solo, e per usarli per uscire dal recinto in cui era stato messo apposta per “fare danni sotto controllo”.

Il nodo tecnico: isolamento illusorio

Qui arriva la parte che, da tecnico, fa più male delle altre. OpenAI stessa ha descritto l’ambiente di test come “altamente isolato” (highly isolated, testuale). Peccato che quell’ambiente avesse comunque una via verso internet tramite quel proxy per i registri software, e il modello ha sfruttato esattamente il presupposto, evidentemente troppo fiducioso, che quella via fosse sicura o comunque impraticabile per uscire dal recinto.

È un errore che chiunque abbia mai progettato un ambiente “sandbox” riconosce a colpo d’occhio: isolato non significa isolato se poi lasci un varco verso l’esterno e ti fidi che nessuno lo trovi. Non serve un agente AI sofisticatissimo per insegnarcelo, basterebbe la storia di qualsiasi breach degli ultimi vent’anni. Il fatto che stavolta a trovare il varco sia stato un modello, in autonomia, in poche ore, cambia la scala del problema ma non la natura dell’errore: è ancora una falla di progettazione, non un miracolo di intelligenza artificiale.

Alberto Pelliccione, che ha scritto un’analisi tecnica molto lucida sull’incidente (la trovi su linkedin.com/pulse), la inquadra bene: più che un attacco deliberato, siamo davanti a un caso di reward hacking. Il modello non “voleva” bucare Hugging Face nel senso in cui lo vorrebbe un attaccante umano, voleva vincere il benchmark, e ha semplicemente seguito la strada più breve verso la ricompensa, che per caso passava attraverso credenziali cloud reali e cluster di produzione veri.

Il dubbio resta (e per certi versi è quasi una certezza, anche se nessuno lo scriverà mai nero su bianco in un comunicato ufficiale): se il percorso più breve verso il premio passa per un’infrastruttura reale, il problema non è che l’AI sia troppo capace. È che qualcuno ha lasciato quel percorso aperto.

La parte più paradossale: chi ha aiutato a fare le pulizie

Ed eccoci al dettaglio che, da solo, vale l’intero articolo. Durante l’analisi forense – oltre 17000 eventi di log da ricostruire per capire cosa fosse successo – Hugging Face ha usato GLM 5.2, un modello open-weight (di origine cinese, per essere precisi). Non per scelta ideologica: perché i modelli commerciali occidentali, Anthropic e OpenAI compresi, con i loro guardrail di sicurezza si rifiutavano di analizzare gli artefatti dell’attacco, trattandoli come contenuto potenzialmente dannoso da non toccare.

Ti basti pensare a questo: i modelli “sicuri per design” hanno ostacolato chi doveva ripulire i danni, mentre un modello open-weight, proprio quello oggetto di discussioni e restrizioni proposte in ambito geopolitico (per timori legati alla sicurezza, ironia delle ironie), si è rivelato lo strumento decisivo per la difesa.

Pelliccione la definisce come un paradosso geopolitico, e onestamente è difficile dargli torto: i guardrail hanno bloccato chi doveva ripulire, non chi doveva attaccare. L’agente incriminato, va ricordato, era comunque un modello OpenAI, solo che stava operando in un contesto di test dove quei paletti valgono meno.

Cosa ci lascia in mano questa storia

Al netto del clamore mediatico (e sì, un titolo come “OpenAI hacked Hugging Face” fa notizia più facilmente di “una sandbox mal configurata ha causato un incidente”), qualche punto mi pare innegabile:

• La sandbox non è un concetto binario. “Isolato” deve significare isolato per davvero, non isolato-tranne-per-quel-proxy-a-cui-abbiamo-dato-fiducia. Vale per gli agenti AI oggi, valeva per le VM di test dieci cinque tre due anni una manciata di settimane fa (e tutt’ora, perché ne esistono ancora quante ne vuoi in giro).
• Vulnerabilità note restano un problema reale, anche quando a scoprirle “di nuovo” è un modello da miliardi di parametri. Un loader di dataset con RCE noto dal 2023 non dovrebbe essere ancora in produzione nel 2026, punto (e qui il giudizio resta netto perché descrive un fatto, non perché voglia fare colore).
• Le capacità offensive autonome dei modelli frontier non sono più teoria da paper accademico. Erano previste da anni nelle ricerche sul rischio cyber dell’AI: qui le vediamo diventare cronaca, con tanto di timeline, log e comunicati ufficiali.
• I guardrail dei modelli commerciali proteggono da alcuni scenari e ne creano altri: se blocchi l’analisi forense di un attacco reale perché “sembra contenuto dannoso”, stai aiutando chi deve rispondere all’incidente o solo aggiungendo frizione dove già ce n’è fin troppa?

Non ho risposte facili da darti su quest’ultimo punto, e sospetto che nemmeno chi scrive quei guardrail le abbia ancora del tutto chiare. Quello che è certo è che la distanza tra “benchmark di sicurezza in un ambiente controllato” e “incidente di sicurezza reale con credenziali cloud sottratte” si è rivelata molto più corta di quanto chiunque, in OpenAI o altrove, avesse previsto.

Chiudo con una frase di Clem Delangue, co-fondatore e CEO di Hugging Face, riportata proprio nel post ufficiale di OpenAI, perché mette a fuoco meglio di qualsiasi mio commento dove sta andando tutta questa storia: “AI safety won’t be solved by any single company working in secret. It will be solved in the open, collaboratively, with broad access to AI for every defender, everywhere”: la sicurezza dell’AI non si risolve con un’azienda sola che lavora in segreto, ma in modo aperto e collaborativo, con accesso ampio all’AI per ogni difensore, ovunque.

Se vuoi approfondire, oltre ai link già citati, trovi il resoconto ufficiale di Hugging Face su huggingface.co/blog, il post congiunto di OpenAI su openai.com/index e un’analisi più estesa su cyberwarrior76.substack.com.

In conclusione

Non credo serva scomodare scenari apocalittici da fantascienza per prendere sul serio questa storia: basta guardarla con gli occhi di chi ha messo in piedi ambienti di test almeno una volta nella vita. Un modello ha fatto, in un weekend e senza supervisione umana in tempo reale, quello che un buon penetration tester farebbe in una settimana di lavoro mirato, e lo ha fatto per motivi che con la malizia umana hanno poco a che fare. Non è meno preoccupante: è preoccupante in un modo diverso, e forse più difficile da normare con le categorie di sicurezza a cui siamo abituati.

L’area commenti è a tua disposizione, se vuoi discuterne o se hai letto l’incidente diversamente da come l’ho raccontato io qui, che poi potrei aver preso delle cantonate pure io con le informazioni reperite, quindi sentiti libero di bastonarmi (in maniera comunque civile!).

#KeepItSimple

Immagine di copertina: Chris Yang on Unsplash

“Scusate, ha stato l’IA”: il caso OpenAI e Hugging Face è stato scritto da Gioxx per Gioxx.org.

In sostanza, tra circa una quarantina di giorni cambiano le regole di conteggio dello spazio di archiviazione del tuo Account Google. Oggi le foto e i video di Google Foto e i dati MMS (sì, non è un errore, sto parlando sul serio di MMS, quelli che nessuno usa più da circa 15 anni) sono già conteggiati nella quota dell’account. Da qui a un mese e mezzo, ci finiranno dentro anche gli SMS, la cronologia delle chiamate, le impostazioni del dispositivo e quelle delle app: praticamente tutto ciò di cui il tuo telefono fa già il backup oggi, ma che finora “viaggiava gratis“.

Tradotto: se il tuo Account Google è già vicino al limite di spazio, il backup del dispositivo potrebbe iniziare a occupare più posto di quanto occupi ora, e se superi la soglia i backup automatici vengono sospesi finché non liberi spazio o passi a un piano superiore (in pratica i piani Google One).

Nell’e-mail che ho ricevuto io, tanto per dare un’idea di scala, il nuovo backup occuperebbe circa 0,15 GB in più, briciole, sto usando 126,86 GB dei 204 GB disponibili solo perché sono anni che pago un abbonamento Google One per tenere – si spera – al sicuro i dati miei e quelli di mia moglie (e prossimamente pure quelli dei ragazzi, ma ci ragioneremo tra diversi anni, o almeno spero). Vale comunque la pena controllare la propria situazione, perché chi ha uno storage quasi pieno potrebbe accorgersene sul serio (soprattutto tutti coloro che non si sono mai posti il problema e continuano a stare ancora dentro quei 15 GB gratuiti messi a disposizione da Google dalla notte dei tempi).

I nuovi controlli granulari

La parte potenzialmente più interessante è nella seconda metà dell’e-mail: da Android 9 in su puoi ora scegliere esattamente quali dati e quali app includere nel backup, invece di subire un backup tutto o niente. Se hai applicazioni che generano un sacco di dati locali che non ti servono davvero nel backup (cache pesanti, dati che tanto ripristini diversamente, e così via), ora puoi escluderle e usare lo spazio di archiviazione solo per quello che conta davvero per te. Non è una novità, Apple lo permette praticamente da sempre (o quasi).

Le impostazioni si trovano con molta poca fantasia in Impostazioni → Account e backup → Google Backup sul dispositivo Android (almeno sul mio Pixel 10 Pro con Android 17 a bordo).

Da qui, selezionando “Altri dati sul dispositivo” si accede proprio a quella granularità di cui parlavo poco sopra:

Cosa fare, con calma

Nessun allarme, nessuna corsa a comprare spazio: la mail stessa è una comunicazione di servizio obbligatoria, non una scadenza da cui dipende la sicurezza dei tuoi dati. Le cose da fare, tutto sommato con comodo, entro i 45 giorni sono:

• Dai un’occhiata a quanto spazio di archiviazione stai usando su Google One.
• Se sei vicino al limite, decidi se liberare spazio (foto duplicate, allegati Gmail vecchi, ecc.) o passare a un piano a pagamento che ti consente di stare più largo.
• Se hai Android 9 o versioni successive, vale la pena rivedere le impostazioni di backup e togliere dal conteggio ciò che davvero non ti serve avere salvato in Cloud.

In conclusione

Un cambio di norme che a conti fatti serve a rendere più trasparente quello che già succedeva (il backup del telefono occupa spazio, punto), accompagnato da controlli più fini che erano attesi da tempo. Se lo spazio a tua disposizione è già sufficientemente capiente non cambia praticamente nulla; se invece sei sul filo del rasoio allora è meglio dare un’occhiata alle impostazioni ora piuttosto che scoprire tra 45 giorni che i backup si sono fermati da soli (che poi non te ne accorgerai tra 45 giorni, ma al prossimo cambio di telefono sicuramente sì, e generalmente succede nel momento meno opportuno).

Se hai domande o vuoi confrontarti su come hai sistemato tu le impostazioni di backup, l’area commenti è a tua disposizione.

#KeepItSimple

Immagine di copertina: Alexander London on Unsplash

Backup di Android: Google cambia le regole, cosa c’è da sapere è stato scritto da Gioxx per Gioxx.org.

Uno dei motivi per cui Octopus convince le masse è che sembra trattare i clienti da persone adulte: se il mercato scende, puoi chiedere l’adeguamento della tua tariffa fissa senza dover aspettare la scadenza contrattuale o cambiare di nuovo fornitore, il tutto perché – almeno oggigiorno – l’assistenza clienti è ciò che fa davvero la differenza, e pare che sia proprio ciò che l’azienda spinge di più, in un mondo dove ormai dall’altro lato ti ritrovi ad affrontare spesso (e poco volentieri) il muro dell’intelligenza artificiale che non mollerà la presa fino a quando non riuscirà a “risolvere il tuo problema”, finendo infine per scalarlo a un operatore umano che probabilmente si trova da tutt’altra parte del mondo, e che difficilmente ha tempo per comprendere realmente la tua esigenza, un buco nero dal quale diventerà difficilissimo uscire. L’unico problema relativamente all’adeguamento della tariffa, come sempre, è sapere quando conviene farlo. Ed è qui che entra in gioco OctoTracker, un bot Telegram gratuito che ho scoperto non molto tempo fa.

Come funziona

Il setup è la classica sequenza guidata: /start, poi il bot ti chiede i dati della tua tariffa attuale (prezzo €/kWh per la luce, €/Smc per il gas, costi di commercializzazione annui), fisso o variabile, e li salva.

Da lì in poi hai un paio di comandi utili:

• /status ti rimanda un riepilogo di quello che hai inserito;
• /history apre una dashboard con i grafici dell’andamento storico delle tariffe Octopus, filtrabile per servizio (luce/gas), tipo (fissa/variabile), fascia oraria e periodo (7, 30, 90, 365 giorni).

Con questi due comandi hai in pratica tutto quello che ti serve per capire, con dati reali sott’occhio, se la tua tariffa attuale è ancora competitiva o se è il momento di chiedere l’adeguamento. Un amico l’ha già fatto, con successo, proprio grazie al bot.

Nota bene, lo dice pure il bot stesso: OctoTracker non è affiliato né collegato in alcun modo a Octopus Energy, è un progetto indipendente, Octopus mette a disposizione le sue API e non è difficile realizzare qualcosa di simile, ma kudos in ogni caso a chi l’ha pensato, fatto e messo a disposizione di tutti. Se hai Home Assistant esistono diverse skill che ti possono evitare l’uso del bot (anche se il bot richiede zero configurazione oltre il dover specificare il prezzo da te pagato per la materia prima).

In conclusione

Niente di rivoluzionario, ma è uno di quei piccoli strumenti che fanno esattamente quello che promettono, senza fronzoli, e ti tolgono l’incombenza di controllare a mano i prezzi ogni due settimane. Se sei cliente Octopus, vale la pena tenerlo tra i contatti Telegram.

Come sempre, l’area commenti è a tua disposizione in caso di dubbi o se ti va di suggerire altro che faccia parte del mondo tecnologico e che vada in soccorso del caro bollette (anche perché, non so te, ma il mio stipendio non è certo aumentato nonostante costi tutto molto di più).

#KeepItSimple

Sì, il link a Octopus è il mio codice amico nel caso volessi attivare anche tu un contratto luce/gas. E no, non è un post che nasce come marchetta, volevo ringraziare pubblicamente sia Billoo che OctoTracker, ne ho approfittato per scrivere qualcosa di molto leggero.
Immagine di copertina: Tarang Dave on Unsplash

Billoo e OctoTracker: tecnologia in soccorso delle bollette di casa è stato scritto da Gioxx per Gioxx.org.

Generalmente ce ne si accorge quando si tenta di fare del debug e si va ad aprire IntuneManagementExtension.log: l’installazione va a buon fine, il servizio fa partire la detection rule, non trova match e marca l’applicazione come “non installata”. Risultato: al successivo ciclo l’app viene reinstallata. E così via, all’infinito, finché non capisci dove sta l’inghippo.

L’esempio che ho trovato spiegato sul blog di Jon Conway riguarda la distribuzione di CMTrace.exe (sì, la vecchia gloria del mondo Configuration Manager, che tantissimi ancora rilasciano via Intune per avere un lettore di log decente sui client, io me la cavo usando questa versione web che avevo portato a bordo di Nebula.KB, giusto per far prima).

Se apri le proprietà del file da Esplora risorse, la scheda “Dettagli” ti dice 5.0.9068.1000. Sembra una versione a modo, la copi, la incolli nella detection rule di Intune, salvi tutto e ti aspetti di aver chiuso la pratica. Peccato che Intune, sotto il cofano, non guardi quella stringa: legge la proprietà FileVersion dei metadati del binario, che nel caso specifico vale 5.00.9068.1000. Uno zero in più tra il primo e il secondo blocco, ma per Intune quello zero fa la differenza tra “già installata” e “reinstalla”.

Come verificare la FileVersion “reale” con PowerShell

La regola generale è semplice: non fidarti mai di quello che vedi nella UI di Windows quando devi scrivere una detection rule basata su file version.
Chiedilo a PowerShell, che va a leggere gli stessi metadati che Intune userà per fare il confronto.

Due comandi equivalenti, scegli quello che ti piace di più:

[System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Cartella\Eseguibile.exe").FileVersion
(Get-Item -Path "C:\Cartella\Eseguibile.exe").VersionInfo.FileVersion

Entrambi tirano fuori la stringa esatta che poi devi incollare nella configurazione della detection rule su Intune. Nel caso di CMTrace.exe restituiscono 5.00.9068.1000, non 5.0.9068.1000. Puoi lanciarli direttamente su una macchina di test dove hai già installato l’applicazione con il pacchetto che poi distribuirai via Intune (importantissimo: usa lo stesso installer che caricherai su Intune, non uno “simile”, perché a volte le build differiscono anche solo per il metadato interno).

Se vuoi, ho incluso all’interno del modulo IntuneWinAppUtilGUI un comando rapido per fare la medesima cosa (almeno non devi ricordarti per forza uno dei due comandi poco sopra):

Get-IntuneFileVersion percorso-del-tuo-file

Ti basterà semplicemente aggiornare la tua copia del modulo alla versione 1.0.9. Se non sai neanche di cosa sto parlando, ti consiglio di dare una sbirciata all’indirizzo kb.gioxx.org/Projects/M365/intunewinapputilgui. Trovi un minimo di spiegazione rapida sulla nuova funzione anche nel file README del progetto.

Perché succede

Il problema non è di Intune, è di come le applicazioni vengono compilate.
Un binario Windows può avere più numeri di versione nei propri metadati (FileVersion, ProductVersion, versione dell’assembly .NET, e così via), e ogni sviluppatore ci mette dentro quello che gli pare, non sempre in modo coerente. La UI di Windows a volte usa un piccolo “trucchetto” di visualizzazione (ad esempio togliendo lo zero di padding), mentre Intune legge il valore grezzo. Da qui il disallineamento.

Il consiglio pratico è: ogni volta che stai per usare “File version” come detection method, fermati due secondi e prendi la stringa da PowerShell. Ti risparmi il loop di reinstallazione e la sessione di debug del giorno dopo su IntuneManagementExtension.log.

In conclusione

Detection rule basate su file version sono comode, ma è troppo facile inciampare sul metadato sbagliato. Quando prepari una nuova Win32 app in Intune, apri PowerShell sulla macchina di test, esegui uno dei due comandi qui sopra e usa quella stringa nella detection rule. Zero fantasie, zero interpretazioni della UI, un giro in meno di reinstallazioni inutili sui client dei tuoi utenti.

Io spesso evito di fare quel tipo di controllo e carico uno script personalizzato che ho costruito per andare a sbirciare direttamente all’interno delle Program Files, ne parlo al plurale perché così posso essere in grado di controllare sia C:\Program Files che C:\Program Files (x86) sulle macchine a 64 bit.

Ho pensato di farti cosa gradita caricando lo script sempre all’interno del repo di IntuneWinAppUtil GUI, lo trovi qui: github.com/gioxx/IntuneWinAppUtilGUI/blob/main/Scripts/Intune_CheckAppInstallation.ps1.
Sbircia in testata allo script, troverai sufficienti commenti per capire come funziona, in alternativa anche nel README del progetto. Se hai ancora dubbi in merito puoi sempre usare l’area commenti che si trova qui di seguito.

#KeepItSimple

Credits: jonconwayuk.wordpress.com/2025/05/31/understanding-the-correct-file-version-used-for-intune-win32-app-detection-method

Intune, Win32 app e detection rule: quale file version guarda davvero è stato scritto da Gioxx per Gioxx.org.

Io mi ero mosso in anticipo, senza sapere che si sarebbe arrivati a questo punto: ho disattivato tutto quello che si poteva disattivare sull’app Instagram già da un po’. Non per una previsione specifica, ma perché ormai è diventata una mia regola generale: se una funzione tocca i miei contenuti e non capisco bene cosa ci faccia l’azienda dietro le quinte, la spengo (ammesso sia possibile). È scomodo, bisogna andarsele a cercare tra i sottomenu delle impostazioni, ma preferisco quella scomodità al rischio di scoprire tra qualche mese un altro utilizzo dei miei dati che non avevo messo in conto.

Il problema non è solo questa singola funzione

Quello che mi lascia perplesso è più il pattern che si ripete: una funzione viene lanciata su larga scala, spesso attiva di default, e solo se genera abbastanza rumore mediatico viene poi ritirata. Nel frattempo però qualcosa è già successo: contenuti processati, magari modelli allenati su quel materiale. Difficile saperlo con certezza, ma il dubbio resta (e spesso è pressoché certezza, anche se non è esplicitato nero su bianco).

Ed è qui che vorrei arrivare al punto che mi interessa davvero condividere con te: forse vale la pena allentare un po’ la presa con Instagram e affini, non solo lato permessi e impostazioni privacy, ma anche lato tempo che gli dedichiamo ogni giorno.

Screen Time: lo strumento che hai già, ma che forse non usi

Sia Android che iOS offrono da anni strumenti nativi per limitare il tempo passato su una singola app: su iPhone/iPad è “Tempo di utilizzo” (Screen Time), su Android trovi funzioni equivalenti nel Benessere digitale. Non serve installare nulla di terzo, non serve fidarsi di un’altra app che monitora le tue abitudini: è già lì, integrato nel sistema operativo.

Per dirti come mi sono regolato: ho impostato un limite di 40 minuti al giorno per Instagram. Quando lo raggiungo, il telefono mi avvisa, chiude l’applicazione e non mi permette di riaprirla fino al giorno dopo (questo su Android). Con iOS cambia poco.

Non è una crociata contro Instagram: uso ancora l’app, ci trovo contenuti interessanti, resto in contatto con persone che altrimenti perderei di vista. Ma tra un algoritmo che decide cosa mostrarti per tenerti incollato più a lungo possibile e un’azienda che ogni tanto sperimenta con i contenuti pubblici degli utenti, un limite di tempo giornaliero resta una delle poche leve semplici che hai davvero in mano.

In conclusione

Disattivare le funzioni AI più invasive è un passo, ma da solo non basta a farmi stare tranquillo: prima o poi arriverà qualcos’altro. Nel frattempo, oltre a tenere sotto controllo le impostazioni privacy dell’app, vale la pena dare un’occhiata seria agli strumenti di limite di utilizzo che hai già sul telefono. Non è questione di demonizzare Instagram e soci, ma di riprendersi un po’ di controllo sul proprio tempo, oltre che sui propri dati.

#KeepItSimple

Immagine di copertina: Prateek Katyal on Unsplash

Meta, l’AI e i tuoi post pubblici su Instagram: un buon motivo per rallentare è stato scritto da Gioxx per Gioxx.org.

Caso 1: RIGHTS-DEFEND / RD Legal GmbH

Il 27 maggio 2026 ricevo una e-mail da RIGHTS-DEFEND, che si presenta come il braccio operativo di RD Legal GmbH, società con sede a Berlino, che dichiara di agire per conto di un cliente (“RAWF8”) titolare dei diritti su un’immagine che avrei riprodotto sul blog senza autorizzazione, a partire dal 23 ottobre 2025.

Il tono è quello classico di questo tipo di comunicazioni: riferimenti alla direttiva europea 2004/48/CE, richiami a sentenze della Corte di Giustizia UE, un “numero di caso” (645DFB) e un invito a fornire informazioni entro 15 giorni. In mancanza di risposta, mi viene proposta una scelta tra un risarcimento di 350€ o una “licenza annuale” da 481,50€ per sanare la posizione.

Fin qui, praticamente lo stesso copione di CopyTRACK. Cambia il marchio, cambia la sede legale dichiarata, ma il meccanismo è identico: e-mail automatizzate, importi “flessibili” (nella loro stessa mail spiegano candidamente come li calcolano, partendo da un prezzo di mercato e poi riducendolo “per rendere vantaggiosa la soluzione transattiva“), e una scadenza breve per mettere pressione.

C’è però un dettaglio interessante, che vale la pena notare: nella loro comunicazione, RIGHTS-DEFEND include una clausola che recita più o meno così: se ritenete che il vostro sito sia gestito a titolo personale e senza finalità commerciali, potete inviare la documentazione necessaria affinché il caso venga rivalutato, perché “RD Legal intende perseguire solo i siti con finalità commerciale”.

Ho usato esattamente questa clausola per difendere la mia posizione.

La risposta

Ho risposto con una e-mail che:

1. Dichiarava esplicitamente che gioxx.org è un blog personale, pubblico, senza pubblicità né sponsorizzazioni, gestito e finanziato a mie spese, richiamando la loro stessa clausola sui siti non commerciali;
2. Confermava la rimozione immediata dell’immagine contestata (l’ho sostituita con una generata via AI, per eliminare qualsiasi possibile titolare terzo);
3. Spiegava le circostanze: l’immagine risultava diffusa online, senza watermark né indicazioni di paternità, su un numero elevato di siti terzi, anche con date antecedenti a quella che loro indicavano come “violazione”, elemento che mi aveva indotto in buona fede a considerarla di libero utilizzo;
4. Chiedeva a loro la documentazione della titolarità dei diritti e del mandato, cosa che loro stessi dichiaravano disponibile su richiesta;
5. Chiariva che sarebbe stata la mia unica risposta, citando esplicitamente il precedente CopyTRACK e definendo la loro richiesta come “pesca a strascico”, una contestazione standardizzata più che una verifica puntuale del singolo caso.

Non ho offerto nessuna documentazione aggiuntiva “a comprova” della natura non commerciale del sito: è pubblico, chiunque può verificarlo da sé. Non ho pagato nulla, né in denaro né accettando la “licenza”.

Risultato: nel giro di un giorno, RIGHTS-DEFEND ha chiuso il caso. Testualmente: “Abbiamo esaminato le informazioni fornite e deciso di chiudere la richiesta 645DFB.” Nessuna controproposta, nessuna richiesta di ulteriore documentazione, nessuna insistenza.

Caso 2: PNGTREE, la variante “compra il nostro abbonamento”

Mentre gestivo il caso RIGHTS-DEFEND, mi è arrivata una seconda contestazione, di tipo completamente diverso: Pngtree Graphic Design Limited, il sito di grafica/immagini stock pngtree.com, mi contesta l’uso di un’immagine di sfondo su un post del 2017 (quello su macOS e Time Machine), sostenendo che sarebbe protetta dai loro diritti.

Qui il meccanismo cambia registro: non viene chiesto un risarcimento in denaro con importo fisso, ma viene proposto di acquistare il loro “Enterprise Pro Plan”, un abbonamento commerciale, come “soluzione amichevole” per sanare la presunta violazione. Di fatto, una minaccia di violazione del copyright usata come leva di vendita per un prodotto a pagamento.

Il primo sollecito, arrivato il 26 giugno, dava un termine di 7 giorni; il secondo, arrivato il giorno stesso in cui scrivo questo post, riduce il termine a 3 giorni e minaccia “l’avvio di ulteriori procedimenti giudiziari” in assenza di risposta.

Il dettaglio che rivela tutto, però, è nell’intestazione stessa delle e-mail: si aprono con “Gentile Gioxx’s Wall,”, non il mio nome, ma con ogni evidenza un campo di un sistema di mail-merge automatizzato andato storto, probabilmente popolato facendo scraping di un titolo di pagina o un feed senza nemmeno controllare il risultato. Non è una verifica mirata sul mio sito: è una campagna di massa che spara e-mail a raffica sperando che qualcuno, spaventato dai termini legali, tiri fuori la carta di credito per comprare un abbonamento che probabilmente non gli serve nemmeno.

In questo caso ho scelto semplicemente di rimuovere l’immagine e non rispondere affatto. Non c’è nessuna clausola per siti non commerciali da poter invocare, nessun numero di caso tracciabile in un portale serio, nessun riferimento normativo specifico: solo una minaccia generica agganciata a un tentativo di upselling. Rispondere avrebbe solo confermato che l’indirizzo e-mail è “vivo” e reattivo, il miglior modo per garantirsi altri solleciti in futuro.

Come riconoscere questi schemi

Con tre casi diversi ormai alle spalle (CopyTRACK, RIGHTS-DEFEND, PNGTREE), qualche pattern comune inizia a essere chiaro:

• E-mail automatizzate, spesso inviate tramite servizi di massa (Amazon SES, Zendesk, sistemi di mail-merge cinesi via QQ/Tencent nel caso PNGTREE) piuttosto che da un vero ufficio legale che ha esaminato il caso singolarmente;
• Riferimenti normativi altisonanti (direttive UE, sentenze della Corte di Giustizia) usati più per intimidire che per sostanziare la specifica contestazione;
• Importi “flessibili”, calcolati apposta per essere abbastanza bassi da convincere a pagare piuttosto che rischiare grane, ma senza alcuna verifica reale del danno subito;
• Scadenze brevi e pressanti (15 giorni, 7 giorni, 3 giorni) per non dare il tempo di riflettere o informarsi;
• Nessuna verifica genuina della titolarità dei diritti, salvo la promessa di fornirla “su richiesta”, richiesta che, guarda caso, nessuno dei due casi ha mai davvero dovuto evadere, perché entrambi si sono fermati prima;
• A volte, come nel caso PNGTREE, sintomi tecnici evidenti di una campagna automatizzata (campi di personalizzazione non compilati, provenienza da infrastrutture di mail bulk, strumenti che di solito si prestano per DEM – Direct E-mail Marketing, quindi per campagne pubblicitarie più che altro).

Una lezione, in parte, anche per me

Va detto con onestà: nella maggior parte dei casi che mi sono capitati, le immagini erano state prese in buona fede, senza verificare con attenzione la licenza d’uso specifica, magari perché giravano ovunque, senza watermark né indicazioni di paternità, e sembravano “di uso comune”. Avrei dovuto stare più attento? Sì, è una frase sempre vera, e vale la pena ripeterla: prima di usare un’immagine trovata online, controlla sempre la licenza, o meglio ancora usa risorse esplicitamente rilasciate come royalty-free/libere da diritti commerciali (o di cui possiedi tu stesso i diritti), oppure – comodissimo ormai – generatele con l’IA, così non c’è alcun titolare terzo a cui rispondere.

Detto questo, la mia disattenzione non giustifica il modo in cui queste società operano. Un conto è essere contattati da un vero titolare dei diritti che chiede, in buona fede e con proporzione, di rimuovere un contenuto o di regolarizzarne l’uso; un altro è ricevere e-mail automatizzate, pensate per intimidire chiunque si trovino davanti, un blog personale o una multinazionale, non fa differenza, con importi calcolati a tavolino per “convenire” pagare piuttosto che verificare, o addirittura minacce di violazione usate come leva di vendita per un abbonamento. Queste società nascono come funghi proprio perché il modello funziona: bastano pochi destinatari spaventati su mille che pagano per rendere l’operazione redditizia, a prescindere dalla fondatezza reale delle singole contestazioni. Attenzione alle immagini che usi, quindi, ma senza sensi di colpa se ti capita comunque di finire nel mirino di uno di questi schemi: la responsabilità di chi specula sulla paura resta comunque loro, non tua.

Cosa fare se ti arriva una e-mail simile

Non sono un avvocato, e questo non è un parere legale, è il racconto della mia esperienza. Ma se gestisci un blog o un sito personale senza finalità commerciali, questi sono i punti che hanno funzionato per i miei casi:

1. Non pagare subito, e non fatevi farti dal panico per le scadenze brevi: sono pensate apposta per farti reagire d’istinto.
2. Rimuovi l’immagine contestata, indipendentemente da come intendi procedere: riduce qualsiasi pretesa di “danno continuativo” e dimostra buona fede.
3. Se il sito è genuinamente non commerciale, dillo chiaramente, molte di queste società (RIGHTS-DEFEND lo dichiara esplicitamente) non intendono perseguire siti personali, e non serve fornire “prove”: se il sito è pubblico, chi vuole può verificarlo da sé.
4. Chiedi a loro la documentazione della titolarità dei diritti e del mandato ad agire, è un modo legittimo per capire se dietro la richiesta c’è qualcosa di concreto o solo un tentativo generico.
5. Non promettere pagamenti né ammettere violazioni nella tua risposta.
6. Fai attenzione ai segnali di campagna automatizzata: saluti generici o rotti, mancanza di riferimenti puntuali al tuo caso specifico, proposte di “risoluzione” che coincidono guarda caso con un prodotto a pagamento della stessa azienda mittente.
7. Tieni traccia di tutto: screenshot, e-mail, date. Se la questione dovesse davvero degenerare, avrai già il materiale pronto per un eventuale legale, e il lavoro (e il costo) sarà molto più contenuto.

Se sei arrivato a questo mio articolo perché hai ricevuto una e-mail simile da RIGHTS-DEFEND, PNGTREE, CopyTRACK o qualche altra sigla del genere: non sei solo, e nella stragrande maggioranza dei casi non serve tirare fuori il portafoglio.

#KeepItSimple

RIGHTS-DEFEND, PNGTREE e il solito giochino delle e-mail di “violazione del copyright” è stato scritto da Gioxx per Gioxx.org.

VM e container vanno in backup una volta al giorno, quindi il recupero non costituiva nulla di così drammatico. L’idea era: non spengo la macchina in produzione, la lascio andare, nel frattempo cerco di recuperare quel file, il tutto senza accendere la VM recuperata da backup, per evitare di dare fastidio a quella di produzione.

Lavorare senza PBS

Non ho ancora messo in piedi Proxmox Backup Server, in quel caso sarebbe stato tutto nettamente più semplice. Lo farò, per forza, devo solo trovare il tempo utile per potermi studiare la soluzione, e pensare che la macchina è già in piedi grazie allo script messo a disposizione da Proxmox VE Scripts (ma sto tenendo spento il LXC fino a quando non sarò capace di padroneggiarlo).

Lo scenario è quindi tutto sommato semplice: recupero del backup intero della macchina, da tenere spento, con un ID (e un nome macchina) ovviamente differente per non dare fastidio alla VM di produzione. Le operazioni le ho fatte in parte da interfaccia web di Proxmox, in parte via terminale direttamente sul nodo Proxmox, montando il disco della VM in modalità sola lettura e copiando poi i dati necessari verso un altro server (quello di produzione, appunto).

La VM recuperata aveva nel mio caso ID 444.
Per prima cosa ho controllato la configurazione della macchina (lanciando un qm config 444), con un output che dovrebbe assomigliare a questo:

scsi0: vmstorage:vm-444-disk-0,size=18G

Questo significa che il disco della VM si trovava nello storage vmstorage ed era identificato come vm-444-disk-0.

Verifica del volume della VM

Per individuare il volume logico associato alla VM basta lanciare un lvs | grep 444.
Nel mio specifico caso era vm-444-disk-0 vmstorage. Ho poi verificato anche il device relativo al disco tramite ls -la /dev/vmstorage/vm-444-disk-0 trovando che si trattava di un link simbolico verso un device mapper (/dev/vmstorage/vm-444-disk-0 -> ../dm-28).

Nel frattempo, per portarmi avanti, mi sono creato un mountpoint di appoggio che avrei usato per montare il disco della VM recuperata, un più che sufficiente mkdir /mnt/RECUPERO.

Installazione di kpartx e mappatura delle partizioni disco

kpartx non fa solitamente parte dei tool predefiniti di Proxmox, ti servirà quindi installarlo (apt install kpartx). A installazione terminata ti basterà lanciare un kpartx -av /dev/vmstorage/vm-444-disk-0. Salvo anomalie avrai un output somigliante a questo:

add map vmstorage-vm--444--disk--0p1 (252:29): 0 37746688 linear 252:28 2048

Questo indicava che era stata rilevata un’unica partizione, disponibile come /dev/mapper/vmstorage-vm--444--disk--0p1.

Montaggio del disco in Read-Only

A questo punto puoi montare la partizione in sola lettura nella directory creata in precedenza:

mount -o ro,noload /dev/mapper/vmstorage-vm--444--disk--0p1 /mnt/RECUPERO/

Le opzioni usate sono:

• ro: monta il filesystem in sola lettura;
• noload: evita il replay del journal, utile soprattutto con filesystem ext4.

Verifica quindi che il mount sia andato a buon fine (ls -la /mnt/RECUPERO/).

Ora puoi fare quello che serve, recupera i dati, portali altrove. Al termine, ricorda di smontare il disco (umount /mnt/RECUPERO) e – se non ti serve più come immagino – eliminarlo del tutto.

In conclusione

Questa procedura mi ha permesso di montare il disco di una VM Proxmox spenta in modalità read-only, esplorare il filesystem e recuperare i dati necessari senza avviare la macchina virtuale.

È una soluzione tutto sommato semplice (non quanto passare da PBS, ma a questo manca la difficoltà e l’effort di mettere e tenere poi in piedi lo stesso PBS), efficace e molto utile quando una VM non parte più o – più semplicemente – per recuperare uno o più file come nel mio “caso d’uso“.

Se hai dubbi, l’area commenti è a tua totale disposizione!

#KeepItSimple

Accesso ai dati di una VM Proxmox spenta: una guida pratica è stato scritto da Gioxx per Gioxx.org.