Una nuova versione del Trinity Desktop Environment (TDE), la R14.1.6, è stata pubblicata il 26 aprile 2026 ed è pensata per gli utenti che apprezzano l’esperienza classica di KDE 3.5, da cui questo ambiente...

🔗 Leggi il post completo

Sony ha annunciato ufficialmente la chiusura di Music Pro, l’applicazione di registrazione audio di qualità professionale disponibile sugli smartphone Xperia di fascia alta. Il servizio si spegnerà definitivamente il 27 ottobre 2026, con una serie di tappe intermedie che interesseranno gli utenti abbonati nei mesi precedenti.

Cosa era Music Pro e perché era speciale

Music Pro era una delle funzionalità distintive degli Xperia top di gamma: permetteva di registrare audio con qualità da studio direttamente dallo smartphone, con strumenti avanzati come riduzione del rumore, rimozione del riverbero e tuning professionale. Era uno dei principali argomenti di acquisto per musicisti e appassionati di audio che sceglievano Xperia proprio per questa capacità unica nel panorama Android.

La chiusura avviene per stadi

Il calendario prevede tre fasi di dismissione. Il 27 luglio 2026 verranno bloccati i nuovi acquisti e i rinnovi degli abbonamenti a pagamento. Il 26 agosto 2026 cesseranno le funzionalità premium. Infine il 27 ottobre 2026 verrà completamente disattivato l’intero servizio. Sony invita tutti gli utenti a esportare i propri progetti — video e audio inclusi — prima della scadenza finale, poiché dopo quella data non sarà più possibile accedere ai dati salvati nell’app.

Motivazioni non dichiarate, futuro incerto

Sony ha spiegato la chiusura con la generica formula “per ragioni di vario tipo”, senza entrare nei dettagli. Non è chiaro se la funzione sarà in qualche modo reintrodotta in futuro o se Sony intende cambiare strategia sul fronte audio. In ogni caso, la fine di Music Pro rappresenta la perdita di uno degli elementi più originali dell’ecosistema Xperia.

OpenAI potrebbe presto fare il suo ingresso nel mercato degli smartphone con un dispositivo completamente ripensato attorno all’intelligenza artificiale. Secondo le ultime indiscrezioni, il progetto non riguarda un semplice telefono con un assistente AI integrato, ma un dispositivo che ridefinisce il modo stesso di interagire con uno smartphone.

Un telefono che “agisce” al posto tuo

Stando a quanto riportato da analisti del settore, il cuore del progetto OpenAI è un sistema di AI agent in grado di eseguire autonomamente compiti complessi. Non parliamo di un semplice assistente vocale, ma di un sistema capace di prenotare voli, raccogliere dati di mercato e gestire attività quotidiane senza che l’utente debba fare praticamente nulla. Il ruolo dell’utente diventa quello di supervisore: si impostano gli obiettivi e si revisionano i risultati.

Addio alla schermata home tradizionale

Uno degli aspetti più radicali del concept emerso è la totale assenza di una schermata home con icone delle app. Al suo posto, l’interfaccia mostrerebbe un pannello dinamico con i task in esecuzione e le informazioni elaborate dall’AI in tempo reale. Una transizione dal concetto di “telefono che si opera” a quello di “telefono a cui si delega”: un cambiamento filosofico profondo per il mondo degli smartphone.

Hardware e produzione: Qualcomm o MediaTek, produzione Luxshare

Sul fronte hardware, il dispositivo potrebbe montare un chip Qualcomm o MediaTek. La produzione sarebbe affidata a Luxshare, già nota per assemblare prodotti Apple. Quanto al sistema operativo, non è stato comunicato nulla di ufficiale, ma è probabile che si basi su una piattaforma smartphone esistente, verosimilmente Android.

Lancio ancora lontano: produzione di massa nel 2028

Il progetto è ancora in una fase molto iniziale: il design definitivo potrebbe non essere fissato prima della fine del 2026 o dell’inizio del 2027, mentre la produzione di massa è attesa non prima del 2028. Dunque, si tratta di una prospettiva a lungo termine, ma l’annuncio del progetto è già di per sé significativo. OpenAI sembra convinta che lo smartphone, pur nella sua forma fisica, possa diventare il veicolo principale per la prossima rivoluzione dell’AI.

Mancano poche ore alla presentazione ufficiale del Motorola Razr 70, ma il web ha già bruciato quasi ogni sorpresa. Nuovi render ad alta definizione del prossimo flip phone di Motorola sono trapelati online, rivelando con grande chiarezza design, materiali e colorazioni del dispositivo.

Quattro colorazioni, due materiali differenti

I render mostrano il Razr 70 in quattro varianti di colore: rosa, argento, verde e marrone. Motorola ha da sempre puntato sulla differenziazione visiva della sua linea Razr, e anche questa generazione non fa eccezione. Il modello verde presenta una finitura con pattern a rombi che cambia aspetto in base alla luce, mentre quello marrone sfoggia una texture che richiama la trama di un tessuto, con un risultato caldo e artigianale. Stessa scheda tecnica, personalità completamente diverse.

Design raffinato con dettagli premium

Dalle immagini ad alta risoluzione si possono apprezzare i dettagli della cerniera e della scocca, che trasmettono una sensazione di qualità costruttiva molto vicina a quella di un prodotto finito. Motorola sembra aver curato particolarmente i particolari estetici, mantenendo il DNA stilistico della serie Razr pur con variazioni cromatiche e materiali più ricercati.

Presentazione il 29 aprile, lineup con Plus e Ultra

Secondo le ultime informazioni, la presentazione ufficiale è attesa per il 29 aprile 2026. Sul mercato americano il dispositivo sarà commercializzato come Razr 2026 anziché Razr 70. La lineup includerà anche le varianti Razr 70 Plus e Razr 70 Ultra per chi cerca maggiori prestazioni. I prezzi non sono ancora stati comunicati ufficialmente, ma l’aumento generalizzato dei costi di memoria potrebbe portare a qualche ritocco verso l’alto rispetto ai modelli precedenti.

I prossimi smartphone pieghevoli Samsung continuano a fare capolino sul web prima ancora dell’annuncio ufficiale. Sono emersi online dei dummy — modelli in alluminio usati dai produttori di accessori per progettare cover e protezioni — che rivelano il form factor di Galaxy Z Fold 8, Galaxy Z Flip 8 e di un inedito modello denominato Galaxy Z Fold 8 Wide.

Galaxy Z Fold 8 Wide: più largo, più simile a un tablet

La novità più interessante è il modello Wide, un device con proporzioni più larghe rispetto al Fold 8 standard, pensato per chi vuole un’esperienza ancora più vicina a quella di un mini-tablet quando il telefono è aperto. I dummy mostrano il dispositivo sia in posizione aperta che chiusa, confermando le dimensioni notevolmente più generose in larghezza.

Ricarica magnetica: Samsung si avvicina al MagSafe?

Tra gli elementi che hanno attirato maggiore attenzione c’è un anello circolare visibile sul retro dei dispositivi. Questa struttura suggerisce la presenza di magneti integrati nel corpo del telefono, aprendo la strada a una ricarica wireless magnetica simile al MagSafe di Apple. Finora Samsung aveva gestito la compatibilità con accessori magnetici tramite cover dedicate, ma questa volta la funzione potrebbe essere incorporata direttamente nell’hardware. Questo significherebbe la possibilità di agganciare accessori, supporti e caricatori magnetici senza necessità di cover speciali.

Dummy affidabili, ma la parola finale spetta a Samsung

Come sempre, i dummy realizzati per i produttori di accessori si basano su specifiche di design anticipate e non sempre coincidono perfettamente con il prodotto finale. Tuttavia, storicamente si sono rivelati una fonte abbastanza attendibile per quanto riguarda dimensioni e design generale. Con la presentazione che potrebbe avvenire nella seconda metà del 2026, nei prossimi mesi arriveranno certamente ulteriori conferme o smentite.

LockBit 5.0 — nome in codice ChuongDong — non è la resurrezione di un brand cybercriminale: è la prova che i ransomware-as-a-service più organizzati si evolvono più velocemente delle operazioni delle forze dell’ordine che li contrastano. Nell’ultima settimana di aprile 2026, la gang ha rivendicato colpi su un istituto finanziario fondato dalle banche centrali latinoamericane, su società di logistica tedesche e su numerose altre vittime in Europa, Asia e nelle Americhe. Un’analisi tecnica e operativa della minaccia più attiva del momento.

Storia e resurrezione: da Operation Cronos a LockBit 5.0

Nel febbraio 2024, la joint task force internazionale Operation Cronos — guidata dall’NCA britannica con la partecipazione di Europol, FBI e polizie di altri dieci paesi — aveva inflitto quello che sembrava un colpo definitivo all’ecosistema LockBit: server sequestrati, chiavi di decryption pubblicate, affiliati arrestati in Polonia e Ucraina, e il volto del presunto admin “LockBitSupp” esposto pubblicamente.

La risposta del gruppo è arrivata con una certa prevedibilità: già nel settembre 2025, LockBit ha annunciato sul forum dark web RAMP la versione 5.0, coincidendo con il sesto anniversario dell’operazione. A distanza di circa sette mesi dal lancio, il quadro è chiaro: il gruppo ha ripreso la sua cadenza operativa, con oltre 100 vittime rivendicate sulla nuova data leak site (DLS) e attività in costante escalation nel 2026.

Architettura tecnica: cosa c’è di nuovo in LockBit 5.0

LockBit 5.0 è costruito su un’architettura a due componenti principali, un Loader e un modulo Ransomware, con una separazione netta tra funzioni di delivery e payload di cifratura.

Il Loader decifra il payload ransomware usando XOR combinato con compressione LZ e lo esegue direttamente in memoria, senza mai scrivere il binario cifrato su disco — una tecnica che complica notevolmente l’analisi forense e il rilevamento da parte degli antivirus tradizionali.

Sul fronte cifratura, la versione 5.0 introduce significativi miglioramenti rispetto alla 4.0:

• Cifratura differenziale basata sulla dimensione dei file: per i file più grandi viene cifrata solo una porzione, massimizzando la velocità dell’attacco e comprimendo la finestra di risposta per i difensori.
• Modulo di cancellazione delle Shadow Copy aggiornato: basato su codice derivato da Conti, ora utilizza le VSS API native di Windows invece degli strumenti da riga di comando, riducendo le tracce nel log degli eventi.
• Patching di EtwEventWrite: disabilita in memoria il Windows Event Tracing for Windows (ETW), cieco di fatto i sistemi di SIEM e EDR che si affidano ai provider nativi.
• Controlli di geolocalizzazione e locale: i campioni escludono automaticamente i sistemi nei paesi della CIS (Comunità degli Stati Indipendenti), un pattern tipico degli operatori ransomware di madrelingua russa.
• Estensioni randomizzate a 16 caratteri: i file cifrati ricevono un’estensione generata casualmente per ogni campagna, impedendo il rilevamento basato su signature statiche.

Multi-piattaforma: Windows, Linux e VMware ESXi nel mirino

Una delle novità più significative di LockBit 5.0 è l’espansione cross-platform. Il gruppo ha sviluppato tre varianti distinte — per Windows, Linux e VMware ESXi — che possono essere deployate in modo coordinato su tutta l’infrastruttura di una vittima.

La variante ESXi è progettata specificamente per cifrare i datastore delle macchine virtuali, paralizzando interi ambienti virtualizzati in un singolo passaggio. Per un’organizzazione enterprise che fa affidamento su VMware, questo significa che server, applicazioni critiche e database possono essere resi inaccessibili simultaneamente, moltiplicando la pressione a pagare il riscatto.

Le vittime di aprile 2026: da Bladex alle logistiche europee

La settimana del 26-27 aprile 2026 ha visto LockBit 5.0 rivendicare una serie di attacchi di profilo elevato, in particolare:

• Bladex (Panama): istituto finanziario multinazionale fondato direttamente dalle banche centrali dei paesi latinoamericani e caraibici. LockBit ha annunciato la pubblicazione dei dati entro 14-15 giorni. Un attacco a un istituto con questo profilo istituzionale ha implicazioni che vanno ben oltre il singolo incidente.
• Merlo Teleskoplader (Germania): produttore tedesco di macchinari industriali; la rivendicazione include potenziale esfiltrazione di dati tecnici e commerciali.
• D. Heinrichs Logistic GmbH (Bremerhaven, Germania): provider logistico nel porto di Bremerhaven, nodo strategico per il commercio europeo.

La concentrazione di vittime tedesche nel settore logistico/industriale suggerisce una campagna mirata, o quantomeno che gli affiliati di LockBit 5.0 stiano attivamente prendendo di mira la filiera produttiva e logistica europea.

Indicatori di compromissione e pattern di attacco

# File system indicators (Windows)
%TEMP%\ReadMeForDecrypt.txt         # Ransom note (naming convention LockBit 5.0)
*.{16-char random extension}         # File cifrati con estensione randomizzata
# Processi sospetti (behavior indicators)
vssadmin.exe (chiamate VSS API native invece di CLI)
wevtutil.exe (possibile log clearing pre-cifratura)
wmic.exe shadowcopy delete
# ETW patching (in-memory)
EtwEventWrite patched -> NOP sled   # Disabilita event tracing Windows
# Geolocation check (CIS exclusion)
GetUserDefaultLCID() / GetLocaleInfoW()  # Controllo locale pre-esecuzione
# Network indicators
Comunicazioni C2 su infrastrutture TOR
Data exfiltration pre-cifratura via tool personalizzato (data theft stage)
# Loader behavior
XOR + LZ decompression in memoria
Nessuna scrittura del payload cifrato su disco (fileless execution)

Il modello RaaS e la resilienza di LockBit

La sopravvivenza di LockBit alle operazioni delle forze dell’ordine non è un caso: è il risultato di un modello RaaS (Ransomware-as-a-Service) progettato con ridondanza in mente. Gli affiliati — decine di gruppi criminali indipendenti che noleggiano il malware in cambio di una percentuale dei riscatti — possono continuare a operare anche quando l’infrastruttura centrale viene sequestrata. Quando il codice e le build vengono trapelate o ricostruite, il lancio di una nuova versione diventa relativamente rapido.

LockBit 5.0 dimostra anche una capacità di adattamento tecnico reale: il patching in memoria di ETW, l’uso delle VSS API invece dei comandi shell, e l’architettura modulare cross-platform non sono aggiornamenti cosmetici ma miglioramenti mirati a sopravvivere agli EDR e ai SIEM di nuova generazione.

Raccomandazioni per i difensori

