(in)sicurezza digitale

2026-05-12 14:32:22

Il primo zero-day costruito con l’AI: Google sventava un attacco di massa con exploit generato da LLM

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.

Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access | Google Cloud Blog

Explore GTIG's 2026 report on how adversaries leverage AI for zero-day exploits, autonomous malware, and industrial-scale cyber operations.

^{Google Threat Intelligence Group (Google Cloud Blog)}

Spcnet.it

2026-05-11 17:15:53

Copilot Studio accelera con .NET 10 su WebAssembly: fingerprinting automatico e AOT ottimizzato

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

Copilot Studio gets faster with .NET 10 on WebAssembly - .NET Blog

Microsoft Copilot Studio recently upgraded its .NET WebAssembly engine to .NET 10. The migration was straightforward, simplified deployment, and delivered another round of meaningful performance gains for end users.

^{Daniel Roth (.NET Blog)}

Spcnet.it

2026-05-11 16:15:22

Durable Workflows nel Microsoft Agent Framework: da console app ad Azure Functions

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}.");
    }
}

I parametri di tipo definiscono il contratto: TInput è ciò che riceve dal passo precedente, TOutput è ciò che passa al passo successivo. Il framework verifica la compatibilità dei tipi a compile time.

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}");
}

Bastano i pacchetti NuGet Microsoft.Agents.AI e Microsoft.Agents.AI.Workflows. Nessuna infrastruttura, nessun Docker, solo una console app .NET.

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

Il runtime durable fornisce:

• 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}");

Per lo sviluppo locale si avvia il DTS Emulator in Docker:

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

La dashboard è disponibile su http://localhost:8082 e mostra la timeline di ogni executor, gli input/output per ciascun step e lo stato delle esecuzioni.

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();

Con il runtime durable, il fisico potrebbe eseguire su una VM e il chimico su un’altra. Se il processo si riavvia a metà esecuzione, gli agenti già completati non vengono rieseguiti grazie al checkpointing.

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

Durable Workflows in the Microsoft Agent Framework - .NET Blog

Build durable AI agent workflows with the Microsoft Agent Framework. Define once, run in-process or on Azure Functions with serverless scaling and durability.

^{Shyju Krishnankutty (.NET Blog)}

Fedimedia Italia APS - Web

2026-03-30 17:14:11

Fedimedia firma la lettera aperta per Mantenere Android Libero, unisciti alla battaglia “keep android open” per liberare lo smartphone

Oggi il controllo degli smartphone è sempre più concentrato nelle mani di poche grandi aziende. Anche un sistema che nasce libero come Android rischia di essere progressivamente chiuso, regolato e trasformato in uno strumento sotto controllo centralizzato, ma qualcosa si sta muovendo.

Fedimedia Italia APS è parte attiva del movimento internazionale keep android open che non si limita a denunciare, ma lavora concretamente insieme ad alcune delle più importanti realtà del mondo open source e del free software per difendere un futuro digitale libero, aperto e decentralizzato ed è fra i firmatari della lettera aperta a google per mantenere l’ecosistema android aperto.

Per questa campagna abbiamo attivato un banner in alto con un conto alla rovescia: il tempo che resta a un Android davvero libero. Un segnale chiaro per sensibilizzare tutte le persone su quanto sta accadendo e sull’urgenza di non restare a guardare.

👉 Se credi anche tu che la tecnologia debba essere al servizio delle persone e non il contrario puoi fare un passo concreto:

Sostieni Fedimedia e partecipa al movimento per la liberazione della tecnologia. Bastano pochi secondi per lasciare il tuo interesse tramite il modulo di contatto. e venire aggiornato sulle azioni intraprese da fedimedia e dal movimento Keep Android Open.

La lettera che abbiamo indirizzato al movimento Keep Android Open

Gentili promotori della campagna KeepAndroidOpen,

con grande interesse e condivisione dei valori espressi nella vostra lettera aperta a Google, scriviamo per aderire ufficialmente alla vostra iniziativa in difesa di un Android libero, aperto e indipendente da controlli centralizzati.

Fedimedia Italia APS nasce per promuovere unecosistema digitale basato su principi di libertà, decentralizzazione e sovranità tecnologica. Come associazione che si batte per un web etico e indipendente dalle Big Tech, non possiamo che sostenere con forza la vostra opposizione alla registrazione obbligatoria degli sviluppatori.

Perchè non dovrebbero vincolare lo sviluppo di app su qualsiasi dispositivo ?

Ci piace pensare ad Android come a una tela di pittore, ai dispositivi come a pennelli e alle app come a colori: chi produce gli strumenti non può pretendere di controllare l’arte che ne scaturisce, né tantomeno imporre agli artisti di registrarsi presso un unico fornitore per poter creare.

