Mozilla has reiterated strong opposition to Google’s proposed Prompt API for Chrome, warning that it could fragment the web, lock developers into model-specific behavior, and introduce problematic policy enforcement at the browser level.
The Prompt API aims to provide web developers with direct access to on-device AI models for tasks like summarization, rewriting, and conversational interactions, without relying on external cloud services. Google positions it as a step toward more capable, privacy-preserving web applications. Critics, however, see it as a premature standardization effort that could entrench a single vendor’s ecosystem and introduce new layers of complexity and risk.
The discussion was sparked by Google Chrome engineer Mike Wasserman, who encouraged continued experimentation and engagement with standards around the Prompt API despite lingering criticism. Wasserman pointed to ongoing interoperability discussions and early-stage testing, asking participants to share insights from a year of experimentation with AI-powered web extensions.
Mozilla’s Jake Archibald responded with a detailed rebuttal, arguing that the API poses “severe negative consequences” for interoperability, model neutrality, and long-term web compatibility. Archibald explained that developers naturally tailor system prompts to the quirks of specific AI models, creating a risk that websites become optimized for a single vendor’s implementation. Over time, this could discourage adoption of competing models, even superior ones, because they would produce inconsistent or degraded results when paired with prompts tuned for another system.
He illustrated the issue with a practical example involving tone adjustments in generated speech, where small prompt tweaks were needed to correct model-specific behavior. Such fine-tuning, Archibald argued, would not generalize across models, leading developers to detect and target specific AI engines. This, in turn, risks reviving browser-specific branching practices reminiscent of the early 2000s, when websites behaved differently depending on the user agent.
Archibald also raised concerns about Google’s Generative AI Prohibited Uses Policy, which developers must accept when using the API. He noted that some restrictions, such as bans on generating certain categories of content or “misleading” information, extend beyond legal requirements and could create uncertainty about liability. In scenarios where user-generated content is processed by the browser’s AI, it remains unclear whether responsibility would fall on the user, the website operator, or the model provider. To mitigate risk, developers may again resort to identifying the underlying model and restricting functionality, further undermining interoperability.
Mozilla additionally challenged Google’s claim of strong developer support, arguing that the cited evidence, limited forum posts, a small survey, and outdated references, does not substantiate broad enthusiasm for the API.
Apple echoed similar concerns through WebKit lead Maciej Stachowiak, who warned of a “calcification” effect where websites become dependent on the quirks of a single model, potentially Google’s. He questioned what mitigation strategies would be available if such fragmentation occurs, suggesting that waiting for real-world harm without a clear remediation plan is risky. Potential responses, such as breaking compatibility or rotating models, could themselves introduce instability.
Google’s Rick Byers acknowledged the risks but argued that inaction carries its own cost. He suggested that failing to support “agentic computing” on the web could push users and businesses toward closed ecosystems, such as chatbot-driven super apps, reducing the web’s relevance. Byers added that, if necessary, Chrome could take corrective action, such as deliberately breaking model-specific quirks, to preserve interoperability, citing past instances where Chromium addressed compatibility issues even at the cost of temporarily breaking major services.
Former Google engineer Domenic Denicola, who previously worked on the Prompt API design, expressed sympathy for Mozilla’s concerns while still supporting Chromium’s decision to move forward. Writing in a Hacker News discussion, Denicola argued that developers are likely to treat the API as a progressive enhancement rather than a hard dependency, and that model diversity across browsers could naturally encourage more portable implementations. However, he agreed that Chrome’s usage policy requirements are ill-suited for a web API and unlikely to be enforceable in practice.
Leave a Reply