• Proteggere i backup offline e immutabili: la strategia più efficace contro LockBit rimane avere copie fuori dalla portata del ransomware. I backup connessi alla rete sono sempre stati l’obiettivo primario degli operatori.
• Monitorare le API di Volume Shadow Copy: rilevare chiamate anomale alle VSS API da processi inusuali, non solo l’esecuzione di vssadmin.
• EDR con visibilità sulle patch in-memory: i provider che monitorano l’integrità del codice in memoria (PatchGuard bypass, EtwEventWrite tampering) hanno significativamente più chance di rilevare LockBit 5.0 prima dell’esecuzione del payload.
• Segmentazione rigorosa degli ambienti VMware: i datastore ESXi non devono essere accessibili da host che non abbiano una necessità operativa diretta.
• Threat hunting basato su estensioni randomizzate: configurare alert su mass-rename di file con estensioni sconosciute nei file server critici.
• Verifica della geolocation check: se in un ambiente vengono rilevati controlli di locale da processi inusuali, potrebbe indicare una fase di reconnaissance pre-attivazione del payload.

LockBit 5.0 non è un fantasma del passato. È una minaccia attiva, tecnicamente evoluta e operativamente resiliente. L’attacco a Bladex — un’istituzione finanziaria nata per volontà delle banche centrali di un’intera regione del mondo — è il segnale che nessun settore, nessuna dimensione aziendale e nessuna geografia è fuori dal mirino del gruppo più prolifico del ransomware mondiale.

Chi lavora con agenti AI su basi .NET sa bene che il vero collo di bottiglia non è spesso la qualità del modello, ma il numero di round trip tra il modello stesso e i tool. Un agente che deve recuperare dati, filtrarli, fare calcoli e assemblare un risultato finisce tipicamente per eseguire cinque o sei chiamate separate al modello, ognuna con la propria latenza e il proprio costo in token. Microsoft ha presentato una soluzione concreta a questo problema: CodeAct, ora disponibile nel pacchetto alpha agent-framework-hyperlight.

Il problema: troppi turni, troppa latenza

Nel flusso tradizionale, un agente ragiona come segue: chiede al modello quale tool usare, esegue quel tool, rimanda il risultato al modello, il quale decide il prossimo tool, e così via. Questo schema modello → tool → modello → tool moltiplica la latenza e il consumo di token con ogni step aggiuntivo. Su task composti da tre, quattro o cinque operazioni concatenate (tipico nelle pipeline di data wrangling, elaborazione report, lookup incrociati), il costo diventa significativo.

CodeAct risolve il problema in modo elegante: invece di chiedere al modello di scegliere un tool alla volta, gli viene offerto un singolo tool speciale chiamato execute_code. Il modello esprime l’intero piano come un breve programma Python, che viene eseguito una volta sola in un ambiente sandbox. Il risultato? Latenza ridotta del ~50% e consumo di token calato di oltre il 60% su workload rappresentativi, secondo i dati pubblicati da Microsoft.

Hyperlight: sandbox micro-VM per sicurezza senza compromessi

La parte che rende CodeAct praticabile in produzione è Hyperlight: una tecnologia Microsoft che avvia una micro-VM isolata per ogni esecuzione di codice generato dal modello. Il codice Python prodotto dall’LLM gira dentro questa sandbox, senza accesso al filesystem host, alla rete o a qualsiasi risorsa non esplicitamente autorizzata. I tool reali invece continuano a girare nel runtime dell’applicazione, con tutti i permessi necessari.

Il bridge tra sandbox e tool avviene tramite la funzione call_tool(...): quando il codice nella sandbox chiama call_tool("nome_tool", ...), Hyperlight instrada la chiamata verso il tool nel processo principale, ne ritorna il risultato nella sandbox, e il programma continua. Il codice generato dall’AI rimane isolato; solo i tool verificati e distribuiti dallo sviluppatore hanno accesso reale alle risorse.

Come si integra CodeAct nel proprio agente

Il setup è sorprendentemente compatto. Dopo aver installato i pacchetti agent-framework e agent-framework-hyperlight:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict:
    # Restituisce il meteo corrente per una citta
    return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
    tools=[get_weather],
    approval_mode="never_require",
)

agent = Agent(
    client=client,
    name="CodeActAgent",
    instructions="Sei un assistente utile.",
    context_providers=[codeact],
)

result = await agent.run(
    "Ottieni il meteo di Seattle e Amsterdam e confrontali."
)


Gestione delle approvazioni: chi controlla cosa

Agent Framework distingue due modalità di approvazione per i tool:

• never_require: il framework invoca il tool automaticamente.
• always_require: ogni chiamata viene sospesa in attesa di un’approvazione human-in-the-loop.

Con CodeAct, la logica cambia leggermente. I tool registrati su HyperlightCodeActProvider non vengono esposti direttamente al modello come tool di primo livello: il modello vede solo execute_code e raggiunge gli altri tool scrivendo call_tool("nome", ...) nel programma Python. L’approvazione, se richiesta, si applica all’intero blocco di codice, non alle singole chiamate interne.

La regola pratica è chiara: i tool puri e sicuri (lookup dati, calcoli, chiamate read-only) vanno passati al provider, così il modello li può comporre in un unico turno. I tool con side effect (invio email, scrittura su sistemi in produzione, transazioni economiche) vanno tenuti sull’agente direttamente con approval_mode="always_require", così il modello li deve invocare esplicitamente uno per uno.

Quando conviene usare CodeAct

CodeAct non è la soluzione giusta per ogni agente. I benefici massimi si ottengono con task che coinvolgono molte operazioni concatenate e chainabili: data wrangling, generazione report, lookup multipli, calcoli intermedi. Se il task dell’agente si risolve quasi sempre con una o due chiamate a tool, il guadagno è marginale.

È anche importante considerare che il codice Python generato dal modello deve essere revisionabile: uno dei vantaggi collaterali di CodeAct è che l’intero piano dell’agente è concentrato in un singolo blocco di codice leggibile e auditabile, invece di essere distribuito su una catena di messaggi di tool-call.

Conclusione

CodeAct con Hyperlight rappresenta un’evoluzione pragmatica nell’architettura degli agenti AI su .NET: meno turni, meno token, stessa qualità. Il pattern è disponibile oggi nel pacchetto alpha agent-framework-hyperlight, pronto per essere sperimentato su workload interni prima di adottarlo in produzione. Chi sta già usando Agent Framework e si trova a costruire pipeline di tool-calling complesse troverà probabilmente il guadagno di latenza immediato e concreto.

Fonte: CodeAct in Agent Framework: Faster Agents with Fewer Model Turns – Microsoft Dev Blogs, 23 aprile 2026

Nothing ha esteso la distribuzione di Nothing OS 4.1 a un gruppo più ampio di dispositivi. Dopo il rilascio iniziale sui modelli di punta, il nuovo sistema operativo raggiunge ora Phone 2, Phone 3a, Phone 2a, CMF Phone 1 e CMF Phone 2 Pro, portando a un bacino più vasto di utenti una serie di novità interessanti.

I modelli coinvolti nell’aggiornamento

L’aggiornamento copre sia la linea Nothing Phone sia i dispositivi del brand CMF, che negli ultimi mesi si è affermato come proposta più accessibile dell’ecosistema Nothing. L’approccio inclusivo dell’azienda — che garantisce aggiornamenti anche ai modelli meno recenti — è uno degli elementi che ha contribuito a fidelizzare la propria community.

Schermata di blocco rinnovata e Live Updates

Tra le novità più visibili di Nothing OS 4.1 spicca il redesign della schermata di blocco, con un nuovo font sviluppato in collaborazione con la community degli utenti. Fa il suo debutto anche la funzione Live Updates, che consente di seguire in tempo reale l’avanzamento di attività come ordini, navigazione o consegne direttamente dal lock screen, dalla tendina delle notifiche e persino attraverso l’interfaccia Glyph — i LED sul retro dei dispositivi Nothing.

Notifiche più intelligenti e stabilità migliorata

Anche la gestione delle notifiche riceve attenzioni: l’interfaccia delle impostazioni è stata riorganizzata e il sistema è ora in grado di suggerire automaticamente le notifiche più rilevanti. Sul fronte della stabilità, vengono risolti problemi di stuttering nelle videochiamate, anomalie nella visualizzazione del pannello rapido e vari bug minori. La configurazione delle eSIM è stata resa più intuitiva, e il patch di sicurezza incluso è quello di aprile 2026.

Una funzione non disponibile su tutti i modelli

Va segnalato che Essential Voice, la nuova funzionalità di input vocale avanzato, non sarà disponibile su tutti i dispositivi compatibili con l’aggiornamento. Nothing non ha specificato nel dettaglio quali modelli ne siano esclusi, ma è ragionevole attendersi che dipenda dalle risorse hardware disponibili sui singoli device.

Lo Xiaomi 17T si fa sempre più concreto: un dispositivo con numero di modello 2602DPT53G, identificato tramite documenti di certificazione come futuro Xiaomi 17T, è apparso sul database di Geekbench AI. Il passaggio nel benchmark svela alcuni dei principali parametri tecnici del prossimo smartphone mid-high range del brand cinese.

Chipset Dimensity 8500 e 12 GB di RAM

Stando ai dati emersi, lo Xiaomi 17T monterà un processore octa-core con core ad alte prestazioni che raggiungono i 3,40 GHz, accompagnato da una GPU Mali-G720 MC8. Queste specifiche fanno propendere per il Dimensity 8500 di MediaTek come chipset principale. La RAM sarà da 12 GB, e il sistema operativo sarà basato su Android 16, confermando l’adozione dell’ultima versione del sistema operativo di Google sin dal lancio.

Display 1.5K OLED da 6,59″ e batteria maxi

Sul fronte dello schermo, lo Xiaomi 17T dovrebbe adottare un pannello OLED flat da circa 6,59 pollici con risoluzione di classe 1.5K. La batteria, pur non ancora confermata ufficialmente, si stima possa attestarsi intorno ai 7.000 mAh con supporto alla ricarica rapida da 67W — una dotazione generosa che posiziona il dispositivo come ottimo compagno per un utilizzo intensivo.

La versione Pro punta al Dimensity 9500

La lineup includerà anche uno Xiaomi 17T Pro, atteso con un display ancora più grande, il chip top di gamma Dimensity 9500 e una fotocamera periscopica per lo zoom ottico. Il modello standard si accontenterebbe di un tele tradizionale. Entrambe le versioni condividerebbero comunque una tripla fotocamera da 50+12+50 MP e un sensore frontale da 32 MP.

Lancio imminente

Con la serie Xiaomi 17 di fascia alta già annunciata, la comparsa del 17T su Geekbench suggerisce che i preparativi per il lancio siano in fase avanzata. Il posizionamento price-performance della serie T ha sempre riscosso grande apprezzamento in Europa, e l’edizione 2026 non sembra fare eccezione. L’annuncio ufficiale potrebbe arrivare entro i prossimi mesi.

BleachBit è uno strumento open source per la pulizia di sistema, progettato per aiutare le utenti a recuperare spazio su disco, migliorare le prestazioni e tutelare la privacy eliminando file inutili, cache, cookie e dati...

🔗 Leggi il post completo

CachyOS è una distribuzione GNU/Linux (o distro) “rolling release” basata su Arch Linux, progettata per offrire prestazioni elevate, tempi di risposta ridotti e un’esperienza d’uso ottimizzata. Le sue radici risalgono al 2021, quando gli sviluppatori Peter “ptr1337” Jung e Vladislav “vnepogodin” Nepogodin iniziano...

🔗 Leggi il post completo

Il progetto Asahi Linux, che porta il supporto di GNU/Linux sui computer Apple Silicon, ha pubblicato un nuovo rapporto sui progressi compiuti, con aggiornamenti significativi per il kernel Linux 7.0 e le funzionalità in...

🔗 Leggi il post completo

Volete costruire agenti AI con JavaScript che vadano oltre le semplici chat? Agenti che ragionano, chiamano strumenti esterni e interrogano knowledge base in modo autonomo? Microsoft ha pubblicato un corso gratuito e open source per fare esattamente questo: LangChain.js for Beginners, 8 capitoli con oltre 70 esempi TypeScript eseguibili.

Se già conoscete Node.js, npm, TypeScript e async/await, non avete bisogno di passare a Python per sviluppare applicazioni AI. LangChain.js vi mette a disposizione i componenti necessari — chat model, tool, agenti, retrieval e molto altro — senza dover cablare tutto da zero.

Perché LangChain.js?

LangChain.js è come avere un negozio di ferramenta completamente fornito a portata di mano. Invece di fabbricare ogni strumento dal metallo grezzo, prendete quello che serve dallo scaffale e iniziate a costruire. La libreria astrae l’integrazione con vari LLM (OpenAI, Azure OpenAI, Anthropic e altri), standardizza l’interfaccia per tool e agenti, e fornisce primitive per la costruzione di pipeline RAG.

Il vantaggio rispetto a Python? Zero friction per chi già lavora nell’ecosistema JavaScript/TypeScript. Stessi strumenti di build, stesso toolchain CI/CD, stessa base di codice.

Struttura del corso: un approccio agent-first

La maggior parte dei tutorial su LangChain inizia con document loader ed embedding. Questo corso arriva agli agenti e ai tool presto, perché è lì che si trovano i sistemi AI in produzione. Gli agenti decidono cosa fare, quando usare strumenti, e se hanno bisogno di cercare dati.

Capitoli 1-3: fondamenta

La prima chiamata a un LLM, chat model, streaming, prompt template e output strutturati con schemi Zod. Contenuto classico, ma necessario prima che le cose si facciano interessanti.

Capitolo 4: Function Calling e Tool

Qui l’AI smette di parlare e inizia a fare. Si insegna al modello a chiamare funzioni personalizzate, e lui ragiona su quando usarle. Esempio pratico:

import { ChatOpenAI } from "@langchain/openai";
import { tool } from "@langchain/core/tools";
import { z } from "zod";

const weatherTool = tool(
  async ({ city }) => {
    // chiamata a una API meteo reale
    return `Il meteo a ${city} è soleggiato, 22°C`;
  },
  {
    name: "get_weather",
    description: "Ottieni le condizioni meteo correnti per una città",
    schema: z.object({
      city: z.string().describe("Il nome della città"),
    }),
  }
);

const model = new ChatOpenAI({ model: "gpt-4o" });
const modelWithTools = model.bindTools([weatherTool]);

const result = await modelWithTools.invoke(
  "Che tempo fa a Milano?"
);
console.log(result.tool_calls);

Capitolo 5: Agenti con pattern ReAct

Un LLM risponde a domande. Un agente ragiona attraverso i problemi, sceglie i tool giusti ed esegue piani multi-step. Il capitolo 5 mostra come costruire agenti con il pattern ReAct (Reason + Act): il modello alterna tra pensiero esplicito e azioni concrete fino a raggiungere la risposta finale.