La libertà di espressione digitale, proprio come quella artistica, non può essere soggetta a permessi o a gatekeeper. Imporre una registrazione centralizzata significa trasformare una piattaforma aperta in un sistema chiuso a chi non autorizzato da voi, dove la creatività e l’innovazione sono ostaggi di regole arbitrarie e di interessi commerciali.

Per noi, la decentralizzazione e l’apertura non sono solo scelte tecniche, ma valori fondanti: ogni sviluppatore, ogni utente, ogni comunità deve poter operare senza dover chiedere il permesso a un’unica autorità. La vostra battaglia è anche la nostra, perché difendere Android significa difendere il diritto di tutti a un futuro digitale pluralista, trasparente e rispettoso dei diritti fondamentali.

Con questa email, vi comunichiamo quindi la nostra piena adesione alla campagna KeepAndroidOpen. Siamo pronti a sostenervi nella diffusione dei vostri obiettivi, a partecipare attivamente alle iniziative promosse e a collaborare per costruire alternative concrete che preservino la libertà e l’apertura di Android, valori che condividiamo profondamente.

Rimaniamo a disposizione per qualsiasi ulteriore passo o azione collettiva.

Cordiali saluti,
Fedimedia Italia APS

Qui di seguito la lettera aperta indirizzata ai vertici di Google

Questa è la traduzione della lettera aperta a Google indirizzata ai fondatori, CEO e dirigenti Google

Dat</code><code>a</code><code>:</code><code> </code><code>24 febbraio</code><code> 2026</code><code>A</code><code>:</code><code> </code><code>Sundar Pichai, Chief Executive Officer, Google</code><code>A</code><code>:</code><code> </code><code>Sergey Brin, Founder and Board Member, Google</code><code>A</code><code>:</code><code> </code><code>Larry Page, Founder and Board Member, Google</code><code>A</code><code>: Vijaya Kaza, General Manager for App & Ecosystem Trust, Google</code><code>CC:</code><code> </code><code>Regulatory authorities, policymakers, and the Android developer community</code><code>Re:</code><code> </code><code>Mandatory Developer Registration for Android App Distribution

---

Noi, le organizzazioni sottoscritte che rappresentano la società civile, le istituzioni no-profit e le aziende tecnologiche, scriviamo per esprimere la nostra ferma opposizione alla politica annunciata da Google, che richiede a tutti gli sviluppatori di app Android di registrarsi in maniera centralizzata presso Google per poter distribuire applicazioni al di fuori del Google Play Store e che entrerà in vigore in tutto il mondo nei prossimi mesi.

Pur riconoscendo l’importanza della sicurezza della piattaforma e della sicurezza degli utenti, la piattaforma Android include già diversi meccanismi di sicurezza che non richiedono una registrazione centralizzata. Iniettare forzatamente un modello di sicurezza estraneo, in contrasto con la storica natura aperta di Android, minaccia l’innovazione, la concorrenza, la privacy e la libertà degli utenti. Esortiamo Google a ritirare questa policy e a collaborare con le comunità open source e della sicurezza per trovare alternative meno restrittive.

Le nostre preoccupazioni

1. Controllo oltre lo Store di Google

Android è storicamente caratterizzato come una piattaforma aperta in cui utenti e sviluppatori possono operare indipendentemente dai servizi di Google. La politica di registrazione degli sviluppatori proposta modifica radicalmente tale rapporto, richiedendo agli sviluppatori che desiderano distribuire app tramite canali alternativi (i propri siti web, app store di terze parti, sistemi di distribuzione aziendali o trasferimenti diretti) di richiedere prima l’autorizzazione a Google attraverso una procedura di verifica obbligatoria, che prevede l’accettazione dei termini e delle condizioni di Google, il pagamento di una quota e il caricamento di un documento di identità rilasciato dal governo.

Ciò estende l’autorità di controllo di Google oltre il proprio marketplace, estendendola a canali di distribuzione in cui non ha alcun ruolo operativo legittimo. Gli sviluppatori che scelgono di non utilizzare i servizi di Google non dovrebbero essere costretti a registrarsi e a sottoporsi al giudizio di Google. Centralizzare la registrazione di tutte le applicazioni a livello mondiale conferisce inoltre a Google nuovi poteri per disattivare completamente qualsiasi app desideri, per qualsiasi motivo, per l’intero ecosistema Android.

2. Barriera all’ingresso e ostacolo all’innovazione

La registrazione obbligatoria crea ostacoli e barriere all’ingresso, in particolare per:

