Azure Resource Manager: il piano di controllo di Azure

Azure Resource Manager (ARM) è il piano di controllo dell’intera piattaforma Azure. Ogni operazione che crea, aggiorna o elimina risorse Azure passa attraverso ARM, indipendentemente da dove provenga: portale Azure, CLI, PowerShell, REST API o SDK. È l’unico punto di ingresso autorevole per gestire l’infrastruttura cloud Microsoft.

Con l’esplosione degli agenti AI, si pone una domanda concreta: come possono questi agenti interagire con ARM in modo strutturato, sicuro e coerente? Microsoft ha risposto con l’Azure Resource Manager MCP Server, ora in anteprima pubblica: un server MCP remoto che fornisce agli agenti AI un accesso di prima classe alle operazioni di infrastruttura Azure attraverso il Model Context Protocol.

Cos’è l’Azure Resource Manager MCP Server

Il server MCP per ARM è progettato per essere il layer di accesso degli agenti AI all’infrastruttura Azure, esattamente come lo è per qualsiasi altro client ARM. Nella versione attuale espone due macro-funzionalità principali:

• Azure Resource Graph (ARG) query: generazione, validazione ed esecuzione di query ARG in linguaggio naturale contro tutti i tipi di risorse Azure
• ARM Template Deployment: avvio, monitoraggio e cancellazione di deployment ARM su scope di resource group esistenti

In pratica, l’agente AI non esegue direttamente SQL o chiamate REST: descrive ciò che vuole sapere o fare, e il server MCP traduce quella richiesta in operazioni ARM concrete e sicure.

I tool disponibili

Il server espone sei tool principali, ciascuno con un ruolo preciso:

• generate_query: genera una query ARG a partire da un prompt in linguaggio naturale. Esempio: “Mostrami tutte le VM in esecuzione nel subscription X” → query KQL valida
• validate_query: verifica che una query ARG sia corretta sintatticamente e sicura prima di eseguirla
• execute_query: esegue la query ARG contro l’ambiente Azure dell’utente e restituisce i risultati
• create_template_deployment: avvia il deployment di un ARM template verso un resource group target
• get_arm_template_deployment_status: monitora lo stato di avanzamento di un deployment ARM
• cancel_arm_template_deployment: annulla un deployment in corso (utile dopo fallimenti di validazione o policy)

Caso d’uso pratico: interrogare l’infrastruttura in linguaggio naturale

Immagina di voler sapere quante storage account nel tuo tenant non hanno il tag “owner” assegnato. Tradizionalmente dovresti conoscere il linguaggio KQL di Azure Resource Graph e costruire manualmente la query:

Resources
| where type == "microsoft.storage/storageaccounts"
| where isnull(tags["owner"]) or tags["owner"] == ""
| summarize count() by subscriptionId

“Conta tutte le storage account senza il tag ‘owner’, raggruppate per subscription”

Il server generate_query crea la query KQL, validate_query la verifica, e execute_query la esegue restituendo i risultati all’agente che li presenta in formato leggibile.

Caso d’uso: deployment di infrastruttura guidato dall’AI

Il secondo use case riguarda il deployment di ARM template. Un agente può ricevere istruzioni come:

“Deploy un’app service con piano B1 nel resource group ‘prod-rg’ in West Europe, usa il template standard dalla nostra libreria”

Il tool create_template_deployment avvia il deployment specificando subscription ID, resource group, nome del deployment e la definizione del template ARM. Il tool get_arm_template_deployment_status permette all’agente di monitorarne l’avanzamento. Se qualcosa va storto, cancel_arm_template_deployment lo interrompe immediatamente.

Governance e sicurezza

Un aspetto critico: il server ARM MCP opera nel contesto dell’utente autenticato in VS Code. Tutte le chiamate vengono eseguite per conto di quell’utente e sono soggette agli stessi permessi e controlli di accesso definiti in Azure. Non ci sono privilegi elevati o bypass del modello di sicurezza Azure: se l’utente non ha i diritti per deployare in un certo resource group, l’agente non li avrà neanche.

Per organizzazioni che vogliono impedire completamente i deployment tramite ARM MCP Server, è possibile applicare una Azure Policy che blocchi esplicitamente le richieste al tool create_template_deployment identificando l’AppID del server MCP (22bfbae3-f4e7-485f-be43-8cee15065084) nel scope desiderato. Un template di policy di esempio è disponibile nel repository GitHub ufficiale.

Installazione e configurazione

Durante questa preview pubblica, il server ARM MCP è supportato su:

• GitHub Copilot Chat in VS Code
• GitHub Copilot CLI

Per installarlo:

1. Apri aka.ms/JoinARMMCP — VS Code si avvierà automaticamente
2. Quando richiesto in VS Code, clicca su Install sotto “Azure Resource Manager MCP server”
3. Effettua il login con le credenziali Azure
4. In VS Code, apri View > Chat e clicca sull’icona Configure Tools
5. Assicurati che “Azure Resource Manager MCP server” sia spuntato

I prerequisiti sono VS Code installato, un account Azure valido e un account GitHub Copilot.

Considerazioni per gli amministratori Azure

L’ARM MCP Server apre nuovi scenari per i team DevOps e gli amministratori Azure. Alcuni esempi concreti:

• Compliance automatizzata: agenti che controllano periodicamente le risorse e verificano l’applicazione di policy di tagging, naming convention o configurazioni di sicurezza
• Troubleshooting accelerato: interrogare in linguaggio naturale lo stato dell’infrastruttura durante un incident, senza dover ricordare sintassi KQL
• Infrastructure as Code assistita: generare e deployare ARM template partendo da descrizioni in linguaggio naturale, con validazione integrata prima dell’esecuzione

Il limite attuale — solo VS Code e GitHub Copilot CLI come client supportati — sarà probabilmente espanso nelle prossime versioni in base al feedback degli utenti. Microsoft ha aperto un canale dedicato su GitHub per raccogliere segnalazioni e richieste di funzionalità.

Conclusione

L’Azure Resource Manager MCP Server rappresenta un passo significativo nell’integrazione tra agenti AI e infrastruttura cloud. Non si tratta di uno strumento che bypassa la governance Azure, bensì di un layer che la rende accessibile agli agenti rispettandola appieno. Per team che già usano Azure e GitHub Copilot, il valore pratico è immediato: meno sintassi KQL da memorizzare, deployment più veloci da validare, e la possibilità di costruire agenti personalizzati per automazioni di compliance che oggi richiedono script dedicati.

Il server è ora in anteprima pubblica e può essere installato seguendo le istruzioni ufficiali su aka.ms/JoinARMMCP.

Fonti:
Introducing the Azure Resource Manager MCP Server! — Microsoft Tech Community (Steven Bucher, 8 maggio 2026)
Azure/Azure-Resource-Manager-MCP — GitHub

Samsung ha dato il via alla distribuzione ufficiale di One UI 8.5 per la serie Galaxy S24, portando su questi dispositivi uno dei più significativi aggiornamenti software degli ultimi anni. Il rollout è partito dalla Corea del Sud, ma presto raggiungerà anche l’Europa e il resto del mondo.

Dopo un mese e mezzo di beta, arriva la versione stabile

Samsung aveva avviato il programma beta di One UI 8.5 per Galaxy S24, S24+ e S24 Ultra a marzo 2026. Dopo diverse settimane di test e affinamenti basati sui feedback degli utenti, l’azienda ha dichiarato concluso il periodo beta e ha avviato il rilascio della versione stabile. Il firmware è identificato dal numero “S92xNKSU5DZOP”. Chi aggiorna dalla versione stabile precedente dovrà scaricare circa 4 GB, mentre per i beta tester il pacchetto è più leggero, attorno ai 371 MB.

Le principali novità di One UI 8.5

One UI 8.5 è basato su Android 16 QPR2 e introduce cambiamenti su più fronti:

• Nuovo design dell’interfaccia: Samsung ha ridisegnato vari elementi dell’UI, con animazioni più fluide e un look generale rinnovato.
• Galaxy AI potenziata: le funzioni di intelligenza artificiale integrate, come la trascrizione delle chiamate, la generazione di testi e le funzioni fotografiche AI, ricevono aggiornamenti e nuove capacità.
• Miglioramenti alla privacy e alla sicurezza: nuovi controlli per la gestione dei permessi e delle notifiche.
• Ottimizzazioni delle prestazioni: il sistema risulta più reattivo, con una migliore gestione della batteria in scenari di utilizzo intenso.

Quando arriverà in Italia

Il rilascio globale, Italia inclusa, dovrebbe seguire a breve distanza dal lancio coreano. Solitamente Samsung impiega da pochi giorni a un paio di settimane per estendere gli aggiornamenti a tutti i mercati. Chi possiede un Galaxy S24 può controllare periodicamente la disponibilità tramite Impostazioni > Aggiornamento software > Scarica e installa.

Una delle tecnologie più apprezzate dai gamer PC approda su Android. Il Lossless Scaling Frame Generation (LSFG), strumento popolare su Steam per rendere i giochi più fluidi grazie all’interpolazione AI dei fotogrammi, è stato portato su Android da uno sviluppatore indipendente ed è già integrato in una prima applicazione.

Cos’è il Lossless Scaling Frame Generation

LSFG è una tecnologia che genera fotogrammi aggiuntivi tra quelli originali di un gioco, usando algoritmi AI per “inventare” i frame mancanti in modo convincente. Il risultato è una fluidità visiva superiore anche se il gioco non raggiunge nativamente i frame al secondo target. Sul PC, questa tecnica è già utilizzata da milioni di gamer per migliorare l’esperienza su hardware meno potente o per spingere frame rate elevatissimi su monitor ad alta frequenza di aggiornamento.

Come funziona su Android

Lo sviluppatore FrankBaretta ha portato LSFG su Android sfruttando le API Vulkan, presenti sulla maggior parte degli smartphone moderni. La tecnologia è stata integrata nell’app GameNative (versione 0.9.1), che permette di eseguire giochi PC su Android. Gli utenti possono attivare la generazione di frame direttamente dal menu rapido dell’applicazione.

I test iniziali mostrano risultati promettenti, anche se le prestazioni variano in base al SoC del dispositivo e al titolo in esecuzione. La tecnologia Vulkan non è universalmente supportata allo stesso modo da tutti i chipset Android, quindi l’esperienza potrebbe differire tra diversi smartphone.

Prospettive future per il gaming mobile

L’arrivo di LSFG su Android apre scenari interessanti non solo per l’emulazione e il gaming via cloud, ma anche per i giochi nativi Android. Se la tecnologia venisse integrata a livello di sistema operativo o adottata dai principali sviluppatori di giochi mobile, potrebbe migliorare sensibilmente l’esperienza su una gamma molto più ampia di dispositivi, anche quelli di fascia media. Un passo in avanti significativo per chi considera Android una piattaforma gaming seria.

OPPO continua a muoversi in anticipo nell’ecosistema Android: il Find X9 Pro ha ricevuto la terza beta di Android 17, l’ultimo aggiornamento del programma di test avviato a marzo. Il rilascio porta nuove funzionalità, miglioramenti della stabilità e supporto all’ultimo pacchetto Google GMS.

Beta 3: cosa cambia rispetto alle versioni precedenti

Android 17 Beta 3 per OPPO Find X9 Pro è costruita sul più recente pacchetto Google GMS (Google Mobile Services), garantendo compatibilità con le ultime API di sistema. Rispetto alle beta precedenti, questa versione introduce correzioni di bug e ottimizzazioni di sistema, pur mantenendo la natura sperimentale del software.

OPPO precisa che questa è una versione destinata a sviluppatori e utenti esperti, e non è adatta all’uso quotidiano. Chi vuole uno smartphone affidabile per la vita di tutti i giorni è invitato ad attendere la versione stabile.

I problemi ancora presenti nella Beta 3

Come prevedibile per una versione in sviluppo, la Beta 3 presenta ancora alcune problematiche note:

• Malfunzionamenti del Bluetooth (parzialmente risolvibili eliminando i dati dell’app)
• Problemi con la funzione Device Connect
• Alcune schermate mostrano errori di visualizzazione

OPPO tra i primi con Android 17

La partecipazione attiva di OPPO al programma beta di Android 17 conferma la volontà del produttore cinese di offrire aggiornamenti tempestivi ai propri utenti, almeno sui modelli top di gamma. Il Find X9 Pro si posiziona così tra i pochi dispositivi non Pixel a ricevere le ultime versioni di Android così precocemente. Quando Android 17 arriverà alla versione stabile, OPPO punta ad essere tra i primissimi ad offrirla al grande pubblico.

.NET Aspire 13.3 è disponibile, e nonostante siano passate soltanto cinque settimane dalla versione 13.2, questa release porta con sé novità di rilievo: un nuovo skill per l’onboarding assistito da agente, risultati strutturati dai comandi delle risorse, log del browser direttamente nell’orchestratore, e — finalmente — supporto di prima classe a Kubernetes e AKS tramite Helm.

In questo articolo analizziamo le funzionalità più importanti di Aspire 13.3, con esempi pratici per i team che già usano Aspire in produzione o che vogliono iniziare.

Aspireify: onboarding assistito da agente

Una delle novità più interessanti di Aspire 13.3 è il nuovo skill Aspireify, pensato per semplificare l’integrazione di applicazioni esistenti in Aspire. Chi ha già seguito le sessioni AspiriFridays sa bene quanto possa essere laborioso il processo di “aspirificazione”: capire quali servizi sono presenti, quali porte usano, quali variabili d’ambiente sono dipendenze reali e come mappare i servizi Docker Compose verso le integrazioni Aspire native.

Il nuovo skill risolve esattamente questo problema. Quando aspire init crea lo scheletro dell’AppHost in un’applicazione esistente, Aspireify guida l’agente di coding attraverso un workflow strutturato per completare il lavoro:

• Ispeziona il repository e comprende come l’applicazione è già strutturata
• Mappa le configurazioni esistenti (es. DATABASE_URL) usando WithEnvironment() invece di riscrivere la configurazione
• Preserva le porte hardcoded quando necessario, chiedendo all’utente nei casi ambigui
• Se esiste già un Docker Compose, lo analizza prima di aggiungere nuove risorse

Il principio guida è chiaro: minimizzare le modifiche al codice esistente. L’agente si adatta all’applicazione, non viceversa.

Risultati strutturati dai comandi delle risorse

In Aspire 13.3, i comandi delle risorse possono restituire risultati strutturati al chiamante. Testo e JSON ora fluiscono attraverso il modello, gRPC, backchannel, UI del dashboard, CLI e strumenti MCP.

Questo significa che i comandi possono restituire risposte in markdown formattato — non solo “sì, è andato a buon fine”. Il dashboard integra tutto questo con un nuovo notification center nell’header, dove i risultati dell’esecuzione appaiono come notifiche con timestamp, rendering markdown e un’azione “View response” per l’output completo.

Tra le novità specifiche:

• I comandi HTTP possono restituire il corpo della risposta, esposto via CLI, dashboard e SDK poliglotti generati
• Il comando di rebuild delle risorse restituisce l’output del build come dati di testo strutturati, leggibili da strumenti e agenti senza dover fare scraping dei log
• Le integrazioni di terze parti possono aggiungere comandi che restituiscono risultati significativi invece di cambiare solo stato in background

Browser logs: Aspire vede anche il frontend

La nuova API WithBrowserLogs() collega una risorsa browser tracciata a qualsiasi risorsa con un endpoint. Aspire avvia Chromium usando una pipe CDP privata (invece di un endpoint TCP debug esposto), poi trasmette log della console, richieste di rete ed errori nel log stream della risorsa:

// C# AppHost
var frontend = builder.AddViteApp("frontend", "../frontend")
    .WithHttpEndpoint(port: 3000)
    .WithBrowserLogs();

// TypeScript AppHost
const frontend = await builder.addViteApp("frontend", "../frontend")
    .withHttpEndpoint({ port: 3000 })
    .withBrowserLogs();

Dal punto di vista degli agent workflow, questo è particolarmente potente: l’agente può eseguire l’app, ispezionare i log del browser, catturare cosa è cambiato, correggere il codice, riavviare la risorsa e continuare — senza che lo sviluppatore debba incollare screenshot nella chat.

TypeScript, Python e Java AppHost verso la GA

Aspire 13.2 aveva introdotto l’authoring TypeScript AppHost. In 13.3, il lavoro continua su tutte e tre le piattaforme:

• TypeScript, Python e Java AppHost espongono ora il set completo di extension method di Aspire.Hosting
• Le API sono state rese più idiomatiche per ogni linguaggio: metodi come addProject, withEnvironment e withReference sono consolidati per leggere naturalmente
• Python si aggiunge come nuovo generatore di codice AppHost
• Java AppHost ora supporta union, optional/nullability, callback e un nuovo template “Empty (Java AppHost)”
• Il nuovo diagnostico ASPIREEXPORT013 individua ID di capability duplicati a compile time

Kubernetes e AKS: finalmente supporto di prima classe

La novità più attesa della release è senza dubbio il supporto Kubernetes come deployment target di prima classe. Aspire aveva già un’ottima storia per Azure Container Apps e Docker Compose; ora Kubernetes entra nel club.

Il nuovo pacchetto Aspire.Hosting.Azure.Kubernetes aggiunge AddAzureKubernetesEnvironment(), con cui è possibile definire cluster AKS, node pool, tier SKU, cluster privati e Azure Container Insights direttamente dall’AppHost:

// C# AppHost
var aks = builder.AddAzureKubernetesEnvironment("prod-aks")
    .WithHelm();

builder.AddCSharpApp("api", "../api")
    .PublishTo(aks);

// TypeScript AppHost
const aks = await builder.addAzureKubernetesEnvironment("prod-aks")
    .withHelm();

await builder.addCsharpApp("api", "../api")
    .publishTo(aks);

Altre novità rilevanti

Aspire 13.3 include molte altre migliorie degne di nota:

• EF Core migration management: sei comandi (Update Database, Drop Database, Reset Database, Add Migration, Remove Migration, Get Database Status) accessibili da dashboard e CLI, con esecuzione automatica all’avvio dell’AppHost in sviluppo locale
• Azure networking: Azure Front Door, Network Security Perimeters, endpoint privati per Azure OpenAI e Foundry, ACR privato, e upgrade HTTPS automatici per App Service
• JavaScript publishing: tre nuovi modelli di pubblicazione — PublishAsStaticWebsite(), PublishAsNodeServer() e PublishAsNpmScript() — con integrazione dedicata AddNextJsApp()
• CLI: rilevamento automatico di Bun, Yarn e pnpm da lockfile; aspire dashboard standalone senza AppHost; aspire docs api per sfogliare la reference API dal terminale
• Estensione VS Code: CodeLens e gutter icon nei file AppHost, Simple Browser integrato per il dashboard, workspace auto-restore
• Docker Compose: supporto Podman tramite rilevamento automatico del runtime

Breaking changes da conoscere prima dell’aggiornamento

Prima di aggiornare, è importante verificare la sezione dei breaking changes ufficiale se si usano:

• Startup hook Kubernetes/Docker Compose/AKS
• Endpoint di gestione degli emulator
• Il server MCP del dashboard
• Il template starter Python
• Output name di Azure network

Come aggiornare

Se si usa già Aspire, l’aggiornamento è semplice:

aspire update --self

aspire init

Conclusione

Aspire 13.3 consolida la piattaforma su tutti i fronti: l’onboarding diventa più semplice grazie ad Aspireify, l’osservabilità raggiunge il browser con WithBrowserLogs(), il supporto multi-linguaggio avanza verso la GA, e Kubernetes entra ufficialmente come target di deployment. Per i team .NET che operano su Kubernetes o AKS, questa è probabilmente la release più attesa degli ultimi mesi.

Fonte: What’s New in Aspire 13.3 — Maddy Montaquila, Microsoft Aspire Blog (7 maggio 2026)

Cos’è il Model Context Protocol e perché interessa ai developer Node.js

I modelli di linguaggio sono bravi a ragionare e conversare, ma da soli non possono eseguire operazioni reali sui tuoi sistemi. Possono suggerire query SQL o chiamate API, ma non possono farle girare concretamente. Il Model Context Protocol (MCP) risolve questo limite: fornisce ai modelli AI un modo strutturato per interagire con i tuoi strumenti, dai database ai file, fino alle API esterne. Invece di generare testo su ciò che dovrebbe accadere, il modello può invocare funzioni che lo fanno davvero accadere.

In pratica, questo apre la strada a strumenti come chatbot che creano e cercano voci nel database, assistenti AI che interrogano tool interni o attivano workflow, e agenti che leggono file, eseguono comandi e restituiscono risultati reali.

In questo tutorial imparerai a costruire il tuo primo MCP server da zero con Node.js e TypeScript: partiremo da un sistema di note basato su file per capire i concetti fondamentali, poi passeremo a un backend MySQL per mostrare come un LLM possa guidare operazioni deterministiche. Entro la fine avrai un server MCP funzionante pronto per essere collegato al client AI che preferisci.

Come funziona MCP

MCP segue un modello client-server: l’applicazione AI fa da client, il tuo codice gira come server. In una configurazione tipica, il client (Claude Desktop, Claude Code, Cursor, ecc.) si interpone tra l’utente e il tuo server, inoltrandogli le richieste e restituendogli i risultati. Il modello stesso non chiama mai direttamente il tuo server: quando l’utente manda un messaggio, il client condivide col modello la lista dei tool esposti dal tuo server. Il modello decide quale tool chiamare (e con quali argomenti), il client esegue la chiamata e rimanda il risultato al modello.

Utente → Client MCP → Modello AI → Tool selezionato → Server MCP → Risposta

Prerequisiti

Per seguire questo tutorial ti serviranno:

• Node.js 18+
• Familiarità di base con TypeScript
• Un client compatibile con MCP per il test (Claude Desktop, Claude Code, Cursor, ecc.)
• MySQL installato localmente (solo per la sezione avanzata con database)

Costruire il server MCP: sistema di note su file

Iniziamo creando un nuovo progetto Node.js. Questo sarà un sistema di note basato su file, utile per comprendere i concetti prima di introdurre un database.

mkdir mcp-notes && cd mcp-notes
npm init -y

npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node