import { createReactAgent } from "@langchain/langgraph/prebuilt";
import { ChatOpenAI } from "@langchain/openai";

const agent = createReactAgent({
  llm: new ChatOpenAI({ model: "gpt-4o" }),
  tools: [weatherTool, searchTool, calculatorTool],
});

const response = await agent.invoke({
  messages: [{ role: "user", content: "Pianifica un itinerario a Roma per domani" }],
});
console.log(response.messages.at(-1)?.content);

Capitolo 6: MCP — Model Context Protocol

Il Model Context Protocol sta diventando lo standard per connettere l’AI a servizi esterni. Il capitolo guida alla costruzione di server MCP e al collegamento degli agenti tramite trasporti HTTP e stdio. È un’abilità sempre più richiesta man mano che l’ecosistema AI aziendale matura.

Capitoli 7 e 8: RAG agentivo

I capitoli finali portano documenti, embedding e ricerca semantica, poi combinano tutto in Agentic RAG. L’agente decide quando cercare nella knowledge base e quando rispondere direttamente da ciò che già conosce.

È una distinzione importante. Il RAG tradizionale è come lo studente che sfoglia il libro di testo per ogni domanda, anche “Quanto fa 2+2?”. Il RAG agentivo è lo studente intelligente che risponde alle domande semplici a memoria e apre il libro solo quando ne ha davvero bisogno. Il risultato: risposte più veloci, costi inferiori (meno ricerche di embedding non necessarie) e un’esperienza complessivamente migliore.

Come iniziare

Il corso è open source su GitHub. Per iniziare bastano tre comandi:

# Clona il repository
git clone https://github.com/microsoft/generative-ai-with-javascript

# Installa le dipendenze
cd generative-ai-with-javascript/lessons/08-langchain/
npm install

# Configura la chiave API
cp .env.example .env
# Aggiungi AZURE_OPENAI_API_KEY o OPENAI_API_KEY nel file .env

# Esegui il primo esempio
npx ts-node chapter1/01-first-llm-call.ts

A chi è rivolto

Il corso si rivolge a sviluppatori JavaScript/TypeScript che conoscono npm install e async/await. Non è richiesta esperienza precedente in AI o machine learning. Ogni capitolo inizia con un’analogia del mondo reale per ancorare il concetto prima di qualsiasi codice.

Per chi già lavora su applicazioni .NET o backend e vuole esplorare il lato AI senza cambiare linguaggio, questo corso rappresenta il punto di ingresso ideale: nessun boilerplate Python, nessun ambiente virtuale da gestire, solo TypeScript e strumenti già familiari.

Considerazioni finali

LangChain.js ha raggiunto una maturità che lo rende adatto a progetti di produzione. Il corso di Microsoft colma un gap reale: la maggior parte della documentazione e dei tutorial sull’AI generativa è orientata a Python. Avere un percorso strutturato, gratuito e orientato agli agenti per l’ecosistema JavaScript è un vantaggio concreto per chi già lavora in questo stack.

Se state valutando come integrare capacità AI nelle vostre applicazioni Node.js o Deno, o se volete costruire un copilota interno per il vostro team, questo è il punto di partenza più pragmatico disponibile oggi.

Fonte originale: LangChain.js for Beginners: A Free Course to Build Agentic AI Apps with JavaScript — Microsoft for Developers

Si parla di:
Toggle

Non serve uno zero-day quando si puo’ semplicemente telefonare. O meglio: mandare un messaggio su Microsoft Teams fingendo di essere il supporto IT aziendale. E’ questa la filosofia operativa di UNC6692, un gruppo di minaccia documentato da Google Threat Intelligence Group (GTIG) e Mandiant il 22 aprile 2026, che ha sviluppato una delle catene di intrusione piu’ efficaci osservate di recente: zero vulnerabilita’ software sfruttate, impatto devastante.

La catena di attacco: dalla casella di posta al dominio compromesso

La campagna di UNC6692 si articola in piu’ fasi con una logica narrativa precisa, progettata per sfruttare i processi cognitivi delle vittime anziche’ le vulnerabilita’ del software. Tutto inizia tra fine dicembre 2025 e i mesi successivi con un’operazione di email bombing: le vittime — prevalentemente dipendenti senior (77% dei casi rilevati) — si trovano improvvisamente sommerse da migliaia di email spam, un’inondazione che paralizza l’attivita’ lavorativa e genera panico.

Nel momento di massima confusione, arriva il soccorso: un messaggio su Microsoft Teams da un account che si presenta come tecnico del supporto IT interno. L’attaccante offre assistenza per il problema email e guida la vittima attraverso una sequenza di azioni apparentemente legittime. Il punto critico e’ il click su un link che porta a una pagina di phishing ospitata su un bucket Amazon S3 — presentata come “Mailbox Repair and Sync Utility v2.1.5”. L’URL su S3 non e’ in lista di blocco di quasi nessun proxy aziendale, e il dominio amazonaws.com gode di alta reputazione nei sistemi di URL filtering.

La suite SNOW: tre strumenti, un’unica operazione

Il download dalla pagina di phishing avvia l’esecuzione di un binario AutoHotKey (RegSrvc.exe) che funge da dropper per l’ecosistema SNOW, una suite malware modulare composta da tre componenti distinti, ciascuno con un ruolo specializzato nella catena di compromissione.

SNOWBELT e’ un backdoor basato su JavaScript, distribuito come estensione Chromium (directory: SysEvents). Viene installato in modalita’ non-supervised attraverso policy forzate, non tramite il Chrome Web Store. Si maschera sotto nomi come “MS Heartbeat” o “System Heartbeat”. Una volta attivo nel browser della vittima, intercetta sessioni autenticate, cookie, token OAuth e qualsiasi credenziale inserita nelle form web. Comunica con il C2 tramite richieste verso bucket S3 in us-east-2, usando un VAPID key fisso come identificatore.

SNOWGLAZE e’ un tunneler Python compatibile con Windows e Linux. La sua funzione primaria e’ creare un tunnel WebSocket autenticato tra il sistema della vittima e l’infrastruttura C2 dell’attaccante, tipicamente un sottodominio Heroku. Questo tunnel permette all’attaccante di instradare traffico RDP, PsExec e altri protocolli attraverso una connessione apparentemente legittima verso Heroku, eludendo i controlli firewall.

SNOWBASIN e’ il backdoor persistente per il controllo remoto completo: esecuzione di comandi via cmd.exe o PowerShell, cattura di screenshot, upload/download di file e auto-terminazione. E’ SNOWBASIN che gestisce la fase di post-exploitation, una volta che il foothold iniziale e’ stabilito.

Post-exploitation: dal PC della vittima al domain controller

L’analisi di Mandiant descrive una sequenza di post-exploitation metodica e aggressiva. Dopo l’installazione della suite SNOW, l’attaccante utilizza SNOWGLAZE per stabilire una sessione PsExec verso il sistema compromesso, poi avvia una scansione della rete locale alla ricerca di sistemi raggiungibili su porte 135 (RPC), 445 (SMB) e 3389 (RDP). Una volta identificato un server di backup, SNOWGLAZE viene usato per instradare una sessione RDP verso di esso.

Sul server di backup avviene la fase critica: l’attaccante usa Windows Task Manager per eseguire il dump del processo LSASS (Local Security Authority Subsystem Service), catturando in chiaro tutti gli hash delle password degli account autenticati sul sistema, inclusi account privilegiati con accesso al dominio Active Directory. Il file di dump viene esfiltrato via LimeWire attraverso il tunnel SNOWGLAZE. Con gli hash estratti, e’ possibile effettuare attacchi pass-the-hash per autenticarsi come qualsiasi account del dominio, portando alla compromissione completa dell’infrastruttura AD.

Indicatori di compromissione (IoC)

# URL phishing (pattern)
https://service-page-[ID]-outlook.s3.us-west-2.amazonaws.com/update.html?email=

# C2 SNOWGLAZE (WebSocket)
wss://sad4w7h913-b4a57f9c36eb[.]herokuapp[.]com:443/ws

# C2 SNOWBELT (pattern URL S3)
https://[a-f0-9]{24}-[0-9]{6,7}-[0-9]{1}.s3.us-east-2.amazonaws[.]com

# SNOWBELT VAPID Key
BJkWCT45mL0uvV3AssRaq9Gn7iE2N7Lx38ZmWDFCjwhz0zv0QSVhKuZBLTTgAijB12cgzMzqyiJZr5tokRzSJu0

# File sospetti (dropper)
RegSrvc.exe    # binario AutoHotKey rinominato
Protected.ahk  # script AHK malevolo

# Directory estensione Chrome malevola
SysEvents/  # in %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions

# Hash SHA256
SNOWGLAZE: 2fa987b9ed6ec6d09c7451abd994249dfaba1c5a7da1c22b8407c461e62f7e49
SNOWBELT background.js: 7f1d71e1e079f3244a69205588d504ed830d4c473747bb1b5c520634cc5a2477

Attribuzione e contesto

UNC6692 e’ classificato da Google/Mandiant come UNC (Uncategorized): non e’ ancora stata stabilita un’attribuzione definitiva a un paese o gruppo noto. Il profilo operativo mostra tuttavia caratteristiche interessanti: capacita’ di sviluppo malware custom elevate, pazienza tattica (la campagna di email bombing precede l’attacco di settimane) e una chiara preferenza per obiettivi aziendali con accesso privilegiato a infrastrutture IT. L’assenza di exploit zero-day puo’ indicare sia un operatore esperto che preferisce metodi OPSEC-sicuri, sia un gruppo finanziariamente motivato che ha ottimizzato il rapporto costo/impatto delle proprie operazioni.

Consigli per i difensori

La campagna UNC6692 mette in evidenza lacune difensive comuni negli ambienti enterprise. Sul fronte delle policy Microsoft Teams, e’ fondamentale limitare la possibilita’ per utenti esterni di contattare dipendenti interni tramite Teams: configurare una allowlist dei tenant esterni autorizzati e’ il primo passo. Sul fronte della protezione da email bombing, implementare rate limiting e filtri anti-spam aggressivi con alert su aumenti anomali di volume per singolo account. Per la protezione del browser, deployare policy Group Policy che blocchino l’installazione di estensioni Chrome non approvate e monitorare la creazione di nuove directory in %LOCALAPPDATA%. Monitorare il traffico verso sottodomini Heroku e bucket S3 non registrati come legittimi nel proprio inventario cloud. Infine, proteggere LSASS con Credential Guard su tutti i sistemi Windows 10/11 e Server 2019+: questa misura da sola avrebbe bloccato la fase piu’ critica dell’attacco documentato.

La campagna UNC6692/SNOW e’ un esempio paradigmatico di come il perimetro piu’ difficile da difendere non sia tecnico, ma umano: un dipendente stressato da un’inondazione di spam e “soccorso” da un collega del supporto IT e’ una vittima quasi inevitabile, indipendentemente dalla sofisticazione dell’infrastruttura di sicurezza aziendale.

I possessori di Google Pixel 8 e Pixel 9 stanno segnalando con crescente frequenza un problema serio: dopo i recenti aggiornamenti di marzo e aprile 2026, i dispositivi mostrano evidenti rallentamenti, lag nelle animazioni e instabilità generale. La situazione ha portato alcuni utenti a ipotizzare scenari preoccupanti sul comportamento di Google nei confronti dei propri flagship.

Cosa sta succedendo ai Pixel dopo gli aggiornamenti

I sintomi riportati dalla community sono concreti e diffusi: avvio lento delle app, scrolling a scatti, input da tastiera che si blocca a metà, crash ripetuti. Non si tratta di episodi isolati ma di un fenomeno che colpisce in modo sistematico chi ha installato le patch mensili degli ultimi due mesi. In alcuni casi, applicazioni solitamente leggere come le mappe stentano a rispondere correttamente.

Una serie di problemi che si accumulano

Quello delle prestazioni calanti non è l’unico capitolo negativo recente per la serie Pixel. L’aggiornamento di marzo aveva causato un problema di bootloop che rendeva alcuni dispositivi inutilizzabili al riavvio, mentre ad aprile erano emersi anomali consumi della batteria. La sequenza ravvicinata di questi episodi sta erodendo la fiducia di una parte degli utenti, che non si spiegano come un brand premium possa accumulare così tanti problemi in poco tempo.

Il calore e il throttling come possibili cause

Sul piano tecnico, una delle ipotesi più accreditate riguarda il surriscaldamento del chip Tensor. Quando la temperatura sale oltre certi limiti, il processore riduce automaticamente le proprie frequenze per proteggersi — il cosiddetto thermal throttling. Se un aggiornamento software aumenta il carico di background, questo meccanismo potrebbe attivarsi in modo persistente, spiegando il degrado delle prestazioni. Tuttavia, al momento non ci sono conferme ufficiali su questa correlazione.

Obsolescenza pianificata: un’accusa senza prove, ma con una logica

In assenza di spiegazioni ufficiali da parte di Google, si è fatta strada tra gli utenti più esasperati l’ipotesi dell’obsolescenza pianificata: rallentare deliberatamente i vecchi modelli per spingere all’acquisto di nuovi dispositivi. È un’accusa grave — già mossa in passato ad Apple con esiti giudiziari rilevanti — e allo stato attuale priva di prove concrete. Eppure la sovrapposizione di più problemi gravi in così poco tempo rende difficile escludere del tutto la possibilità che qualcosa non vada nella gestione degli aggiornamenti.

Le soluzioni disponibili (e i loro limiti)

Google non ha ancora rilasciato una risposta pubblica dettagliata. Nel frattempo, i workaround suggeriti dalla community — reset alle impostazioni di fabbrica, avvio in modalità provvisoria, disattivazione del Wi-Fi in favore dei dati mobili — offrono risultati parziali e non risolutivi. Gli utenti attendono un intervento correttivo rapido, nella speranza che la prossima patch mensile riporti i Pixel a funzionare come dovrebbero.

L’account Instagram ufficiale di Sony ha pubblicato per errore il nome di un modello non ancora annunciato: Xperia 1 VIII. Il post è stato rimosso rapidamente, ma non prima che gli appassionati ne notassero il contenuto, alimentando ulteriormente le speculazioni sull’imminente arrivo della prossima ammiraglia del marchio giapponese.

Un refuso rivelatore

L’immagine del post mostrava chiaramente un dispositivo riconoscibile come Xperia 1 VII — stesso design, stessa tripla fotocamera verticale sul retro. La stranezza stava nel testo: la scritta “Xperia 1 VIII” accompagnava visivamente un dispositivo che è l’attuale flagship. Si tratta quasi certamente di un errore di copia-incolla commesso da chi gestisce i social media di Sony, ma l’effetto è stato quello di confermare indirettamente l’esistenza del nome del prossimo modello.

Design completamente rinnovato in arrivo

La notizia si inserisce in un contesto già ricco di indiscrezioni. Secondo fonti ritenute attendibili, Xperia 1 VIII porterà un restyling estetico significativo rispetto ai suoi predecessori. Sarebbero già circolati rendering CAD definiti “quasi ufficiali” che mostrano le dimensioni e le linee del nuovo dispositivo, confermando un cambio di rotta nel design rispetto alla serie attuale.

Cosa aspettarsi dal prossimo top di gamma Sony

La serie Xperia 1 ha da sempre puntato su un pubblico di appassionati che apprezza il display 4K OLED in formato 21:9, il sistema di fotocamere con ottiche Zeiss e le funzionalità di monitoraggio audio e video professionali. Il fatto che il successore si stia avvicinando — e che addirittura il nome sia già “sfuggito” sui canali ufficiali — suggerisce che l’annuncio ufficiale potrebbe essere a pochi mesi di distanza. Gli occhi degli Xperia fan sono ora puntati sulle prossime comunicazioni di Sony.

Non molto tempo fa abbiamo raccontato della creazione del fork di ONLYOFFICE chiamato Euro-Office, un’iniziativa europea guidata da NextCloud e IONOS il cui scopo è provare a rendere “Made in Europe” la piattaforma che attualmente è sviluppata per la maggioranza in Russia. La vicenda, per ovvi motivi, unisce svariati temi che spaziano dalla geopolitica alla...

🔗 Leggi il post completo

Gli oggetti cambiano comportamento in base al loro stato interno continuamente. Un documento passa da bozza a revisione a pubblicato. Un personaggio di un gioco alterna tra inattivo, in corsa e in attacco. Un pagamento transita da pending ad autorizzato a catturato. La domanda quando usare lo State Pattern in C# emerge nel momento in cui la logica condizionale inizia a ramificarsi sullo stesso campo stato in metodo dopo metodo — e ogni nuovo stato obbliga a toccare più file.

In questo articolo troverete una guida decisionale pratica per il pattern State in C#: quando merita davvero il suo posto e quando soluzioni più semplici — enum o flag booleani — bastano e avanzano.

Cos’è lo State Pattern e cosa fa davvero

Lo State Pattern consente a un oggetto di cambiare il proprio comportamento quando il suo stato interno cambia. Dall’esterno sembra che l’oggetto abbia cambiato classe. Invece di sparpagliare istruzioni if e switch in ogni metodo che dipende dallo stato corrente, si incapsula il comportamento di ciascuno stato in una propria classe. L’oggetto delega al state object attivo in quel momento.

La struttura coinvolge tre ruoli:

• Context — mantiene un riferimento allo state object corrente e vi delega il comportamento
• State interface — dichiara i metodi che ogni stato deve implementare
• Concrete state classes — implementano l’interfaccia con il comportamento specifico del loro stato

Quando avviene una transizione, il context sostituisce il riferimento al proprio state object. Questo approccio elimina i blocchi condizionali che crescono ogni volta che si aggiunge uno stato nuovo.

Segnali che indicano che avete bisogno dello State Pattern

Non ogni oggetto con un campo status ha bisogno dello State Pattern. Tuttavia certi code smell sono segnali forti che il pattern ripulirà il design.

La logica condizionale si ramifica sullo stesso stato ovunque

Questo è il trigger principale. Quando vedete lo stesso switch o if-else che controlla _status in tre, quattro o dieci metodi diversi, il vostro oggetto sta gestendo le transizioni di stato nel modo più difficile. Ogni nuovo stato significa toccare ciascuno di quei metodi.

Avete regole di transizione complesse

Se le transizioni valide dipendono dallo stato attuale — e alcune azioni devono lanciare eccezioni o essere semplicemente ignorate a seconda di dove ci si trova — il pattern State rende queste regole esplicite invece di affogarle in condizionali.

Ogni stato ha un comportamento distinto

Quando lo stato influenza come si comporta un metodo, non soltanto se eseguirlo, il pattern vale l’investimento. Ciascuna classe stato diventa un luogo coeso che racchiude tutto il comportamento per quella condizione.

Scenario 1: gestione degli ordini (comportamento condizionale complesso)

Ecco un esempio di elaborazione ordini con lo State Pattern:

public interface IOrderState
{
    void Submit(OrderContext context);
    void Cancel(OrderContext context);
    void Ship(OrderContext context);
    void Deliver(OrderContext context);
}

public sealed class OrderContext
{
    public IOrderState CurrentState { get; private set; }
    public string OrderId { get; }

    public OrderContext(string orderId)
    {
        OrderId = orderId;
        CurrentState = new PendingState();
    }

    public void TransitionTo(IOrderState state)
    {
        Console.WriteLine(
            $"Order {OrderId}: " +
            $"{CurrentState.GetType().Name} -> " +
            $"{state.GetType().Name}");
        CurrentState = state;
    }

    public void Submit() => CurrentState.Submit(this);
    public void Cancel() => CurrentState.Cancel(this);
    public void Ship()   => CurrentState.Ship(this);
    public void Deliver() => CurrentState.Deliver(this);
}

public sealed class PendingState : IOrderState
{
    public void Submit(OrderContext context)
    {
        Console.WriteLine("Ordine inviato per elaborazione.");
        context.TransitionTo(new ProcessingState());
    }

    public void Cancel(OrderContext context)
    {
        Console.WriteLine("Ordine annullato prima dell'invio.");
        context.TransitionTo(new CancelledState());
    }

    public void Ship(OrderContext context) =>
        throw new InvalidOperationException("Impossibile spedire un ordine in attesa.");

    public void Deliver(OrderContext context) =>
        throw new InvalidOperationException("Impossibile consegnare un ordine in attesa.");
}

Scenario 2: workflow e gestione dei processi

Un caso d’uso classico è la gestione di una domanda con audit trail integrato:

public interface IApplicationState
{
    string StatusName { get; }
    void Review(ApplicationContext context);
    void Approve(ApplicationContext context);
    void Reject(ApplicationContext context);
    void RequestInfo(ApplicationContext context);
}

public sealed class ApplicationContext
{
    public IApplicationState CurrentState { get; private set; }
    public string ApplicantName { get; }
    public List<string> AuditLog { get; } = new();

    public ApplicationContext(string applicantName)
    {
        ApplicantName = applicantName;
        CurrentState = new SubmittedState();
        Log("Domanda inviata");
    }

    public void TransitionTo(IApplicationState state)
    {
        Log($"Transizione a {state.StatusName}");
        CurrentState = state;
    }

    public void Log(string message) =>
        AuditLog.Add($"[{DateTime.UtcNow:u}] {message}");
}

Scenario 3: gestione dello stato di un personaggio in un gioco

I giochi sono un esempio naturale: un personaggio che alterna tra IdleState, RunningState, AttackingState e DyingState beneficia enormemente di questo pattern, poiché ciascuno stato ha logica di input e di update completamente diversa.

Quando NON usare lo State Pattern

Il pattern non è sempre la risposta giusta. Evitate di applicarlo nei seguenti casi:

• Stati booleani semplici: se l’oggetto ha solo attivo e inattivo, un campo booleano è più chiaro e diretto.
• Pochi stati senza transizioni significative: se avete due o tre stati con poco comportamento differenziato, gli enum bastano.
• La logica di transizione è esterna all’oggetto: se le decisioni di cambio stato appartengono a un orchestratore esterno, il pattern State aggiunge complessità senza benefici.

State Pattern vs alternative: quando scegliere cosa

Un enum con un switch è la scelta giusta quando gli stati sono pochi, stabili e il comportamento differisce solo su una o due dimensioni. Appena gli stati crescono, il comportamento diverge significativamente per metodo, o le transizioni diventano complesse, è il momento di passare al pattern State.

Il pattern State non è la stessa cosa del pattern Strategy: Strategy cambia l’algoritmo usato per una singola operazione, mentre State cambia il comportamento complessivo dell’oggetto al variare della condizione interna. Possono tuttavia lavorare insieme: una transizione di stato può emettere eventi che degli Observer gestiscono.

Integrazione con Dependency Injection

Una domanda comune è se il pattern State si integri bene con la DI di ASP.NET Core. La risposta è sì, con qualche accorgimento: le classi stato concrete possono essere registrate nel contenitore DI, ma è consigliabile usare factory o ActivatorUtilities.CreateInstance per creare le istanze in modo da evitare cicli nel contenitore.

Conclusione

Lo State Pattern in C# risolve un problema preciso: oggetti il cui comportamento cambia radicalmente al variare dello stato interno, con transizioni complesse e comportamento specifico per stato. Prima di applicarlo, fate questa verifica rapida: contate quante volte controllate lo stesso campo di stato in metodi diversi. Se la risposta supera tre o quattro, probabilmente il pattern vi risparmierà mesi di manutenzione futura.

La regola d’oro rimane: preferite sempre la soluzione più semplice che risolve il problema. Un enum con uno switch è più leggibile di una gerarchia di classi per casi banali. Ma quando la complessità cresce, lo State Pattern offre un’architettura che scala senza sforzo.

Fonte originale: When to Use State Pattern in C#: Decision Guide with Examples — Dev Leader

Una campagna di supply chain attack di nuova generazione non aspetta di essere scoperta: prima si mimetizza, poi colpisce. È questa la logica dietro GlassWorm, un attore malevolo che ha trasformato il marketplace Open VSX in un campo minato di estensioni apparentemente legittime, pronte ad attivarsi dopo settimane di apparente innocenza.

La nuova ondata: 73 estensioni sleeper identificate

Il 25 aprile 2026, i ricercatori di Socket hanno pubblicato un’analisi approfondita rilevando 73 nuove estensioni per Open VSX — il registry alternativo a Visual Studio Marketplace, utilizzato principalmente dagli sviluppatori di VSCodium e Eclipse Theia — che mostrano caratteristiche riconducibili alla campagna GlassWorm. Almeno sei di queste estensioni si sono già “svegliate”, aggiornandosi per distribuire payload malevoli, mentre le restanti rimangono classificate come sleeper ad alta confidenza in attesa di attivazione.

Il meccanismo è elegante nella sua perversità: le estensioni vengono pubblicate con codice pulito, superano i controlli automatici del marketplace, accumulano installazioni e fiducia degli utenti — poi, attraverso un aggiornamento silenzioso o aggiungendo una dipendenza malevola, si trasformano in vettori di malware. Nessun exploit, nessun CVE: pura abuso della fiducia nella supply chain del software.

Evoluzione di una campagna persistente

GlassWorm non è un attore nuovo. La campagna è attiva almeno dal tardo 2024, con escalation progressive che si sono succedute nel corso del 2025-2026. A dicembre 2025 furono rilevate le prime 24 estensioni impersonatrici; a febbraio 2026 si scoprì che un account sviluppatore compromesso era stato usato per propagare il malware; a marzo 2026 la campagna scalò a 72 estensioni attive su Open VSX con diffusione tramite abuso di dipendenze. L’ondata di aprile 2026 rappresenta dunque l’evoluzione più sofisticata finora osservata.

Gli obiettivi rimangono costanti: furto di segreti di sviluppo (API key, token, credenziali), svuotamento di wallet di criptovalute, e trasformazione dei sistemi infetti in proxy per ulteriori attività criminali. Il target primario sono sviluppatori che lavorano su macOS, Linux e Windows con ambienti basati su VS Code o suoi fork.

Tecniche di attacco: la profondità della sleeper strategy

L’analisi di Socket rivela una serie di pattern tecnici ricorrenti nell’attuale cluster di 73 estensioni. I publisher sono account GitHub neonati, con una o due repository pubbliche: una repository vuota con nome composto da otto caratteri casuali e una contenente il codice dell’estensione. Questo pattern serve a superare le verifiche di identità del marketplace, che richiedono un profilo GitHub associato.

Le estensioni impersonano utility popolari — ad esempio il language pack turco per VS Code — usando la stessa icona, un nome simile e contenuti copiati dal pacchetto legittimo. Una volta guadagnata la fiducia degli utenti, la delivery del malware avviene in due modalità principali: aggiornamento diretto dell’estensione per includere codice offuscato, oppure aggiunta di una dipendenza da un’estensione separata che contiene il loader GlassWorm, sfruttando il fatto che l’installazione di un’estensione può portare all’installazione automatica di tutte le sue dipendenze dichiarate.

I payload attivati al momento includono: VSIX malevoli ospitati su GitHub, binari nativi firmati con certificati rubati, JavaScript offuscato con tecniche di code splitting per sfuggire all’analisi statica. Il loader GlassWorm, una volta eseguito nell’ambiente VS Code, ha accesso allo stesso filesystem, alle variabili d’ambiente e ai token di sessione dell’IDE — un privilegio enorme che permette di esfiltrare le credenziali di ogni servizio cloud configurato nello strumento di sviluppo.

Contesto più ampio: l’ecosistema VS Code come vettore sistemico

GlassWorm rappresenta un sintomo di una vulnerabilità strutturale: gli ecosistemi di estensioni per editor di codice sono intrinsecamente difficili da proteggere. A differenza dei package manager come npm o PyPI, dove esiste una cultura più consolidata di analisi della sicurezza, i marketplace di estensioni IDE tendono ad avere meccanismi di revisione più leggeri e una percezione del rischio più bassa da parte degli utenti. Un desarrollatore che installa un’estensione VS Code raramente si chiede se stia introducendo un RAT nella propria workstation.

La tecnica della sleeper extension è particolarmente insidiosa perché richiede pazienza da parte dell’attaccante — una caratteristica tipica di campagne sponsorizzate da attori con risorse significative. Non è ancora stata stabilita un’attribuzione definitiva per GlassWorm, ma il livello di sofisticazione e persistenza suggerisce un gruppo criminale strutturato o un attore nation-state interessato alla compromissione di pipeline di sviluppo software.

Indicatori di compromissione (IoC)

# Pattern publisher malevoli (account GitHub)
- Account con repository vuota a nome di 8 caratteri esadecimali
- Account creati tra gennaio e aprile 2026 senza storia pubblica

# Pattern nomi estensioni sospette (esempi noti)
- Estensioni che impersonano language pack (es. Turkish Language Pack for VSCode)
- Estensioni con nomi che differiscono di un carattere da quelle legittime

# Comportamenti runtime sospetti
- Lettura di variabili d'ambiente (PATH, HOME, credenziali cloud)
- Connessioni in uscita verso bucket S3 su us-east-2 o us-west-2
- Caricamento dinamico di script da URL GitHub Raw

# Repository di tracking
https://socket.dev/glassworm-v2  (lista aggiornata estensioni maligne)

Consigli per i difensori

Per chi gestisce ambienti di sviluppo, alcune misure concrete. Prima di tutto, applicare policy di allowlist per le estensioni VS Code/VSCodium approvate, impedendo l’installazione di estensioni non verificate dall’organizzazione. Monitorare con strumenti come Socket o Phylum le dipendenze dei progetti, incluse quelle delle estensioni IDE. Configurare il traffico di rete delle workstation degli sviluppatori per rilevare connessioni anomale verso S3 bucket sconosciuti o hostname Heroku. Abilitare la telemetria degli IDE aziendali e integrarla nel SIEM per rilevare accessi insoliti al keychain o alle variabili d’ambiente. Infine, considerare l’adozione di ambienti di sviluppo containerizzati o in sandbox, dove l’impatto di un’estensione compromessa è limitato al container.

Socket mantiene una pagina dedicata al tracking di GlassWorm v2 con l’elenco aggiornato delle estensioni malevole identificate: consultarla periodicamente è una misura di igiene minima per chi usa Open VSX. La campagna è ancora attiva e il numero di sleeper non ancora attivati — stimato in oltre 60 — suggerisce che il peggio non sia ancora avvenuto.

Emergono nuovi dettagli sul prossimo flagship di Sony: l’Xperia 1 VIII potrebbe arrivare in quattro colorazioni, con una new entry che non si vedeva da tempo nella lineup del brand giapponese. Un leak proveniente da un gruppo Facebook dedicato agli appassionati Xperia svela quella che potrebbe essere la palette definitiva del dispositivo.

Le quattro colorazioni trapelate

L’informazione arriva da un membro affidabile della community Xperia su Facebook: si tratta dell’amministratore del gruppo, che vanta contatti con i rivenditori Sony in Vietnam e che in passato ha già fornito anticipazioni rivelatesi accurate. Secondo questa fonte, Xperia 1 VIII sarà disponibile in quattro varianti cromatiche:

• Nero
• Rosso
• Bianco
• Giallo

Se l’ipotesi di quattro colorazioni era già emersa in precedenza, questa è la prima volta che viene svelata la composizione specifica della palette. E la vera sorpresa è il giallo.

Il giallo torna nella lineup Xperia

Negli ultimi anni Sony ha puntato su colorazioni sobrie e austere per la sua serie flagship, privilegiando toni neutri e scuri. L’introduzione di un giallo vivace rappresenta quindi un cambio di rotta significativo, capace di ridare slancio visivo alla lineup. Bisogna risalire ai tempi dell’Xperia Z5 per trovare colorazioni altrettanto audaci nella gamma premium di Sony — e anche allora si trattava più di sfumature dorate che di un vero giallo.

Se la notizia fosse confermata, Xperia 1 VIII potrebbe distinguersi in modo netto dalla concorrenza, attirando utenti che cercano uno smartphone premium ma con una personalità estetica più marcata.

Design rinnovato: addio al modulo verticale

Le colorazioni non sono l’unica novità attesa per Xperia 1 VIII. Informazioni precedenti indicano che Sony starebbe abbandonando il tradizionale modulo fotocamera verticale in favore di un layout quadrato, avvicinandosi alle scelte stilistiche di altri produttori. Un cambiamento che, unito a colori più vivaci come il rosso e il giallo, potrebbe rinnovare in modo deciso l’identità visiva del brand.

La combinazione di un design rinnovato e di una palette più audace potrebbe rappresentare per Sony l’opportunità di ampliare il proprio pubblico, raggiungendo utenti che in passato consideravano Xperia troppo sobria sul piano estetico.

Presentazione imminente

Seguendo il calendario tradizionale di Sony, Xperia 1 VIII dovrebbe essere presentato nelle prossime settimane. Il fatto che emergano dettagli così specifici sulle colorazioni — tipicamente tra gli ultimi dettagli a essere definiti — suggerisce che il lancio sia davvero vicino. L’annuncio ufficiale chiarirà se il giallo farà effettivamente la sua comparsa nella lineup: l’attesa è già alta.

Classificare automaticamente i documenti aziendali è uno di quei problemi che, a prima vista, sembra un caso d’uso ideale per i modelli AI. Ma in ambienti di produzione, la stabilità, la tracciabilità e la prevedibilità del comportamento spesso contano più della flessibilità. In questo articolo vediamo come implementare un classificatore di documenti rule-based, ponderato e completamente spiegabile in C# .NET, senza toccare un singolo modello di machine learning.

Perché non partire dall’AI?

I modelli AI per la classificazione di testo sono potenti, ma introducono una serie di criticità in contesti enterprise:

• Non-determinismo: lo stesso documento può ricevere classificazioni diverse a seconda della versione del modello, del wording del prompt o di aggiornamenti interni del provider.
• Opacità: spiegare a un responsabile compliance perché il modello ha classificato un contratto come “fattura” è praticamente impossibile.
• Dipendenza da pipeline di dati: aggiornare il classificatore richiede raccolta di dati, rietichettatura, riaddestramento e deployment.

Un approccio deterministico e rule-based risolve tutti e tre i problemi: stesso input, stesso output, sempre. Ogni decisione è tracciabile e modificabile senza toccare il codice, solo aggiornando un file di configurazione JSON.

Architettura del classificatore

Il sistema segue una pipeline chiara:

1. Caricamento dei profili di classificazione da file JSON
2. Apertura del documento .docx con TX Text Control
3. Estrazione del testo da corpo, intestazioni e piè di pagina
4. Rilevamento delle regioni strutturali (titolo, heading, corpo, header, footer)
5. Matching delle regole per categoria con strategie configurabili
6. Calcolo degli score ponderati per categoria
7. Restituzione della categoria vincente con confidence score e spiegazione dettagliata

L’elemento chiave è che tutta la logica di classificazione vive nel file JSON, non nel codice. Questo significa che un domain expert (non un developer) può modificare e migliorare il classificatore semplicemente editando la configurazione.

Il file di configurazione

Ogni categoria è descritta da un insieme di regole. Ogni regola specifica:

• term: il termine o la frase da cercare
• weight: il peso del contributo di questa regola allo score
• matchMode: la strategia di matching (Phrase, WholeWord, Contains)
• strength: la forza del segnale (Strong, Weak)

Esempio per la categoria “Resume”:

{
  "name": "Resume",
  "rules": [
    {
      "term": "work experience",
      "weight": 3.0,
      "matchMode": "Phrase",
      "strength": "Strong"
    },
    {
      "term": "email",
      "weight": 1.0,
      "matchMode": "WholeWord",
      "strength": "Weak"
    }
  ]
}

Estrazione strutturata con TX Text Control

Il classificatore non tratta il documento come un blocco di testo piatto. Usando TX Text Control .NET Server, estrae il contenuto per regioni strutturali:

using var textControl = new ServerTextControl();
textControl.Create();
textControl.Load(docxPath, StreamType.WordprocessingML);

• textControl.Paragraphs → testo del corpo
• textControl.Sections → HeadersAndFooters → intestazioni e piè di pagina di ogni sezione

Questa distinzione è fondamentale: nelle fatture, i termini identificativi come “FATTURA N.” appaiono tipicamente all’inizio del documento o nel titolo. Nei report, il tipo di documento è spesso incorporato nell’header. Ignorare queste regioni significherebbe perdere segnali classificatori di primo livello.

Structure Awareness: non tutto il testo vale uguale

Il miglioramento più significativo rispetto al semplice keyword matching è la consapevolezza della struttura. Il classificatore assegna pesi diversi agli stessi termini a seconda della regione in cui appaiono:

• Un termine nel titolo del documento ha peso massimo: è quasi certamente indicativo del tipo di documento
• Un termine in un heading H1/H2 ha peso alto
• Lo stesso termine nel corpo del documento ha peso standard
• Nel footer (tipicamente template boilerplate) il peso è ridotto

Questo approccio riflette come un essere umano leggerebbe effettivamente il documento: prima si guarda il titolo, poi le intestazioni principali, infine il corpo.

Scoring, confidence e spiegabilità

Al termine dell’analisi, il sistema restituisce non solo la categoria vincente, ma anche:

• Il confidence score (rapporto tra lo score della categoria vincente e la somma degli score di tutte le categorie)
• Una spiegazione dettagliata: quali regole hanno fatto match, in quale regione, con quale peso

Questa tracciabilità è essenziale per scenari di audit e compliance. Se un documento viene classificato erroneamente, il problema è sempre identificabile e correggibile: si modifica la regola nel JSON e si riclassifica. Nessun riaddestramento, nessuna nuova pipeline di dati.

Quando usare questo approccio (e quando no)

L’approccio deterministico è ottimale quando:

• Il set di categorie è definito e stabile (fatture, contratti, report, CV, ecc.)
• La compliance e l’auditability sono requisiti primari
• Il volume di documenti è alto e la velocità di classificazione è critica
• Non si dispone di dataset etichettati sufficienti per addestrare un modello

Dove l’AI rimane superiore è nei casi con categorie ambigue, linguaggio naturale molto variabile, o quando il set di categorie evolve rapidamente e non si vuole aggiornare manualmente le regole. Un’architettura ibrida – classificazione rule-based come primo filtro, AI solo per i casi borderline – è spesso la soluzione migliore in produzione.

Conclusione

La classificazione documentale senza AI non è un’alternativa di ripiego: è una scelta ingegneristica deliberata per sistemi che richiedono stabilità, spiegabilità e controllo. Il pattern rule-based, ponderato e configuration-driven descritto in questo articolo è già in uso in ambienti di produzione enterprise e offre vantaggi concreti in termini di manutenibilità e trasparenza.

Se il vostro stack include la gestione di documenti .docx in C#, questo approccio vale la pena di essere valutato prima di introdurre la complessità di un modello ML.

Fonte: Document Classification Without AI: Deterministic, Explainable, and Built for Production in C# .NET – Bjoern Meyer, TX Text Control Blog

Il Dipartimento di Giustizia degli Stati Uniti ha sferrato un attacco coordinato contro uno dei nodi più oscuri del cybercrimine organizzato in Asia sudorientale: lo Scam Center Strike Force ha incriminato due cittadini cinesi per aver gestito il compound Shunda Park in Myanmar, mentre l’OFAC ha sanzionato il senatore cambogiano Kok An e 28 entità collegate. L’operazione ha portato al sequestro di 503 siti web falsi di investimento in criptovalute e al recupero di oltre 562 milioni di dollari.

Lo Scam Center Strike Force e l’operazione Level Up

L’operazione è stata condotta nell’ambito di due iniziative parallele: Operation Level Up, focalizzata sul contrasto delle truffe di crypto-investimento, e lo Scam Center Strike Force, task force interagenziale del DoJ dedicata allo smantellamento dei compound criminali del Sudest asiatico. Complessivamente, le azioni coordinate hanno interrotto circa 9.000 casi di frode con criptovalute e bloccato oltre 700 milioni di dollari in asset digitali legati al riciclaggio di denaro.

I due imputati principali, Huang Xingshan e Jiang Wen Jie, sono stati incriminati per cospirazione in frode telematica. Huang Xingshan avrebbe supervisionato il controllo coercitivo sui lavoratori trafficked nel compound, mentre Jiang Wen Jie dirigeva direttamente le operazioni di scam. Entrambi si trovano attualmente in custodia in Thailandia, dove erano stati arrestati all’inizio del 2026 per violazioni delle leggi sull’immigrazione nel tentativo di rientrare in Myanmar.

Shunda Park: anatomia di un compound criminale

Il compound Shunda Park si trovava nel villaggio di Min Let Pan, nello Stato del Karen (Myanmar), in una zona controllata da milizie locali nella regione di confine con la Thailandia. Ha operato da almeno gennaio 2025 fino a novembre 2025, quando è stato sequestrato dal Karen National Liberation Army (KNLA). Questa dinamica rivela un dato significativo: i compound criminali del Sudest asiatico operano spesso in zone dove l’autorità statale è frammentata o assente, appoggiandosi a milizie e strutture paramilitari.

Secondo la documentazione del DoJ, le vittime dei reclutatori venivano attratte con offerte di lavoro ben retribuito in Thailandia nel settore tecnologico. Una volta giunte nella zona, i documenti d’identità venivano confiscati e i soggetti venivano trafficati in Myanmar e costretti a lavorare sotto minaccia di violenza. Le testimonianze raccolte dall’FBI descrivono condizioni di lavoro forzato in un’operazione industriale di frode.

Il meccanismo del “pig butchering”

Le truffe perpetrate da Shunda Park seguivano il classico schema del pig butchering (in cinese: 杀猪盘, shā zhū pán): i truffatori stabilivano relazioni personali con le vittime attraverso piattaforme di social networking e app di dating, costruendo nel tempo un rapporto di fiducia. Una volta guadagnata la fiducia della vittima, la conversazione veniva progressivamente indirizzata verso presunte opportunità di investimento in criptovalute su piattaforme false create ad hoc. Le vittime venivano incoraggiate a depositare somme crescenti, con la promessa di rendimenti straordinari visualizzati su dashboard manipolate, fino a quando i truffatori sparivano con i fondi.

Questa tecnica è particolarmente efficace perché i criminali dedicano settimane o mesi alla costruzione del rapporto, rendendo le vittime emotivamente investite prima di introdurre il componente finanziario. Le perdite individuali documentate nei casi americani raggiungono spesso centinaia di migliaia di dollari.

La rete di Kok An: senatore, casinò e human trafficking

Parallelamente alle incriminazioni penali, l’OFAC (Office of Foreign Assets Control) ha designato il senatore cambogiano Kok An, assieme al suo impero di affari, 28 individui e entità correlate — tra cui casinò, società di facciata e una banca cambogiana. Le designazioni documentano il ruolo di Kok An nel fornire infrastrutture fisiche e finanziarie ai network di human trafficking e frode cyber-enabled in Cambogia e nella regione.

L’inclusione di un senatore in carica tra i soggetti sanzionati rappresenta una mossa diplomaticamente significativa, segnalando la disponibilità dell’amministrazione americana a colpire direttamente figure politiche regionali che proteggono o facilitano queste operazioni. Esperti del settore avvertono tuttavia che i compound criminali, già dimostratasi resiliente, probabilmente si rilocalizzeranno piuttosto che cessare le operazioni.

Infrastruttura digitale sequestrata

Sul fronte digitale, l’operazione ha portato a risultati tangibili: sequestro di 503 siti web di investimento fake in criptovalute, abbattimento di un canale Telegram con oltre 6.000 follower usato per reclutare lavoratori forzati in Cambogia, blocco di oltre 700 milioni di dollari in criptovalute legate al riciclaggio. Questi numeri evidenziano la scala industriale dell’operazione: non si tratta di piccoli gruppi criminali, ma di organizzazioni con infrastrutture tecnologiche, risorse umane forzate, e strutture finanziarie sofisticate.

Il contesto geopolitico: Asia sudorientale come hub del cybercrimine

I compound criminali di Myanmar, Cambogia, Laos e Filippine sono emersi negli ultimi anni come il principale hub globale delle truffe online. Secondo le stime delle Nazioni Unite, centinaia di migliaia di persone sono vittime di trafficking forzato in questi compound. La particolarità di questa criminalità organizzata è la sua doppia natura: è contemporaneamente una crisi di human trafficking e una minaccia di cybercrimine sofisticato, con vittime sia tra i lavoratori forzati che tra le persone truffate.

Le azioni dell’amministrazione americana vanno lette anche in chiave geopolitica: la presenza di criminali cinesi alla guida di operazioni in Myanmar, unita alla complicità di figure politiche cambogiane, configura una rete di illegalità che attraversa le sfere di influenza della regione. La risposta americana con sanzioni OFAC e incriminazioni penali tenta di esercitare pressione su attori che operano fuori dalla giurisdizione diretta degli Stati Uniti.

Implicazioni per i difensori e indicatori di allerta

Per i professionisti della sicurezza, l’operazione Level Up offre spunti operativi utili. Le piattaforme di investimento in criptovalute false utilizzate nei pig butchering scam mostrano pattern infrastrutturali ricorrenti: domini registrati di recente con nomi che imitano exchange legittimi, certificati TLS validi ma hosting su provider offshore, assenza di registrazioni presso autorità di regolamentazione finanziaria, e dashboard di investimento con rendimenti manipolati in tempo reale.

Pattern infrastrutturali dei siti fake sequestrati:
- Registrazione dominio: <90 giorni prima del sequestro
- Hosting: provider offshore (generalmente Asia/Est Europa)
- TLD comuni usati: .vip, .top, .xyz, .pro
- Pattern nome dominio: [exchange-legittimo]-[suffisso] (es. coinbase-pro-vip[.]com)
- Assenza di registrazione SEC/FCA/CONSOB

Indicatori di una truffa pig butchering:
- Contatto non sollecitato via app di dating o social
- Proposta di investimento in crypto dopo periodo di "amicizia"
- Piattaforma di trading non verificabile su registri ufficiali
- Richiesta di deposit in crypto (irreversibile)
- "Rendimenti" visibili ma impossibilità di prelevare fondi

Niri è un compositore Wayland progettato per offrire un sistema di gestione delle finestre basato sul tiling scrollabile, una modalità di organizzazione in cui ogni finestra occupa uno spazio preciso senza sovrapporsi alle altre. Il termine...

🔗 Leggi il post completo

Ogni settimana, il mondo del software libero e open source ci offre una moltitudine di aggiornamenti e nuove versioni di software. Anche se non tutti sono di grande rilevanza, molti di questi possono risultare...

🔗 Leggi il post completo

La corsa alle batterie giganti nel mondo Android si fa sempre più concreta. Secondo le ultime indiscrezioni, Redmi starebbe testando ben tre modelli dotati di batterie da circa 10.000 mAh, quasi il doppio rispetto ai 5.000-6.000 mAh che rappresentano oggi lo standard di mercato.

Tre modelli in fase di sviluppo

Le informazioni arrivano da un leaker di fiducia, secondo cui Redmi — brand del gruppo Xiaomi — avrebbe in sviluppo almeno tre dispositivi con batterie nell’ordine dei 10.000 mAh. Uno di questi potrebbe appartenere alla serie Redmi Note 17, con il modello Pro Max indicato come candidato principale per ospitare questa configurazione da record.

Non si tratta di un territorio del tutto inesplorato: Honor Power 2 e Realme P4 Power hanno già portato capacità simili sul mercato, ma Redmi — con i suoi enormi volumi di vendita — potrebbe renderla davvero una categoria mainstream.

Scheda tecnica ricca: 200MP, 100W e display 1.5K

Le specifiche trapelate per il modello di punta della serie sono tutt’altro che banali. Si parla di un sensore principale da 200 megapixel (Samsung HP5), fotocamera ultra-wide OmniVision da 8MP e selfie camera da 32MP. La ricarica rapida a 100W dovrebbe permettere di ricaricare questa enorme batteria in tempi ragionevoli.

Completano il quadro un display 1.5K ad alto refresh rate, lettore di impronte digitali sotto lo schermo e scocca in metallo. Un profilo tecnico da fascia media superiore abbinato a un’autonomia potenzialmente record.

In Europa batteria ridotta a 9.210 mAh

Chi si trovasse in Europa dovrà probabilmente accontentarsi di una versione leggermente ridimensionata: per rispettare le normative di sicurezza europee, la batteria del modello globale potrebbe fermarsi a 9.210 mAh. Una cifra comunque straordinaria, quasi il doppio rispetto alla media attuale del mercato.

Questa tendenza non riguarda solo Redmi: anche Vivo e iQOO sembrano muoversi nella stessa direzione. L’era degli smartphone con autonomia multi-giorno senza compromessi sembra sempre più vicina.

Samsung starebbe lavorando a una variante inedita del suo foldable di punta: il Galaxy Z Fold 8 Wide, un dispositivo pieghevole più largo del solito, con un display interno dalle proporzioni tipiche dei tablet. I dati fisici del dispositivo sono stati anticipati da un leaker affidabile del settore.

Tre foldable in arrivo da Samsung

Secondo le indiscrezioni, Samsung starebbe preparando simultaneamente tre nuovi pieghevoli: il Galaxy Z Fold 8 classico, il Galaxy Z Flip 8 e questa nuova variante “Wide”. Quest’ultima si differenzia radicalmente dai Fold precedenti per il form factor, orientato verso un utilizzo più simile a quello di un piccolo tablet.

Le dimensioni nel dettaglio

Le misure trapelate per il Galaxy Z Fold 8 Wide sono le seguenti: larghezza aperta di 161,4 mm, larghezza chiusa di 82,2 mm, altezza di 123,9 mm, spessore di 4,3 mm da aperto e 9,8 mm da chiuso. A colpire soprattutto è il rapporto altezza/larghezza: il display esterno avrebbe proporzioni 4,7:3, mentre quello interno raggiungerebbe il classico rapporto 4:3 tipico dei tablet.

Un’esperienza d’uso più simile a un tablet che a un telefono

Il passaggio a un display 4:3 non è un semplice dettaglio estetico: significa ridisegnare completamente il modo in cui si usa il dispositivo. Navigazione web, video, multitasking e produttività guadagnano spazio orizzontale, avvicinando l’esperienza a quella di un iPad mini più che a quella di uno smartphone tradizionale.

Samsung sembra voler puntare esplicitamente su un utente che considera questo dispositivo un sostituto del tablet piuttosto che del telefono. Una scommessa ambiziosa che potrebbe ritagliarsi una nicchia molto interessante nel mercato dei dispositivi pieghevoli Android premium.

Sony Xperia 1 VIII si mostra per la prima volta in dettaglio grazie a render CAD basati su dati di fabbrica reali. Le immagini, attribuite al leaker OnLeaks — noto per l’affidabilità delle sue fonti nella filiera produttiva — rivelano dimensioni precise e un restyling significativo del comparto fotografico posteriore.

Dimensioni confermate: compatto ma completo

Dalle specifiche fisiche emerge un dispositivo con altezza di circa 161,9 mm, larghezza di 74,4 mm, spessore di 8,58 mm (escluso il bump della fotocamera) e un display flat da circa 6,5 pollici. I numeri sono molto simili al predecessore Xperia 1 VII, segno che Sony non intende stravolgere il fattore di forma che ha già fidelizzato la sua base di utenti.

La fotocamera cambia volto

Il cambiamento più evidente rispetto alla generazione precedente riguarda il sistema fotocamere sul retro. I render mostrano una configurazione ridisegnata, con un modulo che si discosta dal layout tradizionale della serie Xperia 1. I dettagli sulle specifiche ottiche non sono ancora stati confermati, ma il cambiamento estetico è netto e fa presagire un aggiornamento sostanziale anche dell’hardware fotografico.

Render “quasi ufficiali”: perché ci possiamo fidare

La particolarità di queste immagini è la loro origine: non si tratta di bozzetti speculativi o ricostruzioni basate su voci, ma di elaborazioni a partire da dati CAD reali utilizzati dai fornitori di Sony nella catena produttiva. Questo le rende una fonte estremamente affidabile per capire come sarà effettivamente il dispositivo fisico.

L’Xperia 1 VIII si conferma dunque come un aggiornamento misurato nelle dimensioni ma potenzialmente significativo sotto il cofano. Sony non ha ancora comunicato date ufficiali per il lancio, ma la presenza di questo materiale tecnico dettagliato lascia intuire che l’annuncio non sia lontano.

Brutte notizie per i possessori di Google Pixel 8 e Pixel 9: dopo gli aggiornamenti software di marzo e aprile, numerosi utenti segnalano un peggioramento significativo delle prestazioni. L’avvio delle app, la navigazione tra le schermate e le operazioni quotidiane risultano visibilmente più lente rispetto a prima.

Lag e rallentamenti dopo l’aggiornamento

I Pixel sono sempre stati apprezzati per la fluidità d’uso piuttosto che per la potenza bruta, ma qualcosa sembra essere andato storto con gli ultimi aggiornamenti mensili. Le segnalazioni riguardano soprattutto Pixel 8 e Pixel 9, i modelli più recenti della famiglia Google, paradossalmente quelli su cui gli utenti si aspetterebbero le migliori prestazioni.

Non tutti gli utenti sono colpiti nello stesso modo: alcuni riferiscono rallentamenti lievi, altri parlano di un’esperienza d’uso decisamente compromessa, con lag evidenti anche nelle operazioni più semplici come aprire un’app o scorrere la schermata home.

Una serie di problemi che si accumula

Il rallentamento non è un caso isolato. Nei mesi scorsi si sono verificati altri problemi significativi sui Pixel: l’aggiornamento di aprile ha portato con sé un consumo anomalo della batteria, mentre quello di marzo ha causato in alcuni casi il temuto bootloop, ovvero l’impossibilità di avviare correttamente il dispositivo.

Questa serie di inconvenienti sta mettendo a dura prova la fiducia degli utenti, soprattutto considerando che Google ha promesso ben 7 anni di aggiornamenti per i Pixel 8 e successivi. Un impegno a lungo termine che perde di valore se gli aggiornamenti stessi diventano fonte di problemi.

Google ancora in silenzio

Al momento Google non ha rilasciato alcuna dichiarazione ufficiale riguardo ai problemi segnalati, né sono stati annunciati aggiornamenti correttivi. Gli utenti colpiti si trovano in una situazione di attesa senza una tempistica precisa per una possibile soluzione.

Nel frattempo, chi possiede un Pixel 8 o Pixel 9 e non ha ancora installato gli ultimi aggiornamenti potrebbe valutare di rimandare, almeno fino a quando Google non fornirà chiarimenti ufficiali sulla questione.

La divisione mobile di Samsung potrebbe registrare per la prima volta nella sua storia una perdita su base annuale. Il principale imputato è l’impennata dei prezzi della memoria DRAM e NAND, che sta pesantemente erodendo i margini di profitto. Una notizia che stona con i dati di vendita positivi della gamma Galaxy S26.

Il caro-memoria mette in crisi i conti

Secondo la società di ricerca Counterpoint, nei flagship oltre gli 800 dollari il costo dei componenti è aumentato tra i 100 e i 150 dollari rispetto al passato. La memoria è la voce che pesa di più: la RAM rappresenta circa il 23% del costo totale dei componenti, mentre lo storage arriva al 18%. Un incremento che, moltiplicato per milioni di unità vendute, si traduce in perdite consistenti per il produttore.

L’allarme interno di TM Roh

TM Roh, a capo delle divisioni DX e MX di Samsung, avrebbe già messo in guardia il management sulla possibilità concreta che il comparto mobile chiuda l’anno in perdita. Un segnale d’allarme che sottolinea quanto la situazione sia seria, nonostante in superficie le cose sembrino andare bene.

Il Galaxy S26 Ultra è il modello più richiesto, mentre l’intera serie S26 ha stabilito record di preordini in Corea del Sud, con una crescita del 25% negli USA e del 20% in Europa rispetto alla generazione precedente. Le vendite non sono il problema.

Un paradosso tra vendite e redditività

Il paradosso è evidente: Samsung vende più smartphone che mai, eppure la divisione mobile rischia di andare in rosso. I costi di produzione crescono più velocemente dei ricavi e Samsung non può semplicemente scaricare tutto l’aumento sul prezzo finale senza perdere competitività sul mercato globale.

La situazione contrasta nettamente con l’andamento del settore semiconduttori dello stesso gruppo, che si avvia verso un primo trimestre record. La pressione sui prezzi della memoria è destinata a influenzare l’intero mercato degli smartphone Android nei prossimi mesi.

Il Motorola Moto G87 si avvicina al debutto: nonostante non ci sia ancora un annuncio ufficiale, le sue schede tecniche e il design sono già visibili sul sito di supporto Motorola, e un rivenditore italiano ha già listato il prodotto con prezzi e configurazioni dettagliate.

Il design confermato dai disegni tecnici

Le immagini pubblicate sul portale di supporto ufficiale mostrano chiaramente le linee del Moto G87. Il design segue il DNA consolidato della serie Moto G: forme pulite, approccio pratico e senza fronzoli. Nessuna rivoluzione estetica, ma una continuità stilistica apprezzata da chi cerca affidabilità e semplicità a un prezzo accessibile.

Specifiche tecniche e prezzo in Italia

Grazie alle informazioni pubblicate da un rivenditore italiano, sappiamo già che il Moto G87 sarà disponibile in due varianti, entrambe con 8GB di RAM e 256GB di storage interno. Il prezzo indicato è di circa 406,89 euro, posizionando il dispositivo nella fascia medio-alta del segmento Moto G.

Sul fronte della memoria espandibile, il telefono supporta uno slot ibrido per SIM e microSD, con espansione fino a 2TB. Un vantaggio non trascurabile per chi lavora con molti file multimediali.

Colori e varianti previste

Le colorazioni confermate al momento sono due: Pantone Overture Gray e Pantone Blue Atoll. Dai file firmware emergono però ulteriori opzioni cromatiche, tra cui Arctic Seal, Black Olive, Nile e Shaded Spruce, che suggeriscono una gamma più ampia almeno in alcuni mercati.

Con il materiale già caricato sui canali ufficiali e la quotazione attiva in Italia, il lancio del Moto G87 sembra davvero imminente. Motorola non ha ancora fissato una data, ma tutti i segnali puntano a un annuncio a breve termine.

Nothing ha annunciato Essential Voice, una nuova funzione di inserimento vocale che va ben oltre la semplice trascrizione. Grazie all’intelligenza artificiale, i testi dettati vengono automaticamente ripuliti da esitazioni, ripetizioni e parole inutili, restituendo un risultato più naturale e pronto all’uso.

Come funziona Essential Voice

Le normali funzioni di dettatura trascrivono il parlato parola per parola, compresi i classici “ehm”, “cioè” e i ripensamenti. Essential Voice analizza invece il flusso del discorso e genera automaticamente una versione corretta e coerente. Si parla normalmente, e il sistema produce un testo già leggibile senza bisogno di editing manuale.

Cento lingue supportate, traduzione in tempo reale

La funzione supporta oltre 100 lingue con riconoscimento automatico della lingua parlata. Non manca la traduzione in tempo reale e la trascrizione simultanea, oltre a scorciatoie di testo personalizzabili: si può, ad esempio, digitare un’abbreviazione per far comparire automaticamente il proprio indirizzo completo o altri dati ricorrenti.

Accessibile dal tastierino e dall’Essential Key

Essential Voice si attiva dalla tastiera di sistema o dal tasto dedicato Essential Key presente sui Nothing Phone. Il design punta alla semplicità d’uso: un tocco e si inizia a dettare, senza configurazioni complesse.

Privacy al centro del progetto

La funzione si attiva solo su richiesta esplicita dell’utente: nessuna registrazione passiva in background. L’audio viene trasmesso cifrato ai server di Nothing per l’elaborazione, mentre il testo generato non viene conservato sul server. Una scelta progettuale orientata alla tutela dei dati personali.

Disponibilità

Essential Voice è già disponibile sul Nothing Phone 3. Il rilascio per Phone 4a Pro è previsto entro aprile, mentre il Phone 4a riceverà la funzione a partire dai primi di maggio. Nelle versioni future è prevista anche una modalità context-aware, che ottimizzerà lo stile del testo in base al contesto d’uso (messaggi, email, ricerche).

Il OnePlus 16 si preannuncia come uno dei flagship Android più ambiziosi del prossimo anno. Le ultime indiscrezioni dipingono un dispositivo con specifiche al limite del possibile: display a 240Hz, batteria mostruosa e un nuovo SoC Qualcomm ancora inedito.

Display LTPO da 6,78″ con refresh rate a 240Hz

Secondo i leak, il OnePlus 16 monterà un pannello LTPO da 6,78 pollici con risoluzione 1.5K e frequenza di aggiornamento massima di 240Hz. Rispetto agli attuali 165Hz del OnePlus 15, si tratta di un salto considerevole. I giocatori mobili e gli amanti della fluidità visiva avranno pane per i loro denti. A completare il quadro, cornici ultrasottili da circa 1mm realizzate con un pannello BOE e tecnologie produttive innovative.

Snapdragon 8 Elite Gen 6 Pro a 2nm

Il processore indicato dai rumor è lo Snapdragon 8 Elite Gen 6 Pro, il prossimo top di gamma Qualcomm realizzato con processo produttivo a 2nm. Le promesse riguardano sia le prestazioni sia l’efficienza energetica, con guadagni sensibili rispetto all’attuale generazione.

Batteria da 9.000 mAh e fotocamera da 200MP

Sul fronte energetico, i rumor parlano di una batteria in silicio-carbonio da 9.000 mAh, un salto enorme rispetto ai 7.300 mAh del predecessore. Le nuove chimiche delle celle permettono di raggiungere capacità maggiori senza aumentare troppo lo spessore del dispositivo. Per il comparto fotografico, si vocifera di un sensore principale rinnovato e un teleobiettivo periscopico da 200 megapixel.

Atteso per fine 2026, distribuzione globale incerta

Il lancio è previsto verso ottobre 2026, in linea con la cadenza dei modelli precedenti. Resta invece un’incognita la disponibilità nei mercati europei: negli ultimi anni OnePlus ha progressivamente ridotto la propria presenza in Europa e negli USA, e non è chiaro se il 16 arriverà anche da noi. Se le specifiche saranno confermate, sarà comunque un dispositivo molto atteso.

Google Drive si trasforma con l’arrivo di due nuove funzionalità basate su Gemini: AI Overviews e Ask Gemini. Non si tratta di aggiornamenti superficiali, ma di un cambio di paradigma che avvicina Drive a un vero assistente intelligente per la gestione dei documenti.

AI Overviews: i tuoi file riassunti in un colpo d’occhio

Con AI Overviews, la barra di ricerca di Drive diventa molto più potente. Quando si digita una query, l’IA analizza i file presenti nel cloud e restituisce un riepilogo automatico con i punti chiave, estrapolati da tutti i documenti pertinenti. Non serve più aprire cinque file diversi per trovare la data di una fattura o il riassunto di una riunione: Drive lo fa al posto tuo.

Ask Gemini: conversazione intelligente con i tuoi documenti

Ask Gemini è la componente conversazionale: permette di interagire in modo dialogico con i propri file, fare domande complesse e ottenere risposte che attraversano più documenti. Le conversazioni vengono salvate per poterle riprendere in un secondo momento. È possibile creare anche dei Drive Project, cartelle “intelligenti” che raggruppano file ed email correlati, permettendo a Gemini di rispondere tenendo conto di tutto il contesto del progetto.

Chi può usarle e quando

Le nuove funzioni sono disponibili per gli abbonati ai piani Google Workspace Business, Education e ad alcuni piani AI di Google. Il rollout in inglese è già iniziato; il supporto per le altre lingue, tra cui l’italiano, è atteso a partire da maggio 2026, con una copertura finale prevista per 29 lingue. Per chi gestisce documenti di lavoro all’interno dell’ecosistema Google, si tratta di un aggiornamento da non perdere.

Un nuovo leak svela i dettagli di One UI 8.5, il prossimo grande aggiornamento software per i Galaxy S25. Tra le novità più attese c’è una funzione di condivisione simile ad AirDrop e un significativo potenziamento delle funzioni Galaxy AI.

Interfaccia rinnovata con effetti blur e floating

One UI 8.5 porterà un restyling visivo dell’interfaccia, con effetti di trasparenza, sfocature (blur) e elementi grafici “galleggianti” che conferiscono un aspetto più moderno e arioso. Questo stile era già stato introdotto sui Galaxy S26, e ora viene esteso alla serie S25 attraverso un aggiornamento software.

Galaxy AI: call screening, generazione immagini e Now Brief

Le funzioni di intelligenza artificiale integrata ricevono un aggiornamento sostanziale. Tra le novità:

• Call Screening: possibilità di pre-ascoltare le telefonate in arrivo prima di rispondere
• Generazione e modifica di immagini via testo: espansione delle capacità fotografiche basate su IA
• Now Brief potenziato: il pannello di riepilogo intelligente diventa più completo e contestuale

Quick Share con condivisione cross-platform alla AirDrop

La novità più interessante per molti utenti riguarda il Quick Share, la funzione di condivisione rapida di Samsung. Con One UI 8.5 dovrebbe arrivare la possibilità di condividere file tra Galaxy e iPhone in modo fluido e intuitivo, similmente a quanto fa AirDrop nell’ecosistema Apple. Questa funzione era già disponibile sui Galaxy S26 con ottima accoglienza e ora arriva anche sulla serie S25.

Quando arriva?

Il build trapelato (S931BXXU9CZDN) suggerisce che lo sviluppo sia nelle fasi finali. Dopo diversi cicli beta, la versione stabile di One UI 8.5 per Galaxy S25 potrebbe essere imminente. La distribuzione globale è attesa nelle prossime settimane, anche se Samsung non ha ancora fissato una data ufficiale.

I problemi di Wi-Fi e Bluetooth sui Pixel 8 sono noti da tempo, ma finora non era chiaro se la colpa fosse del software o dell’hardware. Un caso documentato da un centro di riparazione canadese offre ora una prospettiva nuova: la causa potrebbe essere fisica, legata al degrado delle saldature interne.

Un Pixel 8 riparato con la rilavorazione delle saldature

Secondo quanto riportato da Android Authority, un’officina di riparazione di Vancouver (Canada) ha analizzato un Pixel 8 con connettività non funzionante. Dopo aver smontato il dispositivo, i tecnici hanno rimosso il modulo di comunicazione wireless, pulito i contatti e proceduto con una nuova saldatura. Il risultato: Wi-Fi e Bluetooth hanno ripreso a funzionare correttamente.

Il calore degli aggiornamenti sotto accusa

Uno degli scenari ipotizzati è che il calore generato durante l’installazione degli aggiornamenti di sistema possa stressare le saldature nel tempo. I Pixel 8 tendono a scaldarsi durante le operazioni di sistema intensive, e questo stress termico ripetuto potrebbe degradare i giunti di saldatura del modulo Wi-Fi/BT, portando a problemi di contatto. Si tratta di un fenomeno noto nell’industria elettronica, anche se non è ancora confermato come causa principale nei Pixel 8.

Google non ha ancora riconosciuto il problema

Al momento Google non ha classificato questo come un difetto hardware ufficiale per i Pixel 8, né ha attivato un programma di garanzia estesa simile a quello per il problema delle linee sul display. Chi si trova in questa situazione può contattare l’assistenza Google per valutare le opzioni disponibili, oppure rivolgersi a un centro di riparazione specializzato. L’episodio suggerisce comunque che non tutte le anomalie di connettività su Pixel 8 abbiano un’origine software.

Ubuntu 26.04 LTS, nome in codice Resolute Raccoon, è disponibile e porta con sé una delle novità più attese per gli sviluppatori .NET su Linux: .NET 10 è il runtime ufficiale incluso nel repository standard. In questo articolo esploriamo come installare .NET 10, come aggiornare le immagini container esistenti e come sfruttare Native AOT per ottenere binari ultra-compatti con avvio in pochi millisecondi.

Perché .NET e Ubuntu insieme

La collaborazione tra Microsoft e Canonical non è nuova: ogni nuovo Ubuntu LTS porta con sé l’ultimo .NET LTS come toolchain ufficialmente supportata. Ubuntu 26.04 non fa eccezione: .NET 10 è direttamente installabile via APT senza configurare PPA aggiuntive. Per chi lavora in ambienti enterprise o vuole un’infrastruttura stabile e aggiornabile tramite il gestore pacchetti di sistema, questo è un vantaggio non trascurabile.

È comunque possibile installare anche .NET 8 e .NET 9 tramite PPA dedicata, per chi ha applicazioni su versioni precedenti.

Installazione rapida

L’installazione di .NET 10 su Ubuntu 26.04 è immediata:

sudo apt update
sudo apt install dotnet-sdk-10.0

dotnet --version
# 10.0.105

Eseguire C# direttamente da stdin

Una delle funzionalità meno note ma molto utile per script e automazione è la possibilità di passare codice C# direttamente a dotnet run via stdin, usando i file-based apps:

dotnet run - << 'EOF'
using System.Runtime.InteropServices;
Console.WriteLine($"Hello {RuntimeInformation.OSDescription} from .NET {RuntimeInformation.FrameworkDescription}");
EOF
# Hello Ubuntu Resolute Raccoon from .NET .NET 10.0.5

Novità rilevanti di Ubuntu 26.04 per .NET

Ubuntu 26.04 introduce tre cambiamenti che impattano direttamente gli stack .NET in produzione:

• Linux 7.0: il team .NET avvierà test su questo kernel non appena disponibili VM nel laboratorio. Le prime build sono già in CI.
• Post-Quantum Cryptography: Ubuntu 26.04 spinge su questo fronte e .NET 10 include già il supporto agli algoritmi post-quantum, quindi la compatibilità è garantita.
• Rimozione di cgroup v1: nessun problema per .NET, che supporta cgroup v2 da diversi anni. Tuttavia, chi usa container con immagini molto datate o configurazioni cgroup v1 dovrà verificare la compatibilità.

Container: aggiornare da noble a resolute

Le immagini ufficiali per .NET 10 sono già disponibili con il tag resolute. Aggiornare un Dockerfile esistente è questione di un semplice sed:

sed -i "s/noble/resolute/g" Dockerfile.chiseled

docker build --pull -t aspnetapp -f Dockerfile.chiseled .
docker run --rm -it -p 8000:8080 -m 50mb --cpus .5 aspnetapp

Nota importante: i container ereditano il kernel dell’host. Un container resolute su un host Ubuntu 24.04 userà il kernel 6.x dell’host, non Linux 7.0. Tenere presente questa distinzione in fase di planning.

Native AOT: binari compatti e avvio in 3ms

Native AOT (NAOT) è una delle funzionalità più potenti di .NET 10 per scenari server e CLI. Su Ubuntu 26.04, il pacchetto dedicato è dotnet-sdk-aot-10.0:

apt install -y dotnet-sdk-aot-10.0 clang

dotnet publish app.cs
du -h artifacts/app/*
# 1.4M  artifacts/app/app
# 3.0M  artifacts/app/app.dbg

time ./artifacts/app/app
# real 0m0.003s

Per applicazioni web, lo stesso approccio funziona con <PublishAot>true</PublishAot> nel .csproj:

dotnet publish
# Produce: releasesapi (13MB) + releasesapi.dbg (32MB)

Considerazioni pratiche per il team di sviluppo

Per chi gestisce pipeline CI/CD con Ubuntu, questo rilascio semplifica notevolmente la gestione delle dipendenze: non è più necessario configurare feed Microsoft o repository aggiuntivi per .NET 10. L’intero stack è aggiornabile tramite apt upgrade come qualsiasi altro pacchetto di sistema.

Per i team che usano container come base di sviluppo standardizzata, aggiornare il tag da -noble a -resolute nei Dockerfile è sufficiente per passare alla nuova LTS. È comunque raccomandato verificare la compatibilità con la propria configurazione cgroup se si usano orchestratori come Kubernetes con configurazioni custom.

Conclusione

Ubuntu 26.04 LTS consolida ulteriormente la posizione di Linux come piattaforma di prima classe per .NET. L’integrazione diretta nel repository APT, il supporto alle immagini Chiseled, la compatibilità post-quantum e le performance eccezionali di Native AOT fanno di questo rilascio un upgrade significativo per chiunque sviluppi o distribuisca applicazioni .NET su Linux.

Fonte: What’s new for .NET in Ubuntu 26.04 – Richard Lander, Microsoft .NET Blog

Dodici estensioni browser, distribuite su Chrome e Microsoft Edge, si sono rivelate un’infrastruttura di spionaggio sofisticata che ha silenziosamente compromesso oltre 130.000 utenti. La campagna, denominata StealTok dai ricercatori di LayerX Security, ha sfruttato la popolarità dei downloader di video TikTok per introdurre spyware in grado di raccogliere dati ad alta entropia dai dispositivi delle vittime.

Una campagna costruita sulla fiducia

Il meccanismo più insidioso di StealTok non risiede nelle sue capacità tecniche, ma nella sua strategia di infiltrazione. Le estensioni malevole si comportavano esattamente come promesso per i primi 6-12 mesi dalla pubblicazione sugli store ufficiali: scaricavano video TikTok senza watermark in modo impeccabile, alcune guadagnando persino il badge “Featured” nei marketplace di Chrome e Edge. Solo dopo aver accumulato una base utenti significativa e instaurato un rapporto di fiducia, le estensioni attivavano il payload malevolo.

Questa tattica di “dormienza prolungata” rappresenta un’evoluzione significativa rispetto alle tradizionali estensioni malware che manifestano comportamenti sospetti fin dall’installazione. Il periodo di latenza ha permesso agli operatori di StealTok di eludere i controlli automatizzati dei marketplace e le revisioni manuali, che generalmente si concentrano sul comportamento immediatamente successivo all’installazione.

Meccanismo di attivazione e infrastruttura C2

Una volta superato il periodo di dormienza, le estensioni stabiliscono connessioni con server di comando e controllo (C2) per scaricare configurazioni dinamiche remote. Questo approccio consente agli attori malevoli di modificare il comportamento delle estensioni in tempo reale, aggiornare le istruzioni di raccolta dati senza richiedere aggiornamenti dello store, e rendere l’analisi forense più complessa poiché il codice malevolo non risiede staticamente nell’estensione stessa.

L’infrastruttura di supporto mostrava segnali chiari di operazione organizzata: molti domini presentavano pattern di typosquatting, come “trafficreqort” invece di “trafficreport” o “tiktak” al posto di “tiktok”, indicando una pianificazione deliberata per evitare blacklist automatiche basate su reputazione del dominio.

Raccolta dati e device fingerprinting

Una volta attivato il modulo spyware, le estensioni avviavano una raccolta sistematica di telemetria del dispositivo. Il profilo costruito su ogni vittima includeva: pattern di navigazione web e contenuti scaricati, impostazioni di sistema come timezone e lingua del browser, dati del dispositivo come lo stato della batteria, informazioni sull’ambiente di esecuzione per rilevare sandbox o ambienti di analisi.

L’utilizzo di dati ad alta entropia — come la combinazione di timezone, lingua, risoluzione dello schermo e stato della batteria — è una tecnica di fingerprinting avanzata in grado di identificare univocamente un dispositivo anche in assenza di cookie o identificatori espliciti. Questa tecnica è tipicamente associata a operatori sofisticati interessati a costruire profili duraturi degli utenti piuttosto che a semplici furti di credenziali.

Le estensioni compromesse

LayerX Security ha identificato almeno 12 estensioni coinvolte nella campagna, con circa 12.500 installazioni ancora attive al momento della scoperta. Le più diffuse erano le seguenti:

• TikTok Video Keeper — ~60.000 installazioni (Chrome)
• Mass TikTok Video Downloader — ~30.000 installazioni
• Video Downloader for TikTok — ~20.000 installazioni
• TikTok Downloader – Save Videos, No Watermark — ~10.000 installazioni

Google ha rimosso le estensioni identificate dal Chrome Web Store. Microsoft Edge Add-ons ha adottato misure analoghe. Tuttavia, gli operatori della campagna hanno dimostrato resilienza, ricreando estensioni con nomi e aspetti leggermente modificati riutilizzando lo stesso codebase condiviso — una tattica che suggerisce un’operazione ben strutturata con capacità di recupero rapido.

Contesto e attribuzioni

La campagna StealTok si inserisce in un trend preoccupante di abuso degli store di estensioni browser come vettore di attacco. A differenza degli attacchi tradizionali che richiedono l’exploit di vulnerabilità, le estensioni malware sfruttano i permessi esplicitamente concessi dall’utente. Un’estensione browser, per sua natura, ha accesso privilegiato al traffico web, ai contenuti delle pagine, e potenzialmente alle credenziali inserite nei form.

La tecnica della dormienza prolungata era già stata osservata in operazioni precedenti legate a broker di dati e reti pubblicitarie opache, ma raramente applicata con questa scala e questa sistematicità. Il fatto che le estensioni abbiano ottenuto badge “Featured” ufficiali evidenzia le limitazioni dei processi di review degli store, che dipendono in parte da segnali comportamentali nel breve periodo.

Indicatori di compromissione (IoC)

Domini C2 identificati (typosquatting pattern):
- trafficreqort[.]com
- tiktak-download[.]com
- tiktok-vid-dl[.]com

Estensioni Chrome rimosse (ID parziali noti):
- TikTok Video Keeper
- Mass TikTok Video Downloader  
- Video Downloader for TikTok
- TikTok Downloader – Save Videos, No Watermark

Comportamenti sospetti da monitorare:
- Connessioni HTTP/HTTPS verso domini non correlati all'uso dichiarato
- Richieste fetch() verso endpoint di configurazione dinamica post-installazione
- Accesso a navigator.getBattery() e navigator.language in estensioni di download video

Consigli per i difensori

Per le organizzazioni, è consigliabile implementare policy di gestione delle estensioni browser tramite soluzioni MDM/EDR che blocchino l’installazione di estensioni non approvate dall’IT, monitorare il traffico di rete generato dai browser verso domini non categorizzati, e adottare strumenti di browser security come quelli offerti da vendor specializzati (LayerX, Island, Talon) in grado di analizzare il comportamento runtime delle estensioni. Per gli utenti individuali, la regola fondamentale rimane quella di limitare al minimo il numero di estensioni installate, privilegiare solo quelle di vendor riconoscibili con track record verificabile, e rivedere periodicamente i permessi concessi.

Chi gestisce ambienti Windows aziendali potrebbe aver notato, nelle ultime settimane, che i propri utenti si trovano davanti a finestre di avviso insolite quando aprono i file .rdp. Non si tratta di un malfunzionamento: è una modifica intenzionale introdotta da Microsoft con le patch cumulative di aprile 2026, in risposta a una vulnerabilità di sicurezza sfruttata attivamente.

In questo articolo analizziamo cosa è cambiato, perché è cambiato e soprattutto come adeguare i propri ambienti per continuare a usare i file RDP in modo fluido e sicuro.

La vulnerabilità alla base del cambiamento: CVE-2026-26151

Le patch cumulative KB5083769 (Windows 11) e KB5082200 (Windows 10) introducono nuove protezioni per i file di connessione Remote Desktop (.rdp). La motivazione è la CVE-2026-26151, una vulnerabilità di spoofing RDP sfruttata attivamente in ambienti reali.

Il gruppo russo APT29 (noto anche come Cozy Bear), legato all’SVR (servizio di intelligence estero russo), ha distribuito file .rdp malevoli tramite campagne di phishing mirate. Questi file, apparentemente innocui, erano in grado di:

• Redirigere unità locali e periferiche verso sistemi remoti controllati dagli attaccanti
• Modificare silenziosamente le impostazioni di connessione
• Ingannare gli utenti inducendoli a connettersi a sistemi non previsti
• Esfiltrare credenziali e dati locali

I file RDP sono da sempre un vettore di attacco sottovalutato: non sono eseguibili nel senso tradizionale del termine, quindi gli utenti tendono a fidarsi di essi, ma possono comunque influenzare in modo significativo il comportamento di una sessione remota.

Cosa cambia concretamente

Con le nuove patch, Windows tratta i file .rdp non firmati digitalmente come non attendibili per impostazione predefinita. Le conseguenze pratiche sono:

• La prima volta che si apre un file .rdp dopo l’aggiornamento, compare un “educational dialog” che spiega i rischi dei file RDP e del phishing
• Aprendo un file non firmato, appare un avviso con banner “Caution: Unknown remote connection” e il campo Publisher impostato a “Unknown publisher”
• Alcune funzionalità (come la redirezione degli appunti o delle unità locali) possono essere bloccate o richiedono conferma esplicita ad ogni uso

Nota importante: queste restrizioni si applicano solo ai file .rdp. Chi si connette digitando manualmente l’hostname nel client mstsc.exe o tramite riga di comando con mstsc /v:hostname non vedrà alcun avviso aggiuntivo.

Come risolvere: la firma digitale dei file RDP

La soluzione raccomandata da Microsoft è firmare digitalmente i file .rdp con un certificato di code signing attendibile. Una volta firmato, Windows può verificare l’autenticità e l’integrità del file, eliminando gli avvisi e ripristinando le funzionalità complete.

Lo strumento nativo per la firma è rdpsign.exe, incluso in Windows. Il comando base è:

rdpsign.exe /sha256 <thumbprint_certificato> <percorso_file.rdp>

rdpsign.exe /sha256 A1B2C3D4E5F6... "C:\RDP\ServerAziendale.rdp"

Quale certificato usare?

Esistono tre opzioni principali, ciascuna adatta a scenari diversi:

• Certificato self-signed: gratuito, utile per ambienti di test o reti interne piccole. Deve essere distribuito manualmente su ogni macchina client come certificato attendibile.
• Certificato da Enterprise CA (Active Directory): la scelta ideale per ambienti di dominio. I certificati emessi dalla CA aziendale sono automaticamente attendibili su tutte le macchine domain-joined. Nessun costo aggiuntivo se si dispone già di una PKI interna.
• Certificato commerciale (DigiCert, ecc.): la scelta per ambienti con utenti esterni o macchine non domain-joined. Attendibile di default su tutti i sistemi Windows, ma comporta un costo annuale.

In alternativa, Microsoft Azure offre il servizio Trusted Signing, integrato con Entra ID e RBAC, come soluzione economica e moderna rispetto ai certificati commerciali tradizionali.

Automatizzare la firma con PowerShell: RDPFileSigner.ps1

Michael Morten Sonne ha rilasciato uno script PowerShell open-source chiamato RDPFileSigner.ps1 che automatizza l’intero flusso, dalla creazione del certificato alla firma, verifica e integrazione con Windows Explorer. Lo script è disponibile su GitHub.

Le principali modalità operative:

# Setup iniziale: crea/riusa il certificato, lo installa nei trust store
# e registra il menu contestuale per i file .rdp
.\RDPFileSigner.ps1

# Firmare un singolo file
.\RDPFileSigner.ps1 -Sign -RdpFile "C:\RDP\Server.rdp"

# Firmare tutti i file .rdp in una cartella (incluse sottocartelle)
.\RDPFileSigner.ps1 -Sign -RdpFolder "C:\RDP" -Recurse

# Usare un certificato Enterprise CA
.\RDPFileSigner.ps1 -Setup -CertTemplate "CodeSigning"

# Importare un certificato commerciale da .pfx
.\RDPFileSigner.ps1 -Setup -ImportPfxPath "C:\Certs\commercial.pfx"

# Verificare la firma su tutti i file in una cartella con report CSV
.\RDPFileSigner.ps1 -Verify -RdpFolder "C:\RDP" -ExportCsvPath "C:\Report\rdp-status.csv"


.\RDPFileSigner.ps1 -TaskRegister -WatchFolder "C:\RDP" -CertThumbprint "A1B2C3..."


Disabilitare temporaneamente le protezioni (sconsigliato)

Microsoft ha documentato un workaround tramite registro di sistema per disabilitare temporaneamente le nuove protezioni, ma lo sconsiglia esplicitamente e potrebbe rimuovere questo supporto in aggiornamenti futuri:

HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
Nome: RedirectionWarningDialogVersion
Tipo: REG_DWORD
Valore: 1


Raccomandazioni operative

Al di là della firma digitale, è buona pratica cogliere l’occasione per rivedere più in generale la gestione dei file RDP nell’organizzazione:

• Evitare la distribuzione via email: preferire portali interni attendibili o soluzioni di Remote Desktop Gateway
• Ridurre le redirections al minimo necessario: ogni redirezione abilitata è una potenziale superficie di attacco
• Formare gli utenti: spiegare il significato degli avvisi e quando è sicuro procedere evita la “warning fatigue”
• Automatizzare il rinnovo dei certificati: integrare la firma nel processo di generazione dei file RDP per non dover intervenire manualmente a ogni scadenza

Conclusioni

La modifica introdotta con le patch di aprile 2026 non è un bug né una scelta arbitraria: è la risposta di Microsoft a una vulnerabilità concretamente sfruttata da attori di threat intelligence statali. Per i team IT, il percorso più corretto è implementare la firma digitale dei file RDP, scegliendo il tipo di certificato più adatto al proprio ambiente.

Chi gestisce ambienti di dominio troverà probabilmente nella Enterprise CA la soluzione più rapida e senza costi aggiuntivi. Chi ha utenti esterni o macchine non domain-joined dovrebbe valutare Azure Trusted Signing come alternativa economica ai certificati commerciali tradizionali.

Fonte: Your RDP files are now untrusted after the April 2026 Windows Patch – Sign them with PowerShell (Sonne’s Cloud Blog)

L’OPPO Find X9 Ultra è uno dei flagship Android più interessanti del momento, e ora sappiamo anche cosa c’è dentro. WekiHome ha pubblicato un video di teardown che mostra la struttura interna del dispositivo, rivelando una progettazione hardware di altissimo livello.

Quattro fotocamere e un modulo enorme

Aprendo il Find X9 Ultra si nota immediatamente il sistema fotografico: quattro moduli fotocamera più un sensore spettrale per il colore. Le dimensioni di ciascun modulo sono considerevoli — il bump posteriore ora ha molto più senso. La back cover è incollata con forza, ma una volta rimossa appare il sistema di ricarica wireless da 50W, con la sua grande bobina che occupa una porzione significativa dello spazio interno.

Snapdragon 8 Elite Gen 5, RAM LPDDR5X e storage UFS 4.1

Il cuore pulsante è il Snapdragon 8 Elite Gen 5, il SoC di punta di Qualcomm. Ad affiancarlo ci sono memoria RAM di tipo LPDDR5X e storage UFS 4.1, per prestazioni al massimo delle possibilità attuali. La scheda madre è progettata con un’altissima densità di componenti, come ci si aspetta da un top di gamma.

Batteria da 7.050 mAh e display LTPO AMOLED a 144Hz

L’autonomia è garantita da una batteria da 7.050 mAh con supporto alla ricarica cablata a 100W e wireless a 50W. Il display è un pannello LTPO AMOLED a 144Hz, per una qualità visiva di primissimo livello. Il Find X9 Ultra è anche il primo modello Ultra di OPPO a ricevere una distribuzione globale, aprendo i mercati internazionali a quello che finora era stato un prodotto prevalentemente cinese.

Un flagship costruito per durare

Il teardown conferma ciò che i numeri già lasciavano intuire: il Find X9 Ultra non è un dispositivo che nasce per fare numeri sulla scheda tecnica, ma una macchina progettata con cura nei minimi dettagli. La densità costruttiva e la qualità dei componenti posizionano questo smartphone tra i migliori disponibili sul mercato Android nel 2026.