Mozilla contro la Prompt API di Chrome: perché la scelta pesa sul Web

L’idea di portare capacità di generazione linguistica direttamente nelle API del browser ha iniziato a circolare con più insistenza a partire dal 2023, quando i grandi vendor hanno accelerato sull’integrazione di modelli locali e servizi di inferenza. La cosiddetta Prompt API, già integrata in Google Chrome, nasce proprio da questa spinta: offrire agli sviluppatori Web un’interfaccia standard per inviare prompt a modelli linguistici integrati nel browser o disponibili localmente (Gemini Nano, nel caso di Chrome). Il dibattito, però, si è acceso rapidamente; non tanto sulla fattibilità tecnica, quanto sulle conseguenze a lungo termine.

In passato, ogni tentativo di standardizzare funzionalità fortemente dipendenti da implementazioni specifiche ha prodotto frammentazione. Qui il rischio appare ancora più marcato: i Large Language Models (LLM) non sono equivalenti tra loro e, soprattutto, non si comportano in modo uniforme a parità di input.

Come funziona la Prompt API e cosa promette

L’API proposta si basa su un’astrazione semplice: lo sviluppatore invoca un oggetto di tipo LanguageModel e invia una stringa di input tramite un metodo come prompt(). In teoria, il browser dovrebbe occuparsi del resto: selezione del modello, gestione dell’inferenza, restituzione della risposta attesa.

Un browser potrebbe integrare un modello ottimizzato per dispositivi locali, mentre un altro potrebbe delegare a un modello completamente diverso. Il risultato è che lo stesso prompt produce output divergenti.

Chi lavora quotidianamente con i modelli generativi AI lo sa bene: il comportamento dipende da dettagli sottili. La formulazione del system prompt, la lunghezza del contesto, i parametri di sampling come temperatura e top-p influenzano il risultato in modo significativo. Standardizzare solo la chiamata API senza intervenire su questi aspetti equivale a lasciare ampie zone di ambiguità.

Le valutazioni di Mozilla: prudenza e approccio sperimentale

Tra le voci più critiche emerge quella di Mozilla, che ha espresso una posizione chiaramente negativa rispetto alla proposta nella sua forma attuale puntando il dito proprio contro Chrome.

Il primo punto sollevato riguarda la forma stessa dell’API. Secondo Mozilla, l’astrazione proposta ha una certa utilità, ma tende a incentivare comportamenti dipendenti dal modello: invece di favorire codice portabile, spinge gli sviluppatori a ottimizzare per specifiche implementazioni. Il risultato è un aumento concreto dei rischi legati all’interoperabilità.

Uno sviluppatore che lavora su Edge potrebbe progettare il proprio flusso attorno a un modello come Phi-4-mini, sfruttandone peculiarità e limiti. Lo stesso codice, eseguito su un altro browser con un modello differente, potrebbe produrre risultati inferiori o imprevedibili. Mozilla evidenzia come questo scenario porti inevitabilmente a esperienze incoerenti.

Un altro elemento centrale nella valutazione riguarda il livello di maturità della tecnologia. Mozilla sottolinea che i modelli linguistici sono sempre in rapido movimento: architetture, tecniche di inferenza e parametri evolvono continuamente. Standardizzare un’API in questa fase significa fissare dettagli che potrebbero diventare obsoleti nel giro di pochi mesi.

Per questo motivo, la raccomandazione è chiara: serve più sperimentazione fuori dalla piattaforma Web standard. L’indicazione è di lavorare in userland, cioè attraverso strumenti che non richiedono un consenso tra tutti i browser.

Il problema della dipendenza dal modello

Una criticità emersa con forza riguarda la tendenza degli sviluppatori ad adattare i prompt al comportamento specifico di un modello. In fase di sviluppo, si iterano i prompt fino a ottenere un output soddisfacente.

Un prompt progettato per un modello Google potrebbe produrre risultati mediocri su un modello Apple o Mozilla. Per evitare comportamenti indesiderati, quindi, lo sviluppatore finisce per identificare il modello in uso e modificare dinamicamente il comportamento dell’applicazione. Un esempio realistico:

const modelType = await model.prompt('identify yourself');

Prompt diversi per modelli diversi, insomma, oppure blocco totale per i modelli non riconosciuti. Il risultato ricorda da vicino le pratiche dei primi anni 2000, quando si scriveva codice specifico per Internet Explorer o Firefox. Ma una simile deriva compromette uno dei principi fondamentali del web: la neutralità della piattaforma.

Estensioni come terreno di prova

Mozilla propone un’alternativa concreta: utilizzare estensioni del browser per esporre funzionalità simili a quelle della Prompt API. In questo modello, un’estensione può offrire un’interfaccia di tipo Prompt, ma con maggiore controllo da parte dello sviluppatore.

Uno degli aspetti più interessanti è la possibilità di selezionare esplicitamente il modello da un repository o model hub. È uno schema che evita la scelta del modello da parte del singolo browser e che permette di adattare l’applicazione a casi d’uso specifici.

Installare un’estensione implica uscire dal perimetro delle funzionalità standard; significa accettare, in modo più consapevole, implicazioni come l’uso di storage condiviso o l’esecuzione di modelli locali.

Una posizione netta ma non definitiva

La valutazione negativa di Mozilla non chiude la porta alla Prompt API, ma ne evidenzia i limiti attuali. Il messaggio è che la standardizzazione deve arrivare dopo una fase di sperimentazione più ampia e concreta.

Il punto è che la tecnologia dei modelli linguistici non ha ancora raggiunto un livello di stabilità comparabile ad altre componenti della piattaforma web. Forzare un’API in questa fase rischia di creare più problemi di quanti ne risolva.

Oltretutto, si spiega ancora da Mozilla, con l’attuale Prompt AI gli sviluppatori non hanno facoltà di gestire parametri critici come dimensione del contesto, token limit o strategie di sampling. La fondazione osserva che queste caratteristiche non sono dettagli secondari, ma elementi fondamentali per costruire applicazioni affidabili.