Nelle API di OpenAI lo streaming delle risposte porta con sé un campo extra pieno di caratteri casuali. Si chiama obfuscation, è attivo di default e si controlla con il parametro include_obfuscation dentro stream_options.
La documentazione ufficiale spiega il meccanismo. L’offuscamento aggiunge caratteri casuali a un campo dedicato negli eventi delta dello streaming, così da uniformare la dimensione dei pacchetti. Serve a mitigare certi attacchi a canale laterale. Il costo è un piccolo sovraccarico di dati. Chi si fida dei collegamenti di rete tra la propria applicazione e le API può impostare il parametro a false e risparmiare banda.
Il problema che questa misura affronta è concreto. Anche con il traffico cifrato, la dimensione di ogni pacchetto in streaming può rivelare la lunghezza del token trasmesso. Da lì un osservatore sulla rete può ricostruire indizi sul contenuto della conversazione. Secondo una pull request del progetto vLLM, OpenAI, Microsoft, Mistral e xAI hanno adottato questa contromisura per il canale laterale noto come Whisper Leak. Nei test descritti nella stessa pull request, i pacchetti senza padding mostravano da 6 a 11 dimensioni distinte per flusso. Con il padding ne restava una sola, perché il payload JSON viene arrotondato a un multiplo di 128 byte.
Per gli sviluppatori ci sono effetti pratici. Su Chat Completions il parametro funziona nello streaming normale. Sulle Responses API, secondo una discussione della community OpenAI, compare solo come parametro di query quando si recupera in streaming una risposta già salvata. Nella POST con streaming standard la chiave arriva comunque. Intanto nel repository openai-dotnet c’è una richiesta aperta per aggiungere l’opzione tra i campi di CreateResponseOptions, utile in particolare su Azure OpenAI e Azure Foundry, dove il valore predefinito è true.
La compatibilità con gli altri provider è un secondo fronte. Un progetto open source in Rust inviava a tutti gli endpoint include_usage true e include_obfuscation false. Fireworks, BaseTen e vLLM, che espongono interfacce compatibili con OpenAI, rifiutavano la chiave sconosciuta con un errore HTTP 400. Alcuni host mostravano il guasto come una risposta vuota con finish_reason stop, indistinguibile da un successo. Gli autori hanno tolto il campo. Il prezzo è che il traffico diretto verso OpenAI può ora trasportare il padding, perché l’API lo include di default. Per l’utente finale non cambia nulla di visibile.
La scelta, per chi sviluppa, dipende dal punto in cui passa il traffico. Su reti interne controllate, disattivare l’offuscamento libera un po’ di banda. Su connessioni pubbliche, soprattutto con dati sensibili nei prompt, lasciare il default è la scelta prudente. Il fatto che vLLM stia aggiungendo il supporto, con un’opzione di server disattivata di base, indica che l’offuscamento si sta diffondendo anche fuori dall’ambiente OpenAI.