{
  "type": "module",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

Scrivere il server

Crea il file src/index.ts con il codice base del server:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import fs from "fs/promises";
import path from "path";
import { z } from "zod";

const NOTES_DIR = path.join(process.cwd(), "notes");
await fs.mkdir(NOTES_DIR, { recursive: true });

const server = new McpServer({
  name: "mcp-notes",
  version: "1.0.0",
});

// I tool verranno aggiunti qui

const transport = new StdioServerTransport();
await server.connect(transport);

Aggiungere i tool

Ogni tool definisce una singola azione che il modello può compiere. Include nome, descrizione, schema di input e una funzione handler. Aggiungiamo i tre tool fondamentali: creazione, lettura e lista delle note.

server.tool(
  "create_note",
  "Create a new note with a given title and content",
  {
    title: z.string().min(1).describe("The note title"),
    content: z.string().min(1).describe("The body of the note"),
  },
  async ({ title, content }) => {
    const filename = `${title.replace(/[^a-z0-9_-]/gi, "_")}.txt`;
    const filepath = path.join(NOTES_DIR, filename);
    try {
      await fs.access(filepath);
      return {
        content: [{ type: "text", text: `Error: note "${title}" already exists.` }],
        isError: true,
      };
    } catch {}
    await fs.writeFile(filepath, content, "utf-8");
    return { content: [{ type: "text", text: `Note "${title}" created.` }] };
  }
);

server.tool(
  "read_note",
  "Read the content of a note by its title",
  { title: z.string().min(1).describe("The title of the note to read") },
  async ({ title }) => {
    const filename = `${title.replace(/[^a-z0-9_-]/gi, "_")}.txt`;
    try {
      const content = await fs.readFile(path.join(NOTES_DIR, filename), "utf-8");
      return { content: [{ type: "text", text: content }] };
    } catch {
      return {
        content: [{ type: "text", text: `Error: note "${title}" not found.` }],
        isError: true,
      };
    }
  }
);

server.tool(
  "list_notes",
  "List all available notes",
  {},
  async () => {
    const files = await fs.readdir(NOTES_DIR);
    const notes = files.filter(f => f.endsWith(".txt")).map(f => f.replace(".txt", ""));
    if (notes.length === 0) return { content: [{ type: "text", text: "No notes found." }] };
    return { content: [{ type: "text", text: notes.join("\n") }] };
  }
);

Testare il server con Claude Desktop

Compila il progetto con npm run build. Poi apri il file di configurazione di Claude Desktop:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Aggiungi il server sotto la chiave mcpServers:

{
  "mcpServers": {
    "mcp-notes": {
      "command": "node",
      "args": ["/percorso/del/progetto/mcp-notes/dist/index.js"],
      "cwd": "/percorso/del/progetto/mcp-notes"
    }
  }
}

Passare a MySQL: dati strutturati per uso reale

Il sistema basato su file funziona bene per comprendere i fondamentali, ma ha limiti evidenti. Passare a MySQL mette in luce un pattern importante nel design MCP: il modello decide quale azione intraprendere, ma il tuo codice rimane responsabile di come quella azione viene eseguita. Quando il modello chiama search_notes, non genera né esegue SQL da solo: il tuo handler gestisce l’operazione in modo controllato, con query parametrizzate.

Installa il driver MySQL:

npm install mysql2

CREATE DATABASE mcp_notes;
USE mcp_notes;
CREATE TABLE notes (
  id INT AUTO_INCREMENT PRIMARY KEY,
  title VARCHAR(255) UNIQUE NOT NULL,
  content TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

server.tool(
  "search_notes",
  "Search notes by keyword across titles and content",
  { query: z.string().min(1).describe("Keyword or phrase to search for") },
  async ({ query }) => {
    const like = `%${query}%`;
    const [rows] = await pool.execute<mysql.RowDataPacket[]>(
      "SELECT title, created_at FROM notes WHERE title LIKE ? OR content LIKE ? ORDER BY created_at DESC",
      [like, like]
    );
    if (rows.length === 0) {
      return { content: [{ type: "text", text: `No notes found matching "${query}".` }] };
    }
    return { content: [{ type: "text", text: rows.map(r => `- ${r.title} (${r.created_at})`).join("\n") }] };
  }
);

Principi per progettare buoni tool MCP

Un tool MCP che funziona in fase di test può fallire in produzione se il modello fraintende quando o come usarlo. Alcune regole pratiche:

• Descrizioni esplicite: frasi come “Gestisce le note” sono troppo vaghe. Usa descrizioni che spiegano chiaramente cosa fa il tool e quando va usato.
• Singola responsabilità: ogni tool deve fare una sola cosa. Strumenti troppo “jolly” costringono il modello a indovinare l’intento.
• Errori azionabili: usa isError: true con messaggi che guidano il modello su come riprovare: "Note non trovata. Usa list_notes per vedere quelle disponibili."
• Boundary sicuri: mai interpolazione diretta dell’input utente in SQL o comandi shell. Usa sempre query parametrizzate.

Conclusione

Costruire un MCP server con Node.js e TypeScript è sorprendentemente accessibile grazie all’SDK ufficiale. Il pattern che hai imparato in questo tutorial — definire tool con schema Zod, gestire gli errori con isError e connettere il server via stdio — si scala facilmente a scenari più complessi: integrazione di API REST, automazione di workflow, connessione di agenti AI a sistemi legacy.

Il codice completo del tutorial è disponibile su GitHub.

Fonte: How to build your first MCP server with Node.js — LogRocket Blog (Elijah Asaolu, 5 maggio 2026)

Si parla di:
Toggle

Per la prima volta nella storia documentata della cybersecurity, un gruppo criminale ha utilizzato un modello di intelligenza artificiale per identificare una vulnerabilità zero-day sconosciuta e trasformarla in un exploit funzionante, pianificando di impiegarla in un evento di compromissione di massa. Google Threat Intelligence Group (GTIG) ha svelato la scoperta l’11 maggio 2026, descrivendo quella che potrebbe essere un punto di svolta nell’evoluzione delle capacità offensive dei threat actor.

La scoperta: un exploit scritto da un LLM

Il team GTIG di Google ha identificato uno script Python contenente un exploit per una vulnerabilità zero-day in un popolare strumento open source di amministrazione web. La falla, un bypass dell’autenticazione a due fattori (2FA), permetteva a un attaccante in possesso di credenziali valide di aggirare completamente il secondo fattore di autenticazione, aprendo la strada a un accesso non autorizzato su larga scala.

Ciò che ha immediatamente attirato l’attenzione degli analisti non era tanto la vulnerabilità in sé, quanto le caratteristiche stilistiche e strutturali del codice che la implementava. Lo script presentava una serie di indizi inequivocabili della sua origine artificiale:

• Docstring educativi estremamente dettagliati: ogni funzione era accompagnata da commenti esplicativi esaustivi, in uno stile tipico degli output di Large Language Model addestrati su repository di codice open source e documentazione tecnica.
• Un punteggio CVSS “allucinato”: lo script includeva una valutazione CVSS autogenerata ma non corrispondente a nessuna voce esistente nel National Vulnerability Database — un errore tipico di un modello che genera informazioni plausibili ma non verificate.
• Formato Pythonic “da manuale”: la struttura pulita, la classe _C per i colori ANSI, i menu di aiuto dettagliati e la coerenza stilistica riflettono il pattern caratteristico degli output di modelli come GPT-4 o Gemini quando invitati a scrivere strumenti di sicurezza.

GTIG ha valutato con alta confidenza che un modello di AI sia stato utilizzato sia per scoprire la vulnerabilità che per costruire l’exploit, pur non avendo prove che il modello specifico impiegato fosse Gemini di Google.

La natura della vulnerabilità: logica semantica, non memoria

Uno degli aspetti più rilevanti della scoperta riguarda la tipologia della vulnerabilità stessa. Non si trattava di un classico bug di memory corruption (buffer overflow, use-after-free) né di un problema di input sanitization — le categorie che i fuzzer tradizionali e gli strumenti SAST (Static Application Security Testing) sono progettati per individuare.

La falla era invece un difetto logico semantico ad alto livello: un’assunzione di trust codificata nella logica di enforcement del 2FA, che permetteva a un flusso di autenticazione specifico di saltare la verifica del secondo fattore. Questo tipo di vulnerabilità richiede una comprensione profonda della logica applicativa e dei suoi presupposti impliciti — un dominio in cui i modelli di linguaggio di grandi dimensioni, addestrati su enormi corpus di codice e documentazione, mostrano capacità emergenti superiori agli strumenti di analisi statica convenzionali.

La scoperta conferma ciò che molti ricercatori ipotizzavano ma temevano di veder concretizzato: i modelli AI possono identificare classi di vulnerabilità che sfuggono sistematicamente agli strumenti automatizzati tradizionali.

L’evento pianificato: compromissione di massa sventata

Secondo GTIG, il threat actor aveva pianificato di utilizzare l’exploit in un mass exploitation event — un attacco opportunistico su larga scala verso tutti i sistemi vulnerabili esposti su internet. La proactive discovery da parte di Google ha permesso di interrompere la catena prima che l’exploit venisse utilizzato in produzione.

Google ha lavorato con il vendor del software colpito per la divulgazione responsabile della vulnerabilità e il rilascio di una patch correttiva, senza rivelare pubblicamente il nome dello strumento interessato per limitare il rischio di sfruttamento da parte di altri attori durante la finestra di patching.

Il quadro più ampio: AI e cybercrime state-sponsored

L’incidente non è isolato: il report GTIG del maggio 2026 documenta una tendenza sistematica all’adozione di strumenti AI da parte di gruppi APT nation-state. In particolare:

• Cina: operatori state-linked stanno sperimentando sistemi AI per la vulnerability hunting automatizzata e il probing di target — essenzialmente automatizzando il processo di ricognizione e identificazione delle superfici di attacco.
• Corea del Nord (APT45): il gruppo sta utilizzando AI per processare migliaia di exploit check in bulk e arricchire il proprio toolkit, accelerando significativamente i tempi di sviluppo di nuove capacità offensive.
• Gruppi criminali non-state: come dimostrato da questo episodio, anche attori privi di risorse statali hanno ormai accesso a capacità di sviluppo exploit AI-assisted tramite modelli commerciali o open source.

Il democratizzazione degli strumenti AI abbassa significativamente la barriera tecnica per lo sviluppo di exploit sofisticati, storicamente appannaggio di gruppi con risorse e competenze elevate.

Due righe per i difensori

Questa scoperta accelera un dibattito che era rimasto per lungo tempo teorico: se gli attaccanti usano AI per trovare vulnerabilità, i difensori devono adottare gli stessi strumenti con ancora maggiore urgenza. Alcune considerazioni pratiche:

• Rivedere i programmi di bug bounty per includere vulnerabilità logiche e di flusso che i tool tradizionali non rilevano, premiando i ricercatori umani e AI-assisted che identificano difetti semantici.
• Implementare AI-assisted code review nel ciclo di sviluppo, in particolare per la logica di autenticazione e autorizzazione — le aree dove i difetti semantici sono più probabili e più gravi.
• Monitorare i pattern di accesso MFA con particolare attenzione ai bypass del secondo fattore, anche in presenza di credenziali valide.
• Aggiornare tempestivamente tutti gli strumenti di amministrazione web esposti su internet, indipendentemente dalla loro percezione come “strumenti minori”.

Il primo zero-day AI-generated documentato in natura non segna la fine di un’era, ma l’inizio di una nuova fase nella corsa agli armamenti digitali. Le organizzazioni che non integreranno AI nei propri processi di difesa si troveranno strutturalmente svantaggiate rispetto a avversari che già la impiegano sistematicamente per attaccare.

OPPO potrebbe essere pronta ad alzare ulteriormente l’asticella nel segmento premium. Secondo il leaker Digital Chat Station, uno dei più affidabili nel panorama degli smartphone cinesi, l’azienda starebbe sviluppando un nuovo modello chiamato Find X10 Pro Max — una variante ancora più potente rispetto al Find X10 Pro e posizionata sotto il Find X10 Ultra.

Tre fotocamere da 200 megapixel: un sistema fotografico senza compromessi

La caratteristica più clamorosa del Find X10 Pro Max sarebbe il sistema fotografico: ben tre sensori da 200 megapixel. Se confermato, si tratterebbe di una configurazione senza precedenti nel settore, che spingerebbe al massimo le capacità di risoluzione in ogni condizione di scatto — grandangolo, standard e zoom. Una scelta che punta chiaramente ai fotografi mobile più esigenti.

Display e dimensioni: due opzioni sul tavolo

Secondo le indiscrezioni, OPPO starebbe testando due diverse configurazioni per il display: una variante più compatta e una versione large screen. La decisione finale dipenderà probabilmente dal feedback raccolto durante lo sviluppo e dalle preferenze del mercato target. Entrambe le opzioni punterebbero su pannelli OLED di alta gamma con frequenza di aggiornamento elevata.

Un flagship per il mercato globale

A differenza di alcuni modelli Ultra di OPPO rimasti confinati al mercato cinese, il Find X10 Pro Max punterebbe a un lancio globale. Questo renderebbe il dispositivo disponibile anche in Europa, dove OPPO ha consolidato una presenza significativa negli ultimi anni. Non ci sono ancora indicazioni sulla data di lancio, ma il dispositivo potrebbe arrivare entro la fine del 2026 o all’inizio del 2027.

Samsung non ha abbandonato il sogno del pieghevole a tre schermi. Nuove evidenze emerse da un brevetto recentemente pubblicato suggeriscono che il Galaxy Z TriFold 2 sia in sviluppo, con una modifica importante rispetto al predecessore: l’integrazione dell’S Pen nel corpo del dispositivo.

Il progetto TriFold sembrava morto, ma è tornato

Il primo Galaxy Z TriFold fu presentato a fine 2025 come una pietra miliare dell’innovazione Samsung, ma successivamente si diffusero voci di una cancellazione del progetto per la seconda generazione. Il brevetto appena emerso smentisce queste indiscrezioni: Samsung starebbe lavorando attivamente a un successore che mantiene il design a tre fold ma introduce significative migliorie.

L’S Pen alloggiato nell’cerniera: come funzionerebbe

La grande novità riguarda l’S Pen. Secondo le figure del brevetto, Samsung ha studiato un sistema per alloggiare il pennino all’interno del meccanismo a cerniera del dispositivo. Una soluzione ingegneristica complessa ma elegante, che risolverebbe la principale critica mossa al TriFold originale: la mancanza del supporto all’S Pen, elemento quasi imprescindibile per chi vuole usare produttivamente un grande schermo pieghevole.

Design invariato, funzionalità in crescita

Stando al brevetto, il form factor di base rimarrebbe fedele al TriFold originale: struttura a tre pieghe, grande display interno flessibile e schermo esterno di copertura. Le modifiche riguarderebbero principalmente le funzionalità, con l’S Pen in cima alla lista. Non ci sono ancora indicazioni sui tempi di lancio, ma il fatto che Samsung stia brevettando queste soluzioni lascia intendere che il Galaxy Z TriFold 2 sia più vicino di quanto si pensasse.

Samsung sta preparando una funzione molto attesa per i Galaxy: la possibilità di bloccare automaticamente le notifiche delle app che abusano della pubblicità. La novità è stata intercettata nell’ultima versione di Samsung Device Care e potrebbe debuttare ufficialmente con One UI 8.5.

Il problema delle notifiche pubblicitarie eccessive

Molte app Android, soprattutto quelle gratuite, inviano notifiche pubblicitarie con una frequenza spropositata, interrompendo continuamente l’esperienza utente. Fino ad oggi, l’unica soluzione era disattivare manualmente le notifiche per ciascuna app — un’operazione che non tutti gli utenti sanno effettuare e che comunque richiede tempo.

Samsung ha deciso di affrontare il problema in modo proattivo, affidando la gestione all’app di sistema Device Care, già nota per occuparsi di batteria, memoria e sicurezza del dispositivo.

Due modalità: Basic e Intelligent

La nuova funzione, denominata “Block apps with excessive ads”, si articola in due modalità operative:

• Modalità Basic: blocca le notifiche di tutte le app che superano una soglia predefinita di frequenza pubblicitaria.
• Modalità Intelligent: utilizza l’AI per analizzare il comportamento delle notifiche e decidere caso per caso quali bloccare, con un approccio più sfumato e personalizzato.

In entrambi i casi, l’app non viene disinstallata né bloccata nel suo funzionamento: viene limitata solo la sua capacità di inviare notifiche pubblicitarie.

Quando arriverà e su quali dispositivi

La funzione è stata individuata nella versione beta di Samsung Device Care ed è probabile che faccia parte del pacchetto One UI 8.5, di cui il Galaxy S24 ha già ricevuto la versione stabile in Corea del Sud. Non è ancora confermata una data precisa per il rilascio globale, ma l’arrivo di questa novità su tutti i Galaxy compatibili con One UI 8.5 sembra questione di settimane. Una piccola grande miglioria che promette di rendere l’esperienza quotidiana sui dispositivi Samsung molto più pulita e meno invasiva.

L’Xperia 1 VIII si preannuncia come un autentico salto generazionale sul fronte fotografico. Secondo le ultime indiscrezioni di un noto leaker della community Xperia, il sensore della fotocamera con zoom sarà enormemente più grande rispetto al modello precedente, con l’adozione della tecnologia Exmor-T — finora riservata ai sensori principali della serie.

Sensore zoom: da 1/3.5″ a una superficie quattro volte maggiore

L’Xperia 1 VII montava un sensore da 1/3.5 pollici per la fotocamera zoom. Stando alle informazioni trapelate, il nuovo modello avrà un sensore con una superficie quattro volte superiore. In termini di formato, questo significa passare a un sensore con diagonale doppia rispetto al predecessore — un cambiamento enorme che si traduce in capacità raccolta della luce nettamente superiore, meno rumore nelle foto scattate in condizioni di scarsa luminosità e una profondità di campo più gestibile anche con teleobiettivo.

Debutto dell’Exmor-T sulla fotocamera zoom

Un ulteriore salto di qualità arriva dall’adozione dell’Exmor-T, la tecnologia di sensore più avanzata di Sony. Fino ad ora, questo tipo di sensore era stato utilizzato esclusivamente per la fotocamera principale degli Xperia, mentre il modulo zoom era dotato di soluzioni meno performanti. Portare l’Exmor-T anche sullo zoom significa immagini più nitide, HDR migliorato e prestazioni video di livello superiore anche con la fotocamera tele.

Design rinnovato e annuncio il 13 maggio

Oltre al salto fotografico, l’Xperia 1 VIII porterà anche un restyling estetico: il modulo fotocamera passerà da una disposizione verticale a un layout quadrato, avvicinandosi al design adottato da altri produttori premium. Sony ha già confermato un evento ufficiale per il 13 maggio, dove tutti i dettagli saranno finalmente svelati. Considerati i progressi sul comparto fotografico, le aspettative sono molto alte.

L’app Pixel Screenshots, finora esclusiva degli smartphone Pixel, potrebbe presto espandersi ben oltre il mondo mobile. Nuovi riferimenti trovati nei file dell’applicazione suggeriscono che Google stia lavorando a una versione desktop, probabilmente legata al misterioso progetto Aluminium OS.

Cos’è Pixel Screenshots e perché è speciale

Lanciata insieme alla serie Pixel 9 nel 2024, Pixel Screenshots è un’app che usa l’intelligenza artificiale per analizzare e organizzare automaticamente tutti gli screenshot salvati sul dispositivo. Invece di avere una semplice cartella di immagini, l’AI “capisce” il contenuto di ogni screenshot — ricevute, articoli, conversazioni, prezzi — e permette di cercarli in linguaggio naturale. L’integrazione con NotebookLM ha reso l’app ancora più potente per la gestione delle informazioni personali.

Il collegamento con Aluminium OS

I ricercatori hanno individuato nei file dell’app riferimenti espliciti a una piattaforma desktop, con menzione di “Aluminium OS” — un nome che era già emerso in precedenti leak come possibile successore o evoluzione di ChromeOS. Se confermato, questo significherebbe che Google vuole costruire un ecosistema continuo tra smartphone Pixel e computer, dove gli screenshot e le informazioni personali sono accessibili e ricercabili ovunque.

La visione di Google: un’AI che attraversa i dispositivi

Questa mossa si inserisce nella più ampia strategia di Google di rendere Gemini e le sue capacità AI un filo conduttore tra tutti i propri dispositivi e servizi. Un utente Pixel potrebbe in futuro scattare uno screenshot sul telefono, cercarlo dal PC tramite Aluminium OS e ricevere risposte intelligenti sul contenuto — tutto senza dover trasferire manualmente i file. Siamo ancora in fase di sviluppo, ma le fondamenta di questo ecosistema sembrano essere già in costruzione.

I ricercatori di sicurezza di Google hanno confermato per la prima volta che un hacker ha utilizzato l’intelligenza artificiale per generare un attacco zero-day reale. Un evento che segna un punto di svolta nella storia della cybersecurity e che porta nel mondo concreto una minaccia fino ad ora teorica.

Cos’è successo: il primo attacco zero-day generato dall’AI

Il team di analisi delle minacce di Google, noto come GTIG (Google Threat Intelligence Group), ha analizzato uno script Python utilizzato in un attacco informatico contro un tool di amministrazione web. L’attacco sfruttava una vulnerabilità zero-day nel sistema di autenticazione a due fattori (2FA) — una falla cioè sconosciuta agli sviluppatori al momento dell’attacco.

Analizzando il codice, i ricercatori hanno identificato caratteristiche inequivocabili della generazione da parte di un modello linguistico di grandi dimensioni (LLM): struttura del codice eccessivamente ordinata, messaggi di help troppo dettagliati e persino alcune “allucinazioni” tipiche dei sistemi AI, ovvero contenuti inventati o errati inseriti come se fossero reali.

Perché questa scoperta è importante

Fino ad oggi, il timore che l’AI potesse essere sfruttata per automatizzare la ricerca di vulnerabilità e la generazione di codice malevolo era rimasto nel campo delle ipotesi. Questo caso dimostra invece che siamo già entrati nella fase operativa: attori malevoli stanno effettivamente usando strumenti AI per abbreviare i tempi di sviluppo degli attacchi e abbassare la barriera tecnica necessaria per colpire sistemi complessi.

Non significa che chiunque possa ora diventare un hacker esperto grazie a ChatGPT o sistemi simili, ma rappresenta un segnale d’allarme concreto: le difese tradizionali potrebbero non essere sufficienti contro avversari che sfruttano l’AI per innovare le proprie tecniche di attacco.

Cosa cambia per la sicurezza mobile e Android

L’ecosistema Android, con i suoi miliardi di dispositivi distribuiti globalmente, è un bersaglio privilegiato. Google lavora costantemente per patchare vulnerabilità tramite gli aggiornamenti di sicurezza mensili, ma la scoperta di attacchi zero-day generati dall’AI potrebbe rendere il ritmo degli aggiornamenti meno efficace se i criminali riescono a trovare e sfruttare falle più velocemente di quanto i team di sicurezza riescano a correggerle.

L’invito per gli utenti Android rimane quello di mantenere sempre aggiornati i propri dispositivi, evitare di installare app da fonti non verificate e prestare attenzione ai permessi richiesti dalle applicazioni.

Brutte notizie per chi attendeva il Redmi K100 Pro Max: secondo le ultime indiscrezioni provenienti dalla Cina, il modello sarebbe stato cancellato durante la fase di sviluppo. Al suo posto, Xiaomi starebbe preparando un dispositivo con un nome completamente diverso e forse con una posizione di mercato ridefinita.

Addio al codename Q11U, arriva il Q11X

Stando a quanto riportato da leaker cinesi, il dispositivo identificato internamente come “Q11U” — considerato finora il futuro Redmi K100 Pro Max — sarebbe stato abbandonato. Al suo posto è emerso un nuovo progetto con codename “Q11X”, la cui identità commerciale non è ancora definita. Alcune fonti ipotizzano una ridenominazione in Redmi K100 Ultra, mentre altri suggeriscono che Xiaomi potrebbe scegliere un nome completamente inedito per marcare la discontinuità.

Snapdragon 8 Elite Gen 6 e fotocamera avanzata

Nonostante l’incertezza sul naming, i rumor tecnici dipingono un dispositivo di alto livello. Il nuovo modello dovrebbe montare il processore Snapdragon 8 Elite Gen 6, chip di punta Qualcomm di prossima generazione, affiancato da un sistema fotografico di livello superiore rispetto al K100 Pro standard. La finestra di lancio prevista è entro la fine del 2026.

Una mossa strategica nel segmento premium

La decisione di cancellare un modello già avanzato nella fase di sviluppo suggerisce che Xiaomi stia rivedendo la propria strategia nel segmento high-end. Il brand Redmi punta tradizionalmente al rapporto qualità/prezzo, ma con i K series ha dimostrato ambizioni sempre più elevate. L’arrivo di un nuovo dispositivo con caratteristiche da vero flagship potrebbe posizionare Redmi in competizione diretta con i top di gamma di Samsung, OnePlus e persino Google Pixel.

Restiamo in attesa di ulteriori conferme ufficiali da parte di Xiaomi, che finora non ha commentato le voci di corridoio.

Photoflare è un’applicazione open source dedicata alla modifica delle immagini, progettata per offrire uno strumento semplice ma efficace per interventi fotografici rapidi, lavori grafici essenziali e regolazioni di base. Il progetto, sviluppato dalla comunità...

🔗 Leggi il post completo

A pochi giorni dall’annuncio ufficiale previsto per il 13 maggio, Sony continua ad alimentare la curiosità attorno al suo prossimo flagship Xperia 1 VIII. Le ultime indiscrezioni parlano di un “anello luminoso” attorno al modulo fotografico, un elemento che potrebbe nascondere una gradita sorpresa: il ritorno del LED di notifica.

Il teaser “full circle” e l’anello che brilla

Sony ha pubblicato un teaser ufficiale con la frase evocativa “full circle”, accompagnato da immagini in cui l’area attorno alla fotocamera appare illuminata da un anello di luce. Il dettaglio ha immediatamente acceso la fantasia degli appassionati, che hanno iniziato a chiedersi se questo elemento decorativo nasconda una funzione pratica o sia semplicemente un espediente creativo per il video promozionale.

Tre ipotesi sul tavolo

I media specializzati hanno identificato tre possibili interpretazioni dell’anello luminoso:

• LED di notifica evoluto: l’anello potrebbe fungere da nuovo sistema di notifica luminosa, una feature abbandonata da quasi tutti i produttori negli ultimi anni. Sony potrebbe rilanciarla in forma moderna e più visibile.
• Indicatore luminoso per la fotocamera: l’anello potrebbe segnalare quando la fotocamera è attiva, un dettaglio utile per la privacy o per le riprese video professionali.
• Pura estetica promozionale: non è escluso che l’effetto luminoso esista solo nei video di marketing e non nell’hardware reale. Le immagini di rendering diffuse finora non mostrano strutture LED evidenti attorno alla fotocamera.

Cosa sappiamo per certo sull’Xperia 1 VIII

Al di là del mistero dell’anello, alcune caratteristiche dell’Xperia 1 VIII sembrano confermate: il modulo fotografico passerà a un design quadrato, il sensore della fotocamera con zoom avrà un’area quattro volte superiore rispetto al predecessore e sarà adottata la tecnologia Exmor-T per la prima volta nella serie zoom. L’annuncio ufficiale è atteso per il 13 maggio: non manca molto per scoprire la verità.

Una nuova campagna di frode è stata scoperta sul Google Play Store: 28 applicazioni Android, scaricate complessivamente oltre 7,3 milioni di volte, promettevano agli utenti di poter visualizzare la cronologia delle chiamate e dei messaggi di qualsiasi numero di telefono. In realtà non funzionavano affatto, e servivano solo a sottrarre denaro agli ignari acquirenti.

L’operazione “CallPhantom”: come funzionava la truffa

I ricercatori della società di sicurezza ESET hanno battezzato questa campagna “CallPhantom”. Le app coinvolte si presentavano come strumenti in grado di accedere alla cronologia delle chiamate e agli SMS di qualsiasi numero telefonico inserito dall’utente. Un’offerta pensata per chi volesse spiare un partner, un ex o comunque controllare le comunicazioni di altre persone.

Per accedere ai presunti dati, le app richiedevano un pagamento. Una volta effettuato, però, mostravano esclusivamente numeri di telefono generati casualmente e nomi di fantasia — dati completamente inventati, senza alcuna connessione con la realtà.

Perché queste app erano così pericolose

Oltre alla perdita economica diretta, queste applicazioni presentano un problema etico e legale importante: incoraggiavano comportamenti di sorveglianza non autorizzata. Anche se tecnicamente non funzionavano, il loro stesso scopo dichiarato — spiare le comunicazioni altrui — è illegale nella maggior parte dei Paesi europei, Italia compresa.

Il fatto che siano riuscite a superare i controlli del Google Play Store e ad accumulare milioni di download evidenzia ancora una volta i limiti del sistema di moderazione del marketplace. Google ha successivamente rimosso le app segnalate, ma l’episodio solleva interrogativi sulla velocità e l’efficacia dei controlli preventivi.

Come proteggersi dalle app truffaldine

Per difendersi da questo tipo di minacce è consigliabile leggere sempre attentamente le recensioni prima di scaricare un’app, diffidare di promesse tecnicamente impossibili (nessuna app può legalmente accedere alle chiamate di un’altra persona), verificare il numero di recensioni reali rispetto ai download dichiarati, e controllare la data di pubblicazione e la storia dello sviluppatore. Mantenere Google Play Protect attivo è inoltre fondamentale per rilevare app già installate che potrebbero risultare malevole.

Tails, acronimo di The Amnesic Incognito Live System, è una distribuzione GNU/Linux progettata per garantire un elevato livello di privacy, sicurezza e anonimato durante l’utilizzo del computer e della rete. Il sistema funziona in modalità Live e instrada automaticamente tutto il...

🔗 Leggi il post completo

Se hai letto il nostro articolo su Copy Fail la settimana scorsa e hai tirato un sospiro di sollievo dopo aver aggiornato il Kernel, preparati: c’è già un successore. Si chiama Dirty Frag ed è registrata come l’unione di CVE-2026-43284 e CVE-2026-43500. A scoprirla è stato il ricercatore Hyunwoo Kim (noto online come “@v4bel”). L’exploit...

🔗 Leggi il post completo

A pochi giorni dalla presentazione ufficiale di Xperia 1 VIII, fissata per il 13 maggio, emergono nuove indiscrezioni sulla tecnologia della batteria del prossimo flagship Sony. La capacità rimarrà invariata a 5.000 mAh, ma stando ai leak, Sony avrebbe in serbo qualcosa di inedito che supererebbe anche il già apprezzato HS Power Control.

La capienza non cambia, ma arriva qualcosa di migliore

Le informazioni emerse da un forum ufficiale Sony indicano che la batteria di Xperia 1 VIII non crescerà di dimensioni come avvenuto su molti altri flagship recenti. Tuttavia, la fonte aggiunge che sarà presente “qualcosa di migliore” rispetto all’attuale sistema, e addirittura superiore all’HS Power Control già presente sulla serie attuale. Una promessa intrigante che stuzzica la curiosità degli appassionati.

Cos’è l’HS Power Control e perché è importante

L’HS Power Control (Heat Suppression Power Control) è una tecnologia esclusiva di Sony che permette di alimentare il dispositivo direttamente dall’alimentatore durante la ricarica o l’uso intenso, bypassando parzialmente la batteria. Questo riduce la generazione di calore e il degrado nel tempo, ed è particolarmente apprezzato da chi usa lo smartphone per gaming prolungato o riprese video. La funzione è già considerata un punto di forza della linea Xperia 1, quindi superarla sarebbe un risultato notevole.

Possibili evoluzioni tecnologiche

Basandosi sul leak, si possono ipotizzare diverse direzioni: un sistema di gestione dell’energia ancora più preciso basato su AI, un’evoluzione del sistema di raffreddamento con camera di vapore avanzata, oppure una nuova tecnologia di alimentazione wireless più efficiente. Non è escluso che Sony abbia sviluppato una combinazione di queste soluzioni per garantire autonomia e longevità superiori anche con una batteria da 5.000 mAh.

Appuntamento al 13 maggio

Tutti i dettagli saranno svelati durante l’evento di presentazione ufficiale. Sony ha già confermato la data: 13 maggio 2026, con livestream sul canale YouTube ufficiale. L’attesa cresce, e Xperia 1 VIII si preannuncia come uno degli smartphone più interessanti dell’anno sul fronte dell’autonomia.

PeaZip è un applicazione libera, open source e multi-piattaforma, progettata per la gestione e la compressione dei file. Si basa su strumenti consolidati come 7-Zip/p7zip, Zstandard e FreeArc, insieme ad altri algoritmi di compressione avanzati. Fin dalla sua nascita nel 2006, il progetto...

🔗 Leggi il post completo

Oppo ha avviato la distribuzione di ColorOS 16.1 per la serie Find X9. Si tratta di un aggiornamento corposo che introduce un nuovo linguaggio visivo ispirato al Liquid Glass, funzionalità smart per la schermata di blocco e importanti potenziamenti dell’intelligenza artificiale. Il rollout è partito dal mercato indiano e si espanderà progressivamente ad altre regioni.

Un nuovo look ispirato al Liquid Glass

La novità più visibile di ColorOS 16.1 è il rinnovamento estetico dell’interfaccia. Il Centro di Controllo ora presenta effetti di sfocatura più intensi, con superfici semitrasparenti che lasciano intravedere i contenuti sottostanti. L’effetto complessivo ricorda il cosiddetto “Liquid Glass”, un trend estetico sempre più diffuso tra i produttori Android che punta a interfacce più fluide, profonde e visivamente coerenti. Animazioni e transizioni tra le app risultano più morbide e curate rispetto alla versione precedente.

Live Space: informazioni in tempo reale sulla schermata di blocco

Tra le nuove funzionalità spicca “Live Space”, un sistema che mostra informazioni aggiornate in tempo reale direttamente sulla schermata di blocco. Il concetto richiama la “Now Bar” di Samsung, ma con lo stile visivo di Oppo: notifiche, musica in riproduzione e altri dati rilevanti vengono organizzati in un’interfaccia a pillola con animazioni fluide in stile Liquid Glass. Una soluzione comoda per consultare le informazioni essenziali senza sbloccare lo smartphone.

Intelligenza artificiale più capace

ColorOS 16.1 porta anche un significativo rafforzamento delle funzioni AI. Tra le novità più utili troviamo “AI Menu Translation”, che permette di tradurre i menu di ristoranti e altri testi inquadrati con la fotocamera, e “AI Mind Pilot”, uno strumento di assistenza all’uso dello smartphone. Oppo conferma così la propria attenzione all’integrazione dell’intelligenza artificiale nelle operazioni quotidiane, andando oltre la semplice estetica.

Fotocamera e schermata di blocco rinnovate

L’aggiornamento tocca anche l’app fotocamera, che riceve un’interfaccia rinnovata e una nuova funzione per aggiungere watermark personalizzati alle foto. Anche il player musicale sulla schermata di blocco è stato ridisegnato: ora si espande e si contrae in modo fluido, trascinando con sé gli altri elementi visivi in un’animazione coerente. Il pacchetto pesa circa 2,5 GB e il download via Wi-Fi è consigliato.

Per il momento ColorOS 16.1 è disponibile in fase beta per i Find X9, con il rilascio stabile previsto a breve per tutti gli utenti della serie.

Microsoft Copilot Studio è uno strumento di low-code per la creazione di agenti AI, e uno dei suoi punti di forza è l’esecuzione di logica C# direttamente nel browser tramite .NET WebAssembly (WASM). Di recente, il team di Copilot Studio ha completato la migrazione del motore WASM da .NET 8 a .NET 10 — e i risultati sono più che soddisfacenti. In questo articolo analizziamo in dettaglio cosa è cambiato, perché vale la pena migrare anche per le vostre applicazioni Blazor e WebAssembly, e quali ottimizzazioni concrete offre .NET 10 in questo ambito.

Il contesto: C# nel browser con .NET WebAssembly

Qualche mese fa il team di Copilot Studio aveva già pubblicato un post tecnico su come utilizzano .NET e WebAssembly per eseguire codice C# nel browser, mostrando i guadagni ottenuti passando da .NET 6 a .NET 8. Ora il ciclo si ripete con il salto a .NET 10, e la migrazione è stata descritta come sorprendentemente semplice.

Aggiornare un’applicazione WASM da .NET 8 a .NET 10 è sostanzialmente una questione di modificare il TargetFramework nei file .csproj e verificare la compatibilità delle dipendenze. Per Copilot Studio, il percorso è stato esattamente questo, e il build .NET 10 è già in produzione.

Fingerprinting automatico degli asset: addio script PowerShell personalizzati

Una delle novità più apprezzate di .NET 10 per le applicazioni WebAssembly è il fingerprinting automatico degli asset WASM. Quando si pubblica un’applicazione WebAssembly, ogni risorsa include ora un identificatore univoco nel nome del file, garantendo sia il cache-busting che l’integrità senza alcun intervento manuale.

Prima di .NET 10, Copilot Studio — come molte app WASM — doveva:

• Leggere il manifest blazor.boot.json pubblicato per enumerare tutti gli asset.
• Eseguire uno script PowerShell personalizzato per rinominare ogni file aggiungendo un hash SHA256.
• Passare un argomento integrity esplicito lato JavaScript al momento del caricamento di ogni risorsa.

Con .NET 10, tutto questo è storia. Le risorse vengono importate direttamente da dotnet.js, i fingerprint fanno parte dei nomi di file pubblicati, e l’integrità è validata automaticamente. Il team ha potuto eliminare lo script di rinomina personalizzato e rimuovere l’argomento integrity dal loader JavaScript lato client.

Tip: Se caricate il runtime .NET WASM all’interno di un WebWorker, impostate dotnetSidecar = true durante l’inizializzazione per garantire il corretto avvio nel contesto worker.

Output AOT più piccolo con WasmStripILAfterAOT

L’altra novità di spicco per .NET WASM in .NET 10 è che WasmStripILAfterAOT è ora abilitato per default per le build AOT. Dopo la compilazione ahead-of-time dei metodi .NET in WebAssembly, il codice IL (Intermediate Language) originale non è più necessario a runtime: .NET 10 lo elimina dall’output pubblicato per default. In .NET 8 questa impostazione esisteva ma era disattivata.

Copilot Studio adotta una strategia di packaging più sofisticata. Per ottenere il meglio sia in termini di avvio rapido che di performance a regime, spedisce un singolo pacchetto NPM che contiene sia un motore JIT (per l’avvio veloce) che un motore AOT (per la massima velocità di esecuzione). A runtime, Copilot Studio carica JIT e AOT in parallelo: il motore JIT gestisce le interazioni iniziali, poi cede il controllo all’AOT non appena è pronto. I file identici tra i due modi vengono deduplicati per mantenere il pacchetto compatto.

Poiché WasmStripILAfterAOT produce assembly AOT che non corrispondono più alle controparti JIT, meno file possono essere condivisi tra i due motori:

• Su .NET 8: 59 file condivisi tra JIT e AOT.
• Su .NET 10: solo 22 file condivisi.

L’effetto netto sul pacchetto Copilot Studio è un aumento di dimensione di circa il 15%. In pratica l’impatto per gli utenti finali è contenuto, poiché il motore JIT resta quello scaricato ed eseguito per primo: l’interattività iniziale non è compromessa. Il download AOT è circa 6% (~200 ms) più lento su una LAN veloce e circa 17% (~5 secondi) più lento su una connessione 4G — tutto in background, dopo che l’app è già operativa.

I risultati di performance

I benefici a runtime superano ampiamente il costo in termini di packaging per i workload di Copilot Studio:

• ~20% più veloce nell’esecuzione alla prima chiamata (cold path).
• ~5% più veloce nelle chiamate successive (warm path).

I guadagni sono più visibili negli agenti grandi e complessi (“big bots”), dove il codice AOT compilato fa il grosso del lavoro. Per workload più semplici i miglioramenti sono comunque presenti ma più contenuti.

Come migrare la vostra app a .NET 10

Se avete un’applicazione Blazor o .NET WebAssembly su .NET 8, vale la pena provare .NET 10. Ecco i passi essenziali:

1. Aggiornate <TargetFramework> a net10.0 e aggiornate i riferimenti a pacchetti Microsoft.AspNetCore.*, Microsoft.Extensions.* e System.*.
2. Rimuovete eventuale logica personalizzata di rinomina degli asset o plumbing per l’integrity — il fingerprinting è ora integrato.
3. Se compilate in AOT, beneficerete automaticamente del nuovo default WasmStripILAfterAOT.

Se avete bisogno di supporto per l’aggiornamento, GitHub Copilot app modernization for .NET può analizzare la soluzione, pianificare l’aggiornamento e applicare le modifiche necessarie.

Conclusione

La migrazione di Copilot Studio a .NET 10 è l’ennesima conferma che ogni release di .NET porta WebAssembly a essere più veloce, più leggero e più semplice da distribuire. La rimozione dello script di fingerprinting personalizzato è un piccolo ma significativo esempio di come il framework stia maturando: quello che prima richiedeva custom tooling è ora built-in. Se state ancora su .NET 8, questo è il momento giusto per valutare il salto.

Fonte: Copilot Studio gets faster with .NET 10 on WebAssembly — Daniel Roth, .NET Blog

SparkyLinux è una distribuzione GNU/Linux basata su Debian, progettata per offrire un sistema operativo veloce, leggero e altamente personalizzabile. Nata come progetto indipendente nel 2012, questa distribuzione si rivolge sia a chi muove i primi passi nel mondo del software...

🔗 Leggi il post completo

Samsung potrebbe ricorrere a pannelli OLED prodotti da fornitori cinesi per la prossima serie Galaxy S27. L’indiscrezione, riportata da media coreani, riflette le pressioni economiche legate all’aumento dei prezzi dei componenti — in particolare le memorie DRAM — che stanno spingendo il colosso sudcoreano a ripensare la propria strategia di approvvigionamento.

Il caro DRAM colpisce anche Samsung

Il mercato dei chip di memoria ha vissuto una fase di forte rialzo dei prezzi che ha impattato l’intera filiera degli smartphone premium. Samsung stessa ha già dovuto adeguare i prezzi della linea Galaxy S26, e per il futuro la pressione sui costi si fa ancora più intensa. Il display è una delle componenti più costose di uno smartphone flagship, e ridurne il costo potrebbe essere determinante per contenere il prezzo finale al pubblico.

BOE come possibile fornitore alternativo

Secondo le fonti, Samsung starebbe valutando BOE — il principale produttore di display cinese — come fornitore alternativo per i pannelli OLED di Galaxy S27. BOE non è un nome nuovo in questo settore: l’azienda produce già pannelli per Apple e altri brand, sebbene in passato sia stata oggetto di critiche per problemi di qualità e continuità di fornitura. Adottare BOE sui Galaxy S di fascia alta comporterebbe rischi reputazionali non indifferenti, dato che gli utenti si aspettano il massimo dai display Amoled della serie S.

Samsung non gode di prezzi agevolati dai propri fornitori interni

Un elemento interessante emerso dall’analisi è che Samsung Mobile non acquista i display da Samsung Display a prezzi di favore rispetto ai concorrenti. Questo significa che, dal punto di vista dei costi, passare a un fornitore esterno come BOE potrebbe effettivamente offrire un vantaggio economico reale. La “dual sourcing strategy” — ovvero affidarsi a più fornitori per lo stesso componente — è già pratica comune su dispositivi di fascia media come la serie Galaxy A, dove TCL CSOT fornisce già pannelli OLED.

Qualità: la sfida principale

Il vero nodo resta la qualità. Galaxy S è il biglietto da visita di Samsung nel mercato premium, e qualsiasi differenza nella resa cromatica, nella luminosità o nella durata dei pannelli verrebbe immediatamente notata — e criticata — dagli utenti. Samsung dovrebbe imporre standard qualitativi molto severi a BOE prima di procedere. Al momento si tratta ancora di valutazioni preliminari e nulla è stato finalizzato: l’accordo potrebbe non materializzarsi. Tuttavia, il segnale è chiaro: l’era dei costi fissi e delle supply chain blindate si sta sgretolando anche per i flagship.

Il Microsoft Agent Framework (MAF) è un framework open source multi-linguaggio pensato per costruire, orchestrare e distribuire agenti AI. Con le ultime versioni, il framework ha introdotto un modello di programmazione a workflow che permette di comporre più agenti e unità di lavoro in pipeline multi-step. In questo articolo vedremo come funziona questo modello, come aggiungere durabilità ai workflow e come fare il deploy su Azure Functions.

Il modello di programmazione a Workflow

Il sistema si basa su due concetti fondamentali: Executor e WorkflowBuilder.

Executor: l’unità di lavoro

Un Executor è la granularità minima del workflow. Riceve un input tipizzato, lo elabora e produce un output. Si crea estendendo Executor<TInput, TOutput>:

internal sealed class OrderLookup() : Executor<OrderCancelRequest, Order>("OrderLookup")
{
    public override async ValueTask<Order> HandleAsync(
        OrderCancelRequest message,
        IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        await Task.Delay(TimeSpan.FromMilliseconds(100), cancellationToken);
        return new Order(
            Id: message.OrderId,
            OrderDate: DateTime.UtcNow.AddDays(-1),
            IsCancelled: false,
            CancelReason: message.Reason,
            Customer: new Customer(Name: "Mario", Email: "mario@example.com"));
    }
}

internal sealed class OrderCancel() : Executor<Order, Order>("OrderCancel")
{
    public override async ValueTask<Order> HandleAsync(
        Order message, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        await Task.Delay(TimeSpan.FromMilliseconds(200), cancellationToken);
        return message with { IsCancelled = true };
    }
}

internal sealed class SendEmail() : Executor<Order, string>("SendEmail")
{
    public override ValueTask<string> HandleAsync(
        Order message, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        return ValueTask.FromResult(
            $"Email di cancellazione inviata per l'ordine {message.Id} a {message.Customer.Email}.");
    }
}

WorkflowBuilder: il grafo di esecuzione

Il WorkflowBuilder collega gli executor in un grafo diretto. Si definiscono gli archi tra executor e si ottiene un oggetto Workflow immutabile:

OrderLookup orderLookup = new();
OrderCancel orderCancel = new();
SendEmail sendEmail = new();

Workflow cancelOrder = new WorkflowBuilder(orderLookup)
    .WithName("CancelOrder")
    .WithDescription("Cancella un ordine e notifica il cliente")
    .AddEdge(orderLookup, orderCancel)
    .AddEdge(orderCancel, sendEmail)
    .Build();

Esecuzione in-process

Per eseguire il workflow senza dipendenze esterne si usa InProcessExecution.RunStreamingAsync. Restituisce uno StreamingRun che emette eventi man mano che ogni step completa:

var cancelRequest = new OrderCancelRequest(OrderId: "123", Reason: "Colore errato");

await using StreamingRun run = await InProcessExecution.RunStreamingAsync(
    cancelOrder, input: cancelRequest);

await foreach (WorkflowEvent evt in run.WatchStreamAsync())
{
    if (evt is ExecutorCompletedEvent completed)
        Console.WriteLine($"{completed.ExecutorId}: {completed.Data}");
}

Aggiungere la durabilità con DurableTask

L’esecuzione in-process perde lo stato se il processo termina. Per workflow di produzione — che devono sopravvivere ai riavvii, girare per ore e rimanere osservabili — si aggiunge il pacchetto Microsoft.Agents.AI.DurableTask:

dotnet add package Microsoft.Agents.AI.DurableTask --prerelease
dotnet add package Microsoft.DurableTask.Client.AzureManaged
dotnet add package Microsoft.DurableTask.Worker.AzureManaged
dotnet add package Microsoft.Extensions.Hosting

• Esecuzione stateful e durabile: il workflow sopravvive ai riavvii del processo
• Checkpointing automatico: il progresso viene salvato dopo ogni step
• Esecuzione distribuita: gli executor possono girare su macchine diverse
• Orchestrazioni long-running: i workflow possono durare minuti, ore o giorni
• Osservabilità: dashboard integrata per monitorare e gestire le esecuzioni

Il punto chiave è che la definizione del workflow non cambia. Si usa lo stesso WorkflowBuilder, cambia solo l’hosting:

string dtsConnectionString = "Endpoint=http://localhost:8080;TaskHub=default;Authentication=None";

IHost host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        services.ConfigureDurableWorkflows(
            workflowOptions => workflowOptions.AddWorkflow(cancelOrder),
            workerBuilder: builder => builder.UseDurableTaskScheduler(dtsConnectionString),
            clientBuilder: builder => builder.UseDurableTaskScheduler(dtsConnectionString));
    })
    .Build();

await host.StartAsync();

IWorkflowClient workflowClient = host.Services.GetRequiredService<IWorkflowClient>();
IAwaitableWorkflowRun run = (IAwaitableWorkflowRun)await workflowClient
    .RunAsync(cancelOrder, new OrderCancelRequest("12345", "Colore errato"));

string? result = await run.WaitForCompletionAsync<string>();
Console.WriteLine($"Workflow completato: {result}");

docker run -d --name dts-emulator   -p 8080:8080 -p 8082:8082   mcr.microsoft.com/dts/dts-emulator:latest

Fan-Out / Fan-In con agenti AI

Uno dei pattern più potenti è il fan-out/fan-in: più agenti AI elaborano lo stesso input in parallelo, poi un executor aggrega i risultati. MAF supporta l’uso diretto di agenti AI come executor tramite il metodo estensione AsAIAgent:

AIAgent physicist = chatClient.AsAIAgent(
    "Sei un esperto di fisica. Rispondi in 2-3 frasi concise.", "Physicist");

AIAgent chemist = chatClient.AsAIAgent(
    "Sei un esperto di chimica. Rispondi in 2-3 frasi concise.", "Chemist");

Workflow workflow = new WorkflowBuilder(parseQuestion)
    .WithName("ExpertReview")
    .AddFanOutEdge(parseQuestion, [physicist, chemist])
    .AddFanInBarrierEdge([physicist, chemist], aggregator)
    .Build();

Deploy su Azure Functions

Per il deploy serverless si aggiunge il pacchetto Microsoft.Agents.AI.Hosting.AzureFunctions. I vantaggi:

• Scaling serverless: Azure Functions scala automaticamente in base al carico
• HTTP endpoint automatici: ogni workflow registrato ottiene un HTTP trigger, senza scrivere controller o routing
• Supporto MCP: i workflow possono essere esposti come MCP tool con un singolo flag, rendendoli scopribili da altri agenti AI
• Zero boilerplate: il pacchetto genera orchestratori e activity function automaticamente

Conclusioni

Il Microsoft Agent Framework propone un’astrazione pulita per costruire workflow di agenti AI: si definisce il grafo una volta sola, e si sceglie il runtime — in-process per lo sviluppo, durable per la produzione, Azure Functions per il serverless. La separazione netta tra definizione del workflow e modalità di hosting è il punto di forza dell’approccio: consente di passare da un prototipo locale a un’orchestrazione distribuita con modifiche minime al codice.

Il framework è open source e in evoluzione rapida. Il codice di esempio completo è disponibile nella repository GitHub del Microsoft Agent Framework.

Fonte originale: Durable Workflows in the Microsoft Agent Framework — .NET Blog, Shyju Krishnankutty

Chi attendeva il nuovo tablet gaming RedMagic dovrà aspettare ancora un po’. L’azienda ha confermato che il nuovo modello compatto con display OLED non sarà annunciato insieme alla serie RedMagic 11S Pro il prossimo 18 maggio in Cina. La motivazione ufficiale parla di “colli di bottiglia” ancora da risolvere, lasciando intendere che lo sviluppo è ancora in corso.

Un tablet atteso, con specifiche da top di gamma

Il tablet in questione è stato al centro di numerose indiscrezioni nelle ultime settimane. Le specifiche trapelate lo descrivono come un dispositivo pensato per i gamer più esigenti: display OLED con refresh rate a 185 Hz, fino a 24 GB di RAM, 1 TB di storage e una batteria da 8.300 mAh. Il processore sarebbe lo Snapdragon 8 Elite Gen 5, il chip di nuova generazione Qualcomm. Il sistema di raffreddamento, ispirato a quello della serie RedMagic 11 Pro, garantirebbe sessioni di gioco prolungate senza surriscaldamenti.

Jiang Chao conferma il rinvio

A rivelare il rinvio è stato Jiang Chao, product manager di RedMagic, in un post sui social network cinesi. L’azienda ha riconosciuto l’esistenza di problemi tecnici ancora aperti, senza però specificarne la natura. È probabile che le difficoltà riguardino la gestione termica legata all’utilizzo dello Snapdragon 8 Elite Gen 5 in un form factor compatto, oppure l’ottimizzazione del display ad alto refresh rate. Il settore dei tablet gaming è in forte crescita — con concorrenti come Lenovo Legion Tab che si fanno sempre più agguerriti — e RedMagic non vuole rischiare di lanciare un prodotto non all’altezza delle aspettative.

Possibile emulatore PC a bordo

Una delle caratteristiche più curiose anticipate per questo tablet è la presenza di un emulatore per giochi PC integrato nel sistema, sulla scia di quanto già visto sul precedente modello RedMagic. Se confermata, questa funzione permetterebbe di eseguire alcuni titoli PC direttamente sul tablet Android, ampliandone notevolmente il catalogo di giochi disponibili e distinguendolo dai classici tablet Android.

Aggiornamenti attesi il 18 maggio

Nonostante il rinvio del tablet, RedMagic ha lasciato intendere che durante l’evento dell’11S Pro del 18 maggio potrebbero essere condivisi aggiornamenti sullo stato del progetto. Chi è interessato al dispositivo potrà quindi avere qualche informazione in più in quella data. La presentazione del tablet vero e proprio arriverà successivamente, con una data ancora da definire.

Il gruppo di estorsione digitale ShinyHunters ha violato Instructure, la società madre della piattaforma di e-learning Canvas, sottraendo 3,65 terabyte di dati relativi a circa 275 milioni di studenti e insegnanti distribuiti in 8.809 istituzioni scolastiche in tutto il mondo. L’attacco, rivendicato il 3 maggio 2026 e tuttora in evoluzione con un ultimatum di riscatto fissato al 12 maggio, è già classificato come il più grande data breach della storia nel settore dell’istruzione — con implicazioni che vanno ben oltre la semplice esfiltrazione di dati anagrafici.

La timeline dell’attacco

La prima anomalia rilevata è datata 29 aprile 2026, quando alcuni strumenti di Canvas iniziarono a mostrare malfunzionamenti. Il giorno successivo, Instructure confermò internamente una violazione criminale in corso e ingaggiò esperti forensi esterni. Il 3 maggio, ShinyHunters rivendicò pubblicamente l’attacco su forum underground, pubblicando campioni dei dati come prova. Il 7 maggio — in un’escalation particolarmente aggressiva — il gruppo defacciò le pagine di login di numerose istituzioni scolastiche clienti di Canvas, sostituendole con un messaggio di estorsione visibile a milioni di studenti nel pieno del periodo degli esami di fine anno accademico.

La scelta del momento non è casuale: colpire a maggio, durante le sessioni d’esame universitarie negli USA, nel Regno Unito e in Australia, massimizza la pressione mediatica e istituzionale, aumentando la probabilità che la vittima ceda alle richieste di riscatto.

Il vettore d’attacco: account Free-For-Teacher e abuso OAuth

Secondo le prime ricostruzioni rese note da Instructure, il punto d’ingresso iniziale è stato un’vulnerabilità legata agli account Free-For-Teacher, un tipo di account gratuito offerto da Canvas agli insegnanti per uso personale o sperimentale, con autorizzazioni API più ampie rispetto agli account studente standard. ShinyHunters, noto per la sua expertise nell’abuso di piattaforme cloud enterprise attraverso tecniche di vishing, furto di credenziali e abuso OAuth, ha sfruttato questo vettore per ottenere token di accesso con privilegi elevati all’infrastruttura di Instructure.

Il modus operandi del gruppo in operazioni precedenti — tra cui le violazioni di Snowflake (2024) e Salesforce — segue uno schema consolidato: compromissione di account cloud di terze parti con accesso API, escalation dei privilegi tramite token OAuth mal configurati o rubati, esfiltrazione massiva di dati in formato strutturato (database dump, CSV), e infine doppia estorsione con pubblicazione progressiva di campioni come leva negoziale.

La scala senza precedenti: chi è stato colpito

Con 8.809 istituzioni coinvolte in almeno otto Paesi — Stati Uniti, Canada, Regno Unito, Nuova Zelanda, Australia, Svezia, Paesi Bassi e Singapore — il breach Canvas supera qualsiasi precedente nella storia delle violazioni del settore education. Tra le istituzioni nominalmente esposte figurano MIT, Oxford, Duke University, University of Pennsylvania e centinaia di altre università di primo piano a livello globale.

I dati sottratti confermati includono: nomi e cognomi, indirizzi email istituzionali, numeri di matricola, iscrizioni ai corsi e — particolarmente sensibile — messaggi privati scambiati tra studenti e docenti. Instructure ha dichiarato che non risultano compromesse password, date di nascita, documenti d’identità governativi o informazioni finanziarie, ma l’entità dell’esfiltrazione — 3,65 TB — suggerisce che il quadro completo dei dati sottratti non sia ancora del tutto chiaro.

ShinyHunters: il profilo del gruppo

ShinyHunters è un gruppo di estorsione digitale attivo almeno dal 2020, noto per operazioni ad alto impatto contro piattaforme cloud. Nel curriculum del gruppo figurano violazioni di Tokopedia (91 milioni di record), Wattpad, Mathway, Pluto TV, e la già citata campagna Snowflake del 2024 che colpì centinaia di aziende Fortune 500 tramite furto di credenziali di clienti cloud. Il gruppo non dispone di una struttura ransomware con cifratura dei file: la loro arma primaria è la minaccia di pubblicazione dei dati, amplificata da azioni di defacement visibili (come le pagine login di Canvas sostituite) che generano massima pressione mediatica.

La deadline del 12 maggio 2026 per il pagamento del riscatto è in scadenza nei prossimi giorni. Non è noto l’importo richiesto. Instructure non ha confermato né smentito trattative in corso.

Cosa devono fare istituzioni e utenti

Le istituzioni che utilizzano Canvas devono agire immediatamente su più fronti: rotazione di tutte le API key Canvas, revoca e re-emissione di tutti i token OAuth attivi, verifica delle integrazioni SSO con provider di identità istituzionali, e audit degli account Free-For-Teacher attivi nella propria istanza. Per gli utenti finali, il rischio principale nelle settimane successive sarà quello di campagne di phishing personalizzate, che sfrutteranno i dati esfiltrati (email istituzionali, nomi dei corsi, messaggi privati) per costruire lure altamente credibili. La ricezione di email apparentemente provenienti da docenti, segreterie o piattaforme universitarie deve essere trattata con massima cautela per almeno i prossimi 90 giorni.

## Indicatori e dati chiave del breach Canvas/ShinyHunters
Data prima anomalia: 29 aprile 2026
Data rivendicazione: 3 maggio 2026
Data defacement login pages: 7 maggio 2026
Deadline riscatto: 12 maggio 2026
Volume dati sottratti: ~3,65 TB
Record compromessi (claim ShinyHunters): ~275 milioni
Istituzioni coinvolte: 8.809 (in 8+ Paesi)
Vettore iniziale: account Free-For-Teacher + abuso OAuth API
Dati confermati compromessi: nome, email, student ID, messaggi privati
Dati NON compromessi (Instructure): password, date nascita, ID gov., dati finanziari

## Azioni immediate per amministratori Canvas
1. Ruotare tutte le Canvas API key
2. Revocare e re-emettere i token OAuth attivi
3. Verificare integrazioni SSO e provider identità
4. Auditare account Free-For-Teacher attivi
5. Abilitare MFA per tutti gli account amministrativi

Con la crescita dei cluster Kubernetes verso decine di migliaia di nodi, i controller che osservano risorse ad alta cardinalità come i Pod si scontrano con un limite di scalabilità ben preciso. Kubernetes v1.36 introduce in alpha una soluzione elegante: il Server-Side Sharded List and Watch (KEP-5866), che sposta il filtraggio upstream nell’API server, riducendo drasticamente il traffico verso ogni replica di un controller.

Il problema: scaling client-side

Alcuni controller, come kube-state-metrics, supportano già lo sharding orizzontale: ogni replica è assegnata a una porzione dello spazio delle chiavi e scarta gli oggetti che non le appartengono. Questo approccio funziona dal punto di vista della correttezza, ma non risolve il problema di scala:

• N repliche × stream completo: ogni replica deserializza ed elabora ogni evento, poi scarta ciò che non le compete
• La banda di rete scala con le repliche, non con la dimensione dello shard
• CPU sprecata: il costo di deserializzazione è sostenuto per la frazione scartata

In sintesi, scalare orizzontalmente il controller moltiplica il costo per replica invece di ridurlo.

La soluzione: sharding lato server

Il Server-Side Sharded List and Watch risolve il problema spostando il filtraggio nell’API server. Ogni replica comunica all’API server quale intervallo di hash è di sua competenza, e l’API server invia solo gli eventi corrispondenti.

La feature aggiunge un campo shardSelector a ListOptions. I client specificano un intervallo di hash tramite la funzione shardRange():

shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')

La funzione di hash produce lo stesso risultato su tutte le istanze dell’API server, quindi la feature è sicura anche con più repliche dell’API server.

I percorsi di campo attualmente supportati sono object.metadata.uid e object.metadata.namespace.

Utilizzo pratico nei controller

I controller tipicamente usano informer per fare list e watch sulle risorse. Per fare lo sharding del carico, ogni replica inietta il shardSelector nelle ListOptions usate dai suoi informer tramite WithTweakListOptions:

import (
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/client-go/informers"
)

shardSelector := "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"

factory := informers.NewSharedInformerFactoryWithOptions(
    client,
    resyncPeriod,
    informers.WithTweakListOptions(func(opts *metav1.ListOptions) {
        opts.ShardSelector = shardSelector
    }),
)

// Replica 0: metà inferiore dello spazio di hash
"shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"

// Replica 1: metà superiore dello spazio di hash
"shardRange(object.metadata.uid, '0x8000000000000000', '0x10000000000000000')"

"shardRange(object.metadata.uid, '0x0000000000000000', '0x4000000000000000') || " +
"shardRange(object.metadata.uid, '0x8000000000000000', '0xc000000000000000')"

Verificare che il server supporti il selettore

Quando l’API server onora un shard selector, la risposta list include un campo shardInfo nel metadata della risposta che riporta il selettore applicato:

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "10245",
    "shardInfo": {
      "selector": "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"
    }
  },
  "items": [ ... ]
}

Come abilitarla e stato della feature

Questa feature è in alpha in Kubernetes v1.36 e richiede di abilitare il feature gate ShardedListAndWatch sull’API server:

--feature-gates=ShardedListAndWatch=true

Implicazioni architetturali

L’impatto di questa feature va oltre la semplice riduzione del traffico di rete. Cambia il modello mentale con cui si progettano controller scalabili:

• Efficienza reale: il costo per replica diminuisce proporzionalmente al numero di shard, invece di aumentare
• Scalabilità lineare: aggiungere repliche riduce effettivamente il carico su ciascuna
• Semplicità implementativa: lo sharding è dichiarativo — si specifica l’intervallo, l’API server fa il resto
• Compatibilità hash deterministica: FNV-1a garantisce distribuzione uniforme e risultati coerenti su più API server

Conclusioni

Il Server-Side Sharded List and Watch è una di quelle feature che risolvono un problema reale per chi opera cluster Kubernetes di grandi dimensioni. Spostare il filtraggio nell’API server è la scelta architetturalmente corretta: elimina il lavoro inutile alla radice invece di cercare di ottimizzarlo lato client.

Per i controller author e gli operatori di cluster grandi, vale la pena iniziare a sperimentare con questa feature sin da ora, contribuendo feedback al team di SIG API Machinery tramite il canale #sig-api-machinery su Kubernetes Slack.

Fonte originale: Kubernetes v1.36: Server-Side Sharded List and Watch — Kubernetes Blog, Jeffrey Ying

Cisco Talos ha svelato UAT-8302, un gruppo APT con nexus cinese che condivide un toolkit malware con almeno sei altri threat actor legati a Pechino. Dalla fine del 2024 a oggi, il gruppo ha silenziosamente compromesso enti governativi in Sud America e Sud-Est Europa, usando una catena d’attacco modulare che combina backdoor .NET personalizzate, strumenti Rust e impianti RAT avanzati — tutti con radici nell’ecosistema cyber-offensivo della Cina.

Un gruppo nuovo, un arsenale già conosciuto

Il 5 maggio 2026, i ricercatori di Cisco Talos hanno pubblicato l’analisi completa di UAT-8302, un cluster di attività che operava nell’ombra da oltre diciotto mesi prima di essere formalmente identificato. Ciò che rende questo threat actor particolarmente interessante non è solo chi ha colpito, ma come lo ha fatto: il gruppo ha fatto largo uso di malware già documentato in campagne di altri attori cinesi, costruendo un arsenale di strumenti condivisi che suggerisce un ecosistema coordinato tra hacking group legati allo Stato.

Talos valuta con alto grado di confidenza che UAT-8302 sia un APT a nexus cinese il cui obiettivo primario è ottenere e mantenere accessi persistenti e a lungo termine presso entità governative e organizzazioni correlate in tutto il mondo. Le vittime documentate includono ministeri e agenzie governative in Sud America (attive dalla fine del 2024) e Europa sud-orientale (documentate nel 2025).

La catena d’infezione: dall’exploit iniziale alla persistenza

I ricercatori sospettano che UAT-8302 sfrutti vulnerabilità zero-day e N-day in applicazioni web per ottenere l’accesso iniziale, anche se i vettori precisi non sono stati confermati in tutti i casi analizzati. Una volta ottenuto il foothold, la kill chain si sviluppa con metodologia da manuale per operazioni di spionaggio a lungo termine:

• Ricognizione estensiva: mapping della rete, enumerazione degli host e dei servizi esposti usando lo scanner open-source gogo, strumento popolare nell’ecosistema offensivo sinofono.
• Lateral movement: sfruttamento di Impacket per movimento laterale, accesso a credenziali e persistenza attraverso protocolli Windows.
• Distribuzione del payload finale: deployment di una o più famiglie malware personalizzate a seconda del target e dell’obiettivo dell’operazione.

L’arsenale malware: cinque famiglie per un unico attore

L’elemento più significativo di UAT-8302 è la varietà e la sofisticazione del suo toolkit. Il gruppo ha impiegato almeno cinque famiglie malware distinte, molte delle quali condivise con altri gruppi a nexus cinese:

NetDraft / NosyDoor

NetDraft (noto anche come NosyDoor) è una backdoor .NET che Talos descrive come una variante portata in C# del malware FINALDRAFT (alias Squidoor), sviluppato originariamente dal cluster Jewelbug/REF7707/CL-STA-0049. La caratteristica tecnica più rilevante è il suo meccanismo di C2: NetDraft utilizza la Microsoft Graph API per comunicare con il suo server di comando e controllo, usando OneDrive come canale covert. Un eseguibile legittimo viene usato per side-load una DLL malevola, che a sua volta decodifica NetDraft da un file di dati allegato ed esegue il codice nel contesto del processo corrente — una tecnica che rende l’impianto invisibile a molti prodotti EDR non configurati per monitorare l’uso anomalo delle API Microsoft.

SNOWRUST e VShell

Talos ha identificato SNOWRUST, una variante Rust di SNOWLIGHT, come stager di secondo livello. SNOWRUST decodifica ed esegue il shellcode di SNOWLIGHT incorporato per scaricare il payload finale — VShell (alias VSHELL) — da un server C2 in formato XOR-encoded. VShell è un RAT (Remote Access Trojan) documentato in numerose campagne cinesi precedenti e offre capacità complete di controllo remoto della macchina vittima.

CloudSorcerer v3.0

CloudSorcerer (versione 3.0) è una famiglia malware che Kaspersky aveva già documentato nel 2024 in attacchi contro entità governative russe. La comparsa della stessa famiglia in operazioni di UAT-8302 contro target diversi suggerisce non solo condivisione di codice, ma potenzialmente condivisione di infrastruttura o almeno di sviluppatori tra gruppi diversi dell’ecosistema APT cinese.

SNAPPYBEE / DeedRAT e ZingDoor

Le famiglie SNAPPYBEE (noto anche come DeedRAT) e ZingDoor sono state deployate congiuntamente in alcune campagne. SNAPPYBEE è una backdoor modulare con capacità di caricamento di plugin, già associata ad altri gruppi cinesi. ZingDoor, scritto in Go, completa il quadro con funzionalità di tunneling e proxy che facilitano la creazione di canali C2 resilienti.

Un ecosistema APT condiviso: la vera novità

Il dato più preoccupante che emerge dall’analisi Talos riguarda il modello operativo sottostante: UAT-8302 condivide il proprio arsenale con almeno sei altri gruppi APT a nexus cinese. Questo non è solo un’indicazione di affiliazione statale, ma suggerisce un’infrastruttura di sviluppo e distribuzione malware centralizzata, probabilmente gestita da un’entità governativa — plausibilmente correlata al Ministero della Sicurezza dello Stato (MSS) o all’Esercito Popolare di Liberazione (PLA).

Questa condivisione ha implicazioni pratiche per i difensori: il rilevamento di una singola famiglia (ad es. NetDraft) in un’organizzazione non significa necessariamente stare di fronte a UAT-8302 — potrebbe essere qualsiasi altro degli attori che usano lo stesso toolkit. Questo rende l’attribuzione più difficile e richiede un approccio di detection basato sul comportamento piuttosto che sulle singole firme malware.

Implicazioni geopolitiche

La scelta dei target — governi sudamericani e dell’Europa sud-orientale — riflette le priorità strategiche della Cina in due aree geografiche di crescente importanza. Il Sud America è al centro degli interessi economici e diplomatici di Pechino (BRI, accordi bilaterali, infrastrutture). L’Europa sud-orientale, con paesi come Serbia, Bulgaria e Romania, rappresenta un nodo critico per le ambizioni cinesi di influenza in Europa orientale, specialmente in un contesto di tensioni con NATO e UE.

Indicatori di compromissione (IoC)

Cisco Talos ha pubblicato IoC completi nel report ufficiale. Di seguito i principali indicatori tecnici associati alle famiglie malware di UAT-8302:

# Famiglie malware associate a UAT-8302
NetDraft / NosyDoor  — .NET backdoor, C2 via MS Graph API / OneDrive
SNOWRUST             — stager Rust, variante di SNOWLIGHT
VShell / VSHELL      — RAT multi-funzione, C2 XOR-encoded payload
CloudSorcerer v3.0   — backdoor condivisa con campagne Russia-targeting
SNAPPYBEE / DeedRAT  — backdoor modulare Go, plugin-based
ZingDoor             — tunneling/proxy Go-based

# Tecniche MITRE ATT&CK osservate
T1190 — Exploit Public-Facing Application (initial access)
T1574.002 — DLL Side-Loading (NetDraft loader)
T1071.001 — Application Layer Protocol: Web (MS Graph C2)
T1027 — Obfuscated Files or Information
T1078 — Valid Accounts (post-compromise credential abuse)
T1021 — Remote Services / Lateral Movement (Impacket)
T1082 — System Information Discovery
T1083 — File and Directory Discovery

# Tool open-source utilizzati
gogo      — scanner di rete popolare nell'ecosistema offensivo sinofono
Impacket  — toolkit Python per SMB/Kerberos/lateral movement

Due righe per i difensori

Dati i vettori e le tecniche osservate, le organizzazioni governative e le infrastrutture critiche dovrebbero prioritizzare le seguenti misure difensive. In primo luogo, monitorare il traffico verso Microsoft Graph API e OneDrive per accessi anomali da processi di sistema o applicazioni non standard — NetDraft usa questo canale per mascherare il C2 tra traffico legittimo. In secondo luogo, implementare controlli di DLL sideloading verificando che gli eseguibili firmati non carichino DLL da percorsi non standard. In terzo luogo, rilevare l’uso di Impacket attraverso il monitoraggio di traffico SMB/DCE-RPC anomalo, autenticazioni Kerberos insolite e creazione di servizi remoti. Infine, tenere aggiornate le applicazioni web esposte su internet, poiché UAT-8302 sfrutta CVE noti e zero-day per l’accesso iniziale.

Il report completo di Cisco Talos con IoC estesi è disponibile su blog.talosintelligence.com.

Uno degli ostacoli più concreti nel lavorare con agenti AI è la mancanza di contesto reale: i modelli linguistici hanno una conoscenza “congelata” nel tempo e non hanno accesso ai vostri dati aziendali, alle vostre API interne o agli strumenti specifici del dominio. Il Model Context Protocol (MCP) nasce per risolvere esattamente questo problema, standardizzando il modo in cui applicazioni e agenti AI si scambiano contesto e strumenti. In questo articolo vediamo come i developer .NET possono costruire un MCP Server in C# e integrarlo con agenti AI come GitHub Copilot.

Cos’è il Model Context Protocol

MCP è un protocollo aperto — originariamente sviluppato da Anthropic e ora supportato da numerose aziende tech — che definisce un linguaggio comune tra agenti AI e endpoint specializzati. L’idea è semplice: un MCP Server espone tool (funzioni invocabili), resource (dati strutturati) e prompt (template riutilizzabili) che un agente AI può scoprire e usare dinamicamente. Il risultato è un’integrazione grounded e sicura, in cui l’agente sa cosa può fare e con quali dati lavorare.

Per i developer .NET c’è una buona notizia: esiste un SDK C# ufficiale per MCP che rende la costruzione di server e client MCP relativamente semplice, integrabile con il familiare ecosistema di Microsoft.Extensions.

Struttura base di un MCP Server in C#

Il punto di partenza è un’applicazione console .NET. Le dipendenze NuGet necessarie nel file .csproj sono:

<ItemGroup>
  <PackageReference Include="ModelContextProtocol" Version="*" />
  <PackageReference Include="Microsoft.Extensions.Hosting" Version="*" />
</ItemGroup>

Definire i Tool con gli attributi MCP

La magia di MCP in C# passa attraverso due attributi principali: [McpServerToolType] applicato alla classe e [McpServerTool] applicato ai metodi. Ecco un esempio minimale con un tool Echo:

using ModelContextProtocol.Server;
using System.ComponentModel;

[McpServerToolType]
public static class EchoTool
{
    [McpServerTool, Description("Restituisce il messaggio ricevuto al mittente.")]
    public static string Echo(string message) => $"Hai detto: {message}";
}

Vediamo ora un tool più realistico che chiama un’API HTTP e restituisce dati JSON:

using System.ComponentModel;
using System.Net.Http.Json;
using System.Text.Json;
using ModelContextProtocol.Server;

[McpServerToolType]
public static class PostDataTool
{
    [McpServerTool, Description("Recupera un elenco di post di esempio dall'API.")]
    public static async Task<string> GetSamplePosts()
    {
        using var client = new HttpClient
        {
            BaseAddress = new Uri("https://jsonplaceholder.typicode.com")
        };
        var posts = await client.GetFromJsonAsync<List<Post>>("/posts");
        return JsonSerializer.Serialize(posts ?? new List<Post>());
    }
}

public class Post
{
    public int Id { get; set; }
    public string? Title { get; set; }
    public string? Body { get; set; }
}

Configurare il server in Program.cs

La configurazione del server MCP avviene in Program.cs, sfruttando il generic host di .NET:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = Host.CreateApplicationBuilder(args);

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()   // trasporto stdio per uso locale / VS Code
    .WithToolsFromAssembly();     // scoperta automatica di tutti i [McpServerToolType]

await builder.Build().RunAsync();

Registrare il server in VS Code

Per rendere il server MCP disponibile a VS Code e a GitHub Copilot, create un file .vscode/mcp.json nella root del progetto:

{
  "servers": {
    "MyMcpServer": {
      "type": "stdio",
      "command": "dotnet",
      "args": [
        "run",
        "--project",
        "/percorso/completo/MyMcpServer.csproj"
      ]
    }
  }
}

Testare con l’MCP Inspector

Prima di integrare il server con un agente AI reale, è utile verificarne il funzionamento con l’MCP Inspector, uno strumento interattivo basato su Node.js con frontend React. Non richiede installazione: basta eseguire:

npx @modelcontextprotocol/inspector

Integrazione con GitHub Copilot in modalità agente

Con il server registrato in mcp.json, GitHub Copilot in modalità Agent può scoprire e invocare i vostri tool. Nella chat è sufficiente fare riferimento a un tool con #NomeServer_NomeTool, oppure chiedere all’agente di completare un compito e lasciare che sia lui a decidere quali tool usare.

L’agente chiederà conferma prima di eseguire qualsiasi tool (a meno che non abbiate abilitato l’approvazione automatica per la sessione), e il risultato viene usato come contesto per la risposta successiva. Questo pattern è particolarmente potente quando il tool restituisce dati specifici del dominio — configurazioni di sistema, query a database interni, stati di pipeline CI/CD — che il modello non potrebbe altrimenti conoscere.

Scenari pratici per developer .NET

Alcuni use case concreti per un MCP Server in C#:

• Query al database aziendale: esporre viste o stored procedure come tool MCP per permettere all’agente di rispondere a domande sui dati reali.
• Integrazione con sistemi interni: wrappare API REST o servizi WCF legacy come tool MCP senza riscrivere nulla.
• Automazione DevOps: tool per interrogare lo stato di pipeline, deployment o metriche di monitoring direttamente dalla chat dell’agente.
• Contesto di progetto: esporre convenzioni architetturali, ADR (Architecture Decision Records) o specifiche di dominio come risorse MCP per guidare la generazione di codice.

Conclusione

Il Model Context Protocol è ancora in evoluzione, ma le fondamenta sono solide e l’adozione sta crescendo rapidamente. Per i developer .NET, l’SDK C# rende la costruzione di MCP Server accessibile e naturale, senza allontanarsi dalle convenzioni del framework. Investire oggi nel capire MCP significa essere pronti quando gli agenti AI diventeranno parte integrante del workflow di sviluppo quotidiano — e quel momento è già più vicino di quanto sembri.

Fonti: MCP Magic: Building Tool-Enabled AI Agents with C# — Visual Studio Magazine; Build & Leverage MCP Servers in C# for AI-Driven Development — Uno Platform

Sony ha pubblicato il secondo video teaser dedicato a Xperia 1 VIII, il prossimo flagship dell’azienda atteso per la presentazione ufficiale del 13 maggio 2026. Dopo il primo teaser che evocava un “ritorno alle origini”, questa volta il messaggio è ancora più diretto: preparatevi a una scossa sismica.

Il messaggio: “Brace yourself for a seismic shift”

Il video mostra rocce e strati geologici in movimento, immagini che trasmettono potenza e cambiamento radicale. Il testo che accompagna le immagini è inequivocabile: “Brace yourself for a seismic shift, the next one is coming” — ovvero, preparati a una scossa sismica, il prossimo sta arrivando. L’espressione “seismic shift” non indica solo un terremoto, ma in senso figurato un cambiamento epocale, una trasformazione che sovverte tutto ciò che era noto.

Il teaser è stato pubblicato sull’account ufficiale Twitter di Sony Xperia, con l’invito a seguire l’annuncio ufficiale sul canale YouTube il 13 maggio alle 11:00 ora giapponese (le 4:00 ora italiana).

Ritorno alle origini e rivoluzione: due messaggi che si fondono

Mettendo insieme i due teaser, emerge un racconto coerente. Il primo parlava di “come full circle”, ovvero tornare al punto di partenza, con riferimenti a funzioni amate del passato come il LED di notifica. Il secondo promette invece qualcosa di nuovo e dirompente. Sony sembra voler dire che Xperia 1 VIII riprenderà il meglio della tradizione del brand per poi spingerlo in una direzione inaspettata.

Il modulo fotocamera cambia forma

Una delle novità già confermate dai leak riguarda il design della fotocamera: Xperia 1 VIII abbandonerà il classico modulo verticale che ha caratterizzato la serie per anni, adottando un nuovo layout quadrato. Un cambiamento visivo significativo che segna la fine di un’era per gli Xperia fan. Il video teaser allude proprio a questa trasformazione attraverso le immagini di strati che si spostano e si riorganizzano.

Cosa aspettarsi il 13 maggio

Stando alle indiscrezioni circolate finora, Xperia 1 VIII dovrebbe portare importanti miglioramenti sia sul fronte fotografico — con un teleobiettivo di nuova generazione — sia sul fronte della batteria, con tecnologie inedite oltre all’attuale HS Power Control. La presentazione ufficiale chiarirà tutti i dettagli. Noi saremo lì a coprire ogni annuncio.

Si parla di:
Toggle

Dal 8 aprile 2026, chiunque abbia scaricato DAEMON Tools dal sito ufficiale ha potuto ricevere un installer trojanizzato — firmato digitalmente dal produttore — che installa silenziosamente una backdoor con capacità di comunicazione su sette protocolli diversi, tra cui QUIC e HTTP/3. Kaspersky ha svelato l’operazione a maggio: migliaia di tentativi di infezione in oltre 100 paesi, con targeting chirurgico su enti governativi, scientifici e industriali in una seconda fase. Sullo sfondo, i ricercatori puntano verso un attore di lingua cinese.

Il vettore d’attacco: il sito ufficiale come arma

DAEMON Tools è uno dei software di emulazione dischi più diffusi al mondo, con decine di milioni di utenti. La sua ubiquità lo rende un bersaglio ideale per un attacco supply chain: compromettere il sito ufficiale significa trasformare uno strumento di fiducia in un vettore di distribuzione malware su scala globale.

Secondo l’analisi pubblicata da Kaspersky su Securelist, i ricercatori hanno identificato che le versioni da 12.5.0.2421 a 12.5.0.2434 di DAEMON Tools distribuite dal sito ufficiale del produttore — AVB Disc Soft — contenevano componenti binari modificati con codice malevolo. La finestra di compromissione è iniziata almeno dall’8 aprile 2026 e l’attacco era ancora attivo al momento della divulgazione pubblica avvenuta intorno al 6 maggio 2026.

Anatomia tecnica: tre binari compromessi, un’unica catena d’attacco

Gli attaccanti hanno manomesso tre componenti specifici all’interno del pacchetto di installazione:

• DTHelper.exe — componente helper principale del software
• DiscSoftBusServiceLite.exe — servizio di sistema lanciato all’avvio del sistema
• DTShellHlp.exe — helper per le funzioni di shell integration

L’elemento più insidioso è che tutti e tre i file risultano ancora firmati digitalmente con certificati validi di AVB Disc Soft. Questo significa che i controlli di firma digitale standard — inclusi quelli di Windows SmartScreen e la maggior parte degli antivirus basati su reputazione — non avrebbero segnalato nulla di anomalo al momento dell’installazione. Solo una soluzione EDR con analisi comportamentale avanzata avrebbe potuto identificare l’attività malevola in fase di esecuzione.

Ogni volta che uno di questi binari viene lanciato — e dato che DiscSoftBusServiceLite.exe è un servizio Windows, ciò avviene automaticamente ad ogni avvio del sistema — la backdoor si attiva e stabilisce comunicazione con il server C2.

Il payload di prima fase: information stealer silenzioso

Nella maggior parte dei sistemi infetti, l’attivazione della backdoor comporta innanzitutto l’esecuzione di un info-stealer di prima fase che raccoglie i seguenti dati di profilazione del sistema:

• Indirizzo MAC e hostname della macchina
• Software installato ed elenco processi in esecuzione
• Configurazione di rete (interfacce, IP, gateway)
• Locale di sistema e impostazioni geografiche

Questi dati vengono trasmessi al server C2 e con ogni probabilità utilizzati per selezione e triage delle vittime: non tutti i sistemi infetti ricevono il payload avanzato. Kaspersky ha rilevato che solo un numero limitato di macchine — stimato in una dozzina di sistemi su migliaia di infezioni — ha ricevuto il secondo stage, il che indica targeting altamente selettivo.

QUIC RAT: la backdoor di secondo livello

I sistemi selezionati ricevono QUIC RAT, un impianto avanzato che prende il nome dal protocollo di trasporto di Google su cui si basa come canale C2 preferenziale. La caratteristica tecnica distintiva di QUIC RAT è la sua resilienza nei canali di comunicazione: il malware supporta ben sette protocolli C2 distinti, da usare in modo adattivo a seconda dell’ambiente della vittima:

• HTTP e HTTPS — per ambienti con proxy web standard
• UDP e TCP raw — per connessioni dirette a bassa latenza
• WSS (WebSocket Secure) — per bypassare firewall che bloccano connessioni non-HTTP
• QUIC (HTTP/3 su UDP) — il protocollo eponimo, difficile da ispezionare con DPI tradizionale
• DNS — per ambienti con filtering aggressivo, usando richieste DNS come canale covert

Questa flessibilità rende QUIC RAT particolarmente difficile da bloccare con soluzioni di network security tradizionali: anche in ambienti con firewalling aggressivo, il malware può adattarsi dinamicamente al protocollo consentito.

Sul fronte delle funzionalità offensive, QUIC RAT è capace di iniettare payload malevoli nei processi notepad.exe e conhost.exe — due processi legittimi di Windows particolarmente adatti al process injection per la loro ubiquità e bassa visibilità in ambienti non monitorati.

La scala dell’operazione

A partire dall’inizio di aprile 2026, Kaspersky ha rilevato diverse migliaia di tentativi di installazione di payload malevoli attraverso DAEMON Tools compromesso, con vittime distribuite in oltre 100 paesi e territori. La distribuzione geografica è significativa: il maggior numero di infezioni è stato rilevato in Russia, Brasile, Turchia, Spagna, Germania, Francia, Italia e Cina.

La composizione delle vittime rivela la natura dell’operazione: circa il 90% dei sistemi infetti appartiene a utenti privati, mentre il restante 10% corrisponde a sistemi aziendali e organizzativi. È plausibile che la grande massa di utenti privati funzionasse come copertura e rumore di fondo, mentre gli attaccanti erano in realtà interessati alla percentuale aziendale — che in termini assoluti, su migliaia di infezioni, rappresenta comunque centinaia di potenziali target di interesse.

Kaspersky ha specificato che tra le organizzazioni colpite dalla seconda fase con QUIC RAT figurano enti governativi, istituti di ricerca scientifica e aziende manifatturiere.

Attribuzione: tracce verso un attore sinofono

Kaspersky non attribuisce formalmente l’attacco a un gruppo specifico, ma i ricercatori hanno rilevato stringhe in lingua cinese nel payload di prima fase. Questo, combinato con la sofisticazione operativa dell’attacco, la selezione dei target di seconda fase e la natura delle vittime prioritizzate, suggerisce un attore di lingua cinese — potenzialmente un gruppo APT state-sponsored, anche se al momento non è possibile escludere un cybercriminale con capacità avanzate.

Il pattern di targeting selettivo e il profilo delle vittime di alto valore sono però più coerenti con operazioni di intelligence che con motivazioni puramente economiche.

Indicatori di compromissione (IoC)

# Versioni DAEMON Tools compromesse
Versioni affette: 12.5.0.2421 — 12.5.0.2434

# Binari manomessi (firmati da AVB Disc Soft)
DTHelper.exe
DiscSoftBusServiceLite.exe
DTShellHlp.exe

# Protocolli C2 usati da QUIC RAT
HTTP, HTTPS, UDP, TCP, WSS (WebSocket Secure), QUIC/HTTP3, DNS

# Tecniche MITRE ATT&CK
T1195.002 — Supply Chain Compromise: Software Supply Chain
T1553.002 — Subvert Trust Controls: Code Signing (signed malicious binaries)
T1071     — Application Layer Protocol (multi-protocol C2)
T1572     — Protocol Tunneling (QUIC/DNS channels)
T1055     — Process Injection (notepad.exe / conhost.exe)
T1082     — System Information Discovery (first-stage profiling)
T1018     — Remote System Discovery

# Nota: IoC hash completi disponibili su Securelist
# https://securelist.com/daemon-tools-backdoor/

Come verificare se si è stati colpiti

Chi ha installato o aggiornato DAEMON Tools tra aprile e inizio maggio 2026 dovrebbe verificare urgentemente la versione installata. Se rientra nell’intervallo 12.5.0.2421-12.5.0.2434, è necessario procedere come segue: disinstallare immediatamente DAEMON Tools e aggiornare all’ultima versione disponibile dal sito ufficiale (già corretta al momento della disclosure). Eseguire una scansione completa con una soluzione EDR aggiornata, monitorando in particolare attività anomale di notepad.exe e conhost.exe. Verificare la presenza di connessioni insolite su porta UDP 443 (QUIC) o traffico DNS anomalo verso domini non riconosciuti. Controllare il registro di sistema per servizi sospetti aggiunti da DiscSoftBusServiceLite.exe o varianti.

Il report tecnico completo di Kaspersky con hash SHA256 e IoC di rete è disponibile su Securelist. La press release ufficiale è su kaspersky.com.

Gli agenti AI hanno cambiato radicalmente il modello di minaccia delle applicazioni basate su LLM. Finché un modello si limita a generare testo, le vulnerabilità rimangono nel dominio del contenuto. Ma non appena lo si dota di plugin (o tool) — lettura di file, query su database, esecuzione di script — il perimetro si espande. Una prompt injection non è più un problema di risposta inappropriata: può diventare un primitivo di esecuzione di codice arbitrario.

Il team di Microsoft Defender Security Research ha pubblicato un’analisi dettagliata di due vulnerabilità critiche scoperte in Semantic Kernel, il framework open source di Microsoft per la costruzione di agenti AI. Entrambe le vulnerabilità — già corrette — avrebbero consentito a un attaccante di ottenere RCE (Remote Code Execution) sul sistema che eseguiva l’agente, partendo semplicemente da un prompt malevolo.

Il problema di fondo: i framework AI si fidano troppo dell’output del modello

I framework come Semantic Kernel, LangChain e CrewAI agiscono come “sistema operativo” per gli agenti AI: astraggono l’orchestrazione del modello, gestiscono il routing verso i plugin e traducono il linguaggio naturale in chiamate a funzione strutturate. Questa convenienza ha un costo nascosto: ogni vulnerabilità nel modo in cui il framework mappa l’output del modello verso i tool di sistema porta un rischio sistemico.

Il modello AI stesso non è il problema — si comporta esattamente come progettato, parsando il linguaggio naturale in schemi di tool calling. Il problema sta nel fatto che il framework e i tool si fidano ciecamente dei dati così ottenuti.

CVE-2026-26030: In-Memory Vector Store e la pericolosità di eval()

La prima vulnerabilità riguarda il Search Plugin di Semantic Kernel quando usa l’In-Memory Vector Store con la configurazione predefinita.

Lo scenario di attacco richiede due condizioni:

1. L’attaccante deve avere un vettore di prompt injection — ovvero la capacità di influenzare gli input dell’agente
2. L’agente deve usare il Search Plugin con l’In-Memory Vector Store come backend

Radice tecnica del problema

La funzione di filtro predefinita dell’In-Memory Vector Store è implementata come espressione lambda Python eseguita tramite eval(). Per una ricerca tipica come “Find hotels in Paris”, il filtro generato è:

new_filter = "lambda x: x.city == 'Paris'"

Il tentativo di mitigazione con blocklist — e il suo fallimento

I developer di Semantic Kernel avevano anticipato il rischio e implementato una blocklist che parsava il filtro in un Abstract Syntax Tree (AST) prima dell’esecuzione. Il validator:

• Permetteva solo espressioni lambda
• Rifiutava import e definizioni di classi
• Cercava identificatori pericolosi (eval, exec, open, __import__…)
• Eseguiva il codice in un ambiente ristretto con __builtins__ svuotati

I ricercatori hanno trovato un bypass completo. Il payload di exploit sfruttava quattro debolezze architetturali della blocklist:

1. Nomi mancanti nella blocklist: attributi come __name__, load_module, system e la classe BuiltinImporter non erano presenti nella lista nera
2. Il check strutturale passava: il payload era avvolto in una lambda valida, quindi isinstance(tree.body, ast.Lambda) restituiva True
3. __builtins__ vuoto era irrilevante: il payload partiva da tuple(), che esiste indipendentemente dall’ambiente dei builtin, e risaliva la gerarchia dei tipi Python per raggiungere funzionalità pericolose senza mai chiamare una builtin direttamente
4. Nessun controllo su ast.Subscript: anche se un nome bloccato fosse stato necessario, si sarebbe potuto accedere con notazione bracket (obj['__class__'] invece di obj.__class__), creando un nodo ast.Subscript ignorato dalla validazione

Il risultato pratico: un singolo prompt malevolo era sufficiente per lanciare calc.exe sul sistema che eseguiva l’agente, senza exploit del browser, allegati malevoli o memory corruption.

La lezione generale: le blocklist nei linguaggi dinamici sono fragili

Python (e linguaggi dinamici in generale) offre troppa flessibilità per essere gestita efficacemente con una lista nera. La gerarchia di classi del runtime, la riflessione, i dunders e le notazioni alternative rendono qualsiasi blocklist incompleta per definizione.

CVE-2026-25592: scrittura arbitraria di file tramite SessionsPythonPlugin

La seconda vulnerabilità riguarda il SessionsPythonPlugin, che permette agli agenti di eseguire codice Python in sessioni di Azure Container Apps. Il plugin accetta un nome di file come parametro controllato dall’LLM — senza validazione del percorso — e lo usa per scrivere file nel filesystem del container. Attraverso path traversal (es. ../../etc/cron.d/payload), un attaccante con accesso al vettore di prompt injection potrebbe scrivere file arbitrari in posizioni sensibili del sistema.

La mitigazione applicata da Semantic Kernel

Dopo la responsible disclosure al MSRC, il team di Semantic Kernel ha implementato una correzione multilivello per CVE-2026-26030, sostituendo la blocklist con un approccio allowlist a quattro strati:

1. Allowlist dei tipi AST: solo costrutti sicuri sono permessi — comparazioni, logica booleana, aritmetica, letterali
2. Allowlist delle chiamate a funzione: anche i nodi di chiamata AST permessi vengono verificati per assicurarsi che invochino solo funzioni sicure
3. Blocklist degli attributi pericolosi: traversata della gerarchia di classi bloccata esplicitamente (__class__, __subclasses__)
4. Restrizione sui nodi Name: solo il parametro della lambda (es. x) è accettabile come identificatore; riferimenti a os, eval, type e simili vengono rifiutati

Come sapere se si è vulnerabili

Si è esposti a CVE-2026-26030 se:

• Si usa il pacchetto Python semantic-kernel
• La versione del framework è precedente alla 1.39.4
• L’agente usa l’In-Memory Vector Store con funzionalità di filtro abilitata come backend per il Search Plugin

Per verificare la versione installata:

pip show semantic-kernel

pip install --upgrade semantic-kernel

Raccomandazioni per gli sviluppatori di agenti AI

Questa ricerca offre lezioni importanti per chiunque stia costruendo applicazioni con agenti AI:

• Non trattare l’output del modello come dati fidati: qualsiasi valore che passa dal modello AI a un tool deve essere trattato come input non fidato, validato e sanitizzato come si farebbe con input da un utente esterno
• Preferire allowlist alle blocklist: nelle valutazioni di codice dinamico, le blocklist sono intrinsecamente incomplete. Un allowlist di costrutti permessi è molto più robusto
• Evitare eval() con input derivati dall’LLM: se il requisito è eseguire espressioni dinamiche, usare AST parsing con validazione rigorosa o, meglio, un motore di espressioni dedicato con capacità limitate
• Applicare il principio del minimo privilegio: i plugin degli agenti dovrebbero avere solo le autorizzazioni strettamente necessarie; un plugin che scrive file non dovrebbe mai avere accesso all’intero filesystem
• Monitorare i vettori di prompt injection: qualsiasi fonte esterna che l’agente legge (email, documenti, pagine web, risultati di ricerca) è un potenziale vettore di attacco
• Tenere aggiornati i framework: le vulnerabilità nei framework AI si stanno moltiplicando rapidamente; aggiornare regolarmente e seguire i bollettini di sicurezza dei vendor è essenziale

Un challenge per mettersi alla prova

Microsoft ha anche pubblicato un CTF challenge interattivo che permette di testare l’exploit su un agente Semantic Kernel di esempio in modo sicuro e controllato. È un ottimo modo per capire concretamente il vettore di attacco senza rischiare sistemi reali.

Conclusione

La transizione degli agenti AI da generatori di testo a sistemi che operano attivamente sull’infrastruttura richiede un cambio di mentalità nella sicurezza. Le vulnerabilità come CVE-2026-26030 e CVE-2026-25592 mostrano che i rischi sono reali e concreti: un prompt malevolo può diventare RCE. Aggiornare Semantic Kernel alla versione 1.39.4 o superiore è la priorità immediata; rivedere l’architettura dei propri agenti alla luce del principio di minimo privilegio è il passo successivo.

Microsoft ha annunciato una serie di ricerche simili su altri framework AI (LangChain, CrewAI e altri) — ulteriori pubblicazioni sono previste nelle prossime settimane.

Fonte: When prompts become shells: RCE vulnerabilities in AI agent frameworks — Microsoft Defender Security Research Team (7 maggio 2026)

Sony Xperia 1 VIII si avvicina al lancio e i leak si fanno sempre più precisi. La novità più interessante riguarda la strategia di distribuzione: stando alle ultime indiscrezioni, il mercato giapponese riceverà il telefono prima dell’Europa, invertendo la tendenza storica della serie Xperia.

Europa: disponibile dal 26 giugno 2026

Per il mercato europeo, la data cerchiata in rosso sarebbe il 26 giugno 2026. Il prezzo trapelato è di circa 1.729 euro in bundle con le cuffie wireless WH-1000XM6, ma la cifra per il solo smartphone non è ancora nota. I colori previsti sono quattro: nero, bianco, rosso e giallo, con le ultime due tonalità che rappresentano una scelta audace e insolita per il brand.

Xperia AI e fotocamera con tele rinnovato

Sul fronte hardware, la principale novità fotografica sarebbe un teleobiettivo di nuova generazione all’interno della classica configurazione con tre sensori. Fa capolino anche “Xperia AI”, una suite di funzioni intelligenti che potrebbero toccare la gestione della fotocamera, l’autonomia e le ottimizzazioni di sistema. Sony punta ancora sull’esperienza di scatto professionale come punto di forza distintivo.

Giappone prima dell’Europa: un cambio di rotta significativo

Da sempre, i flagship Xperia arrivavano in Europa con qualche settimana di anticipo rispetto al Giappone. Questa volta la situazione si capovolge, con Giappone e mercati asiatici (Hong Kong, Taiwan) che precedono il lancio europeo. Un segnale che Sony sta ricalibrando le proprie priorità geografiche, forse per puntare con più forza sul proprio mercato domestico dove il brand gode di una base fedele molto solida.

Mentre Google dice no al Liquid Glass su Pixel, Xiaomi sembra andare nella direzione opposta. Le ultime indiscrezioni sulla prossima versione dell’interfaccia HyperOS, la versione 4, parlano di un profondo rinnovamento grafico ispirato proprio a questo tipo di estetica: trasparenze, effetti di sfocatura e un senso di profondità che cambierebbe radicalmente l’aspetto visivo dei telefoni Xiaomi.

Cosa si intende per Liquid Glass design

Il concetto di Liquid Glass in ambito UI si riferisce a interfacce con superfici semi-trasparenti che filtrano i contenuti sottostanti, effetti di luce e rifrazione, e un senso di tridimensionalità. Non si tratta semplicemente di estetica: l’idea è creare un’esperienza visiva più immersiva e coerente. Già nella tastiera di sistema dell’attuale HyperOS si vedono i primi test di sfocatura, considerati come anteprima di ciò che verrà.

Non tutti i dispositivi ne beneficeranno allo stesso modo

Gli effetti di trasparenza e sfocatura richiedono risorse GPU significative, quindi HyperOS 4 proporrà presumibilmente un’esperienza scalata in base all’hardware. I modelli Xiaomi 17, 15T Pro e alcuni della serie 13 dovrebbero ricevere l’implementazione completa, mentre i dispositivi di fascia più bassa — come alcuni Redmi e POCO entry-level — otterranno una versione semplificata.

Un trend che potrebbe diffondersi nell’ecosistema Android

Quello che rende interessante la mossa di Xiaomi è il possibile effetto domino. Se HyperOS 4 avrà successo con questo approccio, altri produttori Android potrebbero seguire la stessa strada. Del resto, anche Android 17 stesso sembra voler introdurre effetti visivi più sofisticati, pur nel rispetto del proprio DNA Material Design. Il 2026 potrebbe segnare l’inizio di una nuova era estetica per gli smartphone Android.

OPPO potrebbe presto presentare un dispositivo fuori dagli schemi: il Reno X, uno smartphone con un rapporto d’aspetto 16:10 — decisamente più largo del normale — pensato per offrire un’esperienza visiva simile a quella di un pieghevole, ma con un corpo rigido tradizionale. Un’idea originale in un mercato che sembra seguire sempre gli stessi percorsi.

Un formato insolito per uno schermo da 6,39 pollici

Il display da 6,39 pollici del Reno X sarebbe decisamente più largo rispetto agli smartphone attuali, con dimensioni fisiche di circa 143 x 91 mm. Un telefono quasi quadrato, insomma, che strizza l’occhio ai tablet mini e ai device multimedia. L’obiettivo dichiarato è ottenere un’area video più ampia senza ricorrere a cerniere o meccanismi pieghevoli — con tutto ciò che comporta in termini di costo e fragilità.

Specifiche da flagship: Dimensity top, 7000 mAh e tele periscopico

Sotto la scocca ci sarebbe un chipset Dimensity di fascia alta (probabilmente la serie 9), abbinato a una batteria da ben 7000 mAh. Il comparto fotografico non delude: tripla fotocamera con sensore principale da 50 MP e teleobiettivo periscopico per un elevato zoom ottico. Una configurazione da smartphone serio, non da semplice esperimento di design.

Possibile debutto insieme ai nuovi Find di OPPO

Secondo le indiscrezioni, il Reno X potrebbe essere presentato insieme alla prossima generazione di Find Series, il che suggerirebbe un posizionamento premium anche nella comunicazione di lancio. Per ora si tratta ancora di un progetto in fase di sviluppo, con specifiche non definitive. Ma l’idea di base — grande schermo senza piegarsi — è abbastanza intrigante da tenere d’occhio.

Omarchy è una distribuzione GNU/Linux basata su Arch Linux, pensata per offrire un’esperienza preconfigurata e ottimizzata sia per utenti avanzati che per sviluppatori. Omarchy si distingue per l’integrazione di un ambiente desktop basato su Hyprland, un window manager tiling (finestre affiancate)...

🔗 Leggi il post completo

Per anni, i progressi nel gioco sui sistemi GNU/Linux sono stati possibili grazie a Wine, uno strato di traduzione che permette ai giochi progettati per Windows di funzionare su sistemi GNU/Linux. Wine (acronimo ricorsivo...

🔗 Leggi il post completo

Anche se potrebbe essere molto facile attribuire un contesto politico all'attacco subito dall'azienda madre di Ubuntu, la realtà è, come spesso accade in questi casi, molto più banale. Tutti i dettagli portano infatti "semplicemente" verso un gruppo di ladri che vuole ricattare un'azienda.

🔗 Leggi il post completo