• Gli sviluppatori individuali e i piccoli team con risorse limitate
• I progetti open source che si basano su collaboratori volontari
• Gli sviluppatori in aree geografiche con accesso limitato all’infrastruttura di registrazione di Google
• Gli sviluppatori focalizzati sulla privacy che evitano gli ecosistemi di sorveglianza
• La risposta alle emergenze e le organizzazioni umanitarie che richiedono un rapido intervento
• Gli attivisti che lavorano per la libertà di Internet in paesi che criminalizzano ingiustamente tale lavoro
• Gli sviluppatori in paesi o aree in cui Google non può consentire loro di registrarsi a causa di sanzioni
• I ricercatori e gli accademici che sviluppano applicazioni sperimentali
• Le applicazioni aziendali e governative interne che non sono mai state pensate per un’ampia distribuzione pubblica

Ogni ulteriore ostacolo burocratico riduce la diversità nell’ecosistema software e concentra il potere nelle mani di grandi attori affermati che possono assorbire più facilmente tali costi di conformità.

3. Problemi di privacy e sorveglianza

Richiedere la registrazione a Google crea un database completo di tutti gli sviluppatori Android, indipendentemente dal fatto che utilizzino o meno i servizi Google. Ciò solleva seri interrogativi su:

• Quali informazioni personali devono fornire gli sviluppatori
• Come queste informazioni saranno archiviate, protette e utilizzate
• La possibilità che questi dati possano essere soggetti a richieste governative o procedimenti legali
• La modalità con cui l’attività degli sviluppatori possa essere monitorata nell’intero ecosistema
• L’impatto che comporta per gli sviluppatori che lavorano su applicazioni che tutelano la privacy o che sono politicamente sensibili

Gli sviluppatori dovrebbero avere il diritto di creare e distribuire software senza sottoporsi a inutili controlli o sorveglianza.

4. Rischi di applicazione arbitraria e chiusura dell’account

Gli attuali processi di revisione delle app di Google sono stati criticati per la scarsa trasparenza del processo decisionale, l’applicazione incoerente delle norme e i meccanismi di ricorso limitati. L’estensione di questo sistema a tutti i dispositivi certificati Android comporta i seguenti rischi:

• Rifiuto arbitrario o sospensione senza chiara giustificazione
• Sistemi automatizzati che prendono decisioni consequenziali con una supervisione umana insufficiente
• Sviluppatori che perdono la possibilità di distribuire app su tutti i canali a causa di una singola decisione aziendale non verificabile
• Considerazioni politiche o competitive che influenzano l’approvazione della registrazione
• Impatto sproporzionato sulle comunità emarginate e applicazioni controverse ma legali

Un singolo punto di vulnerabilità controllato da una sola azienda è l’antitesi di un ecosistema software sano e competitivo.

5. Implicazioni anticoncorrenziali

Questo requisito consente a Google di raccogliere informazioni su tutte le attività di sviluppo Android, tra cui:

• Quali app vengono sviluppate e da chi
• Le strategie di distribuzione e modelli di business alternativi
• Le minacce competitive ai servizi di Google
• Le tendenze di mercato e preferenze degli utenti al di fuori dell’ecosistema di Google

Questa asimmetria informativa fornisce a Google notevoli vantaggi competitivi, le consente di anticipare, copiare e indebolire prodotti e servizi concorrenti e potrebbe sollevare numerose questioni in materia di antitrust.

6. Problemi normativi

Le autorità di regolamentazione di tutto il mondo, tra cui la Commissione Europea, il Dipartimento di Giustizia degli Stati Uniti e le autorità garanti della concorrenza in diverse giurisdizioni, hanno esaminato con sempre maggiore attenzione la capacità delle piattaforme dominanti di privilegiare i propri servizi e limitare la concorrenza, richiedendo maggiore apertura e interoperabilità. Notiamo inoltre crescenti preoccupazioni circa l’intervento normativo che aumenta la sorveglianza di massa, ostacolando la libertà del software, l’apertura di Internet e la neutralità dei dispositivi.

Invitiamo Google a trovare modi alternativi per conformarsi agli obblighi normativi, promuovendo modelli che rispettino la natura aperta di Android senza aumentare il controllo dei gatekeeper sulla piattaforma.

Le misure esistenti sono sufficienti

La piattaforma Android include già diversi meccanismi di sicurezza che non richiedono la registrazione centrale:

• Funzionalità di sicurezza a livello di sistema operativo, sandbox delle applicazioni e sistemi di autorizzazione
• Avvisi utente per le applicazioni installate direttamente (o “sideloaded”)
• Google Play Protect (che gli utenti possono scegliere di abilitare o disabilitare)
• Certificati di firma dello sviluppatore che stabiliscono la provenienza del software

Non è stata presentata alcuna prova che queste misure di sicurezza siano insufficienti a continuare a proteggere gli utenti Android come hanno fatto per tutti i diciassette anni di esistenza di Android. Se la preoccupazione di Google è realmente la sicurezza piuttosto che il controllo, dovrebbe investire nel miglioramento di questi meccanismi esistenti anziché creare nuovi colli di bottiglia e centralizzare il controllo.

La nostra petizione

Invitiamo Google a:

1. Abrogare immediatamenteil requisito obbligatorio di registrazione dello sviluppatore per la distribuzione a terze parti.
2. Avviare un dialogo trasparentecon la società civile, gli sviluppatori e gli enti regolatori sui miglioramenti della sicurezza Android, nel rispetto dell’apertura e della concorrenza.
3. Impegnarsi a favore della neutralità della piattaformaassicurando che Android rimanga una piattaforma realmente aperta in cui il ruolo di Google come fornitore della piattaforma non sia in conflitto con i suoi interessi commerciali.

Nel corso degli anni, Android si è evoluto in un’infrastruttura tecnologica fondamentale al servizio di centinaia di governi, milioni di aziende e miliardi di cittadini in tutto il mondo. Consolidare e centralizzare unilateralmente il potere di approvare il software nelle mani di un’unica azienda che può esimersi da una reale responsabilità e rendicontabilità è antitetico ai principi della libertà di pensiero, è un affronto al software libero, è una barriera insormontabile alla concorrenza ed è una minaccia universale alla sovranità digitale.

Imploriamo Google di invertire la rotta, porre fine al programma di verifica degli sviluppatori e iniziare a collaborare con la più ampia comunità degli sviluppatori per promuovere gli obiettivi di sicurezza senza sacrificare i principi di massima apertura in base ai quali è stato realizzato Android. La forza dell’ecosistema Android è storicamente basata sulla sua architettura aperta e Google deve impegnarsi per ripristinare il suo ruolo di fedele custode di tale fiducia.

Fedimedia Italia APS

Fedimedia Italia APS nasce per costruire un ecosistema digitale e sociale dove tecnologia, diritti e ambiente coesistono in armonia.

^{glowingmug (Fedimedia Italia APS - Web)}

Spcnet.it

2026-05-11 15:14:34

Kubernetes v1.36: Sharded List and Watch lato server per cluster ad alta scala

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')

L’API server calcola un hash FNV-1a a 64 bit deterministico del campo specificato e restituisce solo gli oggetti il cui hash ricade nell’intervallo [start, end). Questo vale sia per le risposte di list che per i flussi di eventi watch.

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
    }),
)

Per un deployment con 2 repliche, i selettori dividono lo spazio degli hash a metà:

// 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')"

Una singola replica può anche coprire range non contigui usando ||:

"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": [ ... ]
}

Se shardInfo è assente, il server non ha applicato il shard selector e il client ha ricevuto la collezione completa non filtrata. In questo caso, il client deve essere pronto a gestire il risultato completo — ad esempio applicando un filtraggio client-side per scartare gli oggetti fuori dal proprio shard.

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

Non è ancora consigliata per ambienti di produzione, ma rappresenta un’opportunità preziosa per i team che gestiscono cluster di grandi dimensioni di iniziare i test e fornire feedback al SIG API Machinery.

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

Kubernetes v1.36: Server-Side Sharded List and Watch

As Kubernetes clusters grow to tens of thousands of nodes, controllers that watch high-cardinality resources like Pods face a scaling wall.

^Kubernetes

Spcnet.it

2026-05-11 14:13:53

Costruire un MCP Server in C#: agenti AI con contesto reale usando il Model Context Protocol

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>

Il pacchetto ModelContextProtocol fornisce le API per creare server e client MCP, mentre l’integrazione con Microsoft.Extensions.AI consente di collegare i tool a modelli AI tramite le astrazioni standard di .NET.

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}";
}

L’attributo [Description] è fondamentale: il testo viene esposto all’agente AI come documentazione del tool, influenzando direttamente se e quando l’agente decide di invocarlo. Scrivete descrizioni chiare e precise.

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();

Il trasporto stdio è il più comune per server locali e per l’integrazione con VS Code. Per scenari più avanzati (server HTTP remoti, autenticazione OAuth) l’SDK supporta trasporti SSE e altri meccanismi.

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"
      ]
    }
  }
}

VS Code legge questo file e avvia automaticamente il server MCP quando necessario. I tool vengono esposti nella chat di GitHub Copilot con il prefisso #NomeServer.

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

Dall’Inspector potete connettervi al vostro server .NET, esplorare i tool esposti, invocarli con parametri di test e verificare le risposte JSON — tutto senza dover aprire VS Code.

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

Build & Leverage MCP Servers in C# for AI-Driven Development

Let's dive into how .NET developers can build MCP Servers and leverage them in AI workflows.

^{Sam Basu (Uno Platform)}