Hi Domenic, The TAG acknowledges the interest from implementers and developers in enabling web applications to integrate with generative models through prompting. However, we have significant concerns about the current level of specification detail and its implications for interoperability, security, and long-term sustainability of the platform. We believe the following concerns apply equally to the Writing Assistance APIs, which share many of the same underlying assumptions/models.

Despite what is mandated in the explainer, we have a concern that local models won't meet user and developer and result expectations, and could be severely limited on low-end devices. This problem could get worse over time, as users/developers become increasingly accustomed to crafting extremely complex prompts by today's standards. And if it's just too presumptuous to assume local models will stay "local", given the trend towards hybrid models that send off complicated prompts to servers (even in a privacy preserving way). As noted in the explainer:

“We do not intend to provide guarantees of language model quality, stability, or interoperability between browsers. ... These are left as quality-of-implementation issues.”
— Explainer: Goals

This is a notable departure on the web platform, where developers expect baseline interoperable behavior across user agents. At present, the API lacks a minimal interoperable model contract, has no reliable capability detection or quality signals, and makes assumptions (such as on-device execution or reliable structured output) that cannot be guaranteed across implementations. And given that models do computational work, there's a real threat of distributed computation abuse by exploiting this local computational resource at scale at the cost of users (i.e., answering other people's prompts on a user's device without the user knowing).

We believe further work is needed, particularly in defining testable guarantees, privacy, security, and data governance requirements, and an architectural fit with other emerging platform capabilities, before something like this should become part of the Web platform.

Detailed concerns:

1. Interoperability & Testability

• No shared baseline: As acknowledged in the explainer, the API does not guarantee any consistent model behavior or quality across browsers. This undermines interoperability and prevents developers from writing portable, testable code.
• Opaque model selection: There is no defined way for developers to know what model is in use, making debugging and conformance testing infeasible and errors often impossible to reproduce.

2. Architecture & Web Principles

• Procedural and nondeterministic: The API departs from predictable, repeatable behavior, though we acknowledge that in some context this might not matter.
• Difficult to polyfill: The explainer leaves open whether fallback to wasm/cloud models is even viable. In practice, the lack of standard behavior makes polyfilling impractical (again, because there is no real baseline - it's just whatever media the model gives developers back).
• Threat model missing: Security concerns such as prompt injection, history leakage, and cross-origin contamination are not clearly addressed.

3. Assumptions That May Not Hold

• On-device vs remote execution: The explainer lists "execution location transparency" as a possible future goal, but not a guarantee:

  “It may be desirable to offer more insight into whether a model is executing locally or remotely (e.g. to inform UX or data governance decisions).”
  — README.md § Goals: Execution location transparency

• Structured output is unreliable: While structured outputs are discussed as desirable, they are not required (making this a risky feature that could negatively impact users and their ability even use a web page):

  “Language models are not guaranteed to produce structurally valid results; efforts to constrain output structure using techniques like prompt templating may be employed...”
  — README.md § Prompt lifecycle

• “Tools” abstraction: No such abstraction is described in the explainer. We have concerns about this proposal being overly tied to vendor-specific use cases.

4. Privacy & Security

• Data governance can be challenging: The explainer notes that training on user data must be prevented, but, even if not used for training, the data is could be stored, transmitted, or retained. This might not be possible because the prompt may be handed off to a service that that does retain data or train the model by default (or by ULA) - or the model has been pre-tuned on purpose by the users.

  “The platform MUST prevent user input from being used to fine-tune models or otherwise persist and train on user prompts.”
  — Security & Privacy Questionnaire

  However, there is no mention of how this is enforced, nor of retention policies, which remains a concern.

• Potential for computation abuse: There are no guardrails discussed around background or opportunistic use of models, which could lead to battery or CPU exhaustion similar to past abuses (e.g. crypto-mining).

• Fingerprinting risk: Even through the explainer demands local model (again, no guaranteed), prompt content can encode sensitive user data or preferences, introducing new unintentional vectors for surveillance or tracking.

5. Developer Experience & UX

• Inconsistent outputs: Developers cannot expect uniform results across UAs due to model divergence.
• No quality signals: There is no standard mechanism to detect hallucinations or confidence levels.
• No schema support: Inputs and outputs remain freeform text, which makes robust integration difficult.

6. Ecosystem & Governance

• Lack of accountability: With no shared test suite or conformance requirements, there is no path for developers to hold implementations to a common standard.
• Unclear relationship to adjacent specs: The explainer does not clarify how this proposal relates to WebNN, WebGPU, or potential future APIs for structured model execution.

We encourage continued exploration of this space, but recommend the following before the API progresses further:

1. Define a minimal, testable capability baseline that all conforming implementations must meet.
2. Provide reliable capability detection and developer-facing signals for output quality or confidence.
3. Establish a clear threat model and data governance framework, including retention and training boundaries.
4. Clarify the API’s relationship with adjacent emerging capabilities and ensure it fits within the layered architecture of the web platform.
5. Propose some means to prevent distributed abuse of this computational resource.

The TAG would welcome re-review as these aspects evolve.

Thank you for your feedback. However, your review has several inaccuracies, and most of the parts that are accurate are repeating the same point about nondeterministic outputs.

Here are some specific points:

• Threat model missing: Security concerns such as prompt injection, history leakage, and cross-origin contamination are not clearly addressed.

I think this is not correct. https://webmachinelearning.github.io/writing-assistance-apis/#privacy is quite detailed, including https://webmachinelearning.github.io/writing-assistance-apis/#privacy-user-input which covers your "history leakage" and "cross-origin contamination". "Prompt injection" is not a concern here since the prompts are supplied directly by the developer; there is no API provided for allowing users or uncontrolled web content to inject prompts into otherwise developer-controlled sessions.

You state

• However, there is no mention of how this is enforced, nor of retention policies, which remains a concern.

But I don't think this makes sense. (Perhaps it was generated by an LLM?) It's quite simple how to enforce not feeding data into a model that the developer didn't request; simply don't do it. I don't know what type of specification you are expecting here, beyond what already exists.

Similarly, the idea of "retention policy" is nonsensical, when there is in fact no data retained (as explained in the S&P questionnaire and mandated in the specification). For the model itself, there is extensive discussion of retention, e.g. in https://webmachinelearning.github.io/writing-assistance-apis/#privacy-availability-eviction and elsewhere.

• Structured output is unreliable: While structured outputs are discussed as desirable, they are not required (making this a risky feature that could negatively impact users and their ability even use a web page): > “Language models are not guaranteed to produce structurally valid results; efforts to constrain output structure using techniques like prompt templating may be employed...” > — README.md § Prompt lifecycle

This appears to be a hallucination in whatever AI you are using to write this TAG review, as that text does not appear anywhere and neither does the anchor it links to. Structured outputs are in fact required; see their dedicated section: https://github.com/webmachinelearning/prompt-api/blob/main/README.md#structured-output-with-json-schema-or-regexp-constraints .

• On-device vs remote execution: The explainer lists "execution location transparency" as a possible future goal, but not a guarantee: > “It may be desirable to offer more insight into whether a model is executing locally or remotely (e.g. to inform UX or data governance decisions).” > — README.md § Goals: Execution location transparency

Similarly a hallucination. The API is in fact designed to allow "execution location transparency", as you put it. The closest text in the goals section is actually debating whether or not we should pierce transparency, by exposing to developers where the model is running. (With the tentative conclusion that we should instead preserve transparency and not expose this information.)

• Potential for computation abuse: There are no guardrails discussed around background or opportunistic use of models, which could lead to battery or CPU exhaustion similar to past abuses (e.g. crypto-mining).

This is false. See https://webmachinelearning.github.io/writing-assistance-apis/#security-runtime .

• Fingerprinting risk: Even through the explainer demands local model (again, no guaranteed), prompt content can encode sensitive user data or preferences, introducing new unintentional vectors for surveillance or tracking.

This is false. Prompt content is not retained.

• No schema support: Inputs and outputs remain freeform text, which makes robust integration difficult.

This is false, as explained in https://github.com/webmachinelearning/prompt-api/blob/main/README.md#structured-output-with-json-schema-or-regexp-constraints .

• Lack of accountability: With no shared test suite or conformance requirements, there is no path for developers to hold implementations to a common standard.

We are developing a shared test suite, some of which is already available on wpt.fyi.

• Unclear relationship to adjacent specs: The explainer does not clarify how this proposal relates to WebNN, WebGPU, or potential future APIs for structured model execution.

Although in theory we could expand this more, it's worth noting that it is discussed, e.g. in https://github.com/webmachinelearning/prompt-api/blob/main/README.md#execution-location-transparency:~:text=Currently%2C%20web%20developers%20wishing%20to%20use%20language%20models%20must%20either%20call%20out%20to%20cloud%20APIs%2C%20or%20bring%20their%20own%20and%20run%20them%20using%20technologies%20like%20WebAssembly%20and%20WebGPU .

Hi @domenic, We've seen your response and have reopened the issue. We'll discuss how to address this at our plenary in 12 hours.

Hi @domenic,

We reviewed the situation in our plenary this morning and we accept full responsibility for this oversight. We're sorry for not giving a thorough, accurate and considered review of the Prompt API. Moving forward we will be re-reviewing the proposed design, the issue will remain open while we do so and we rescind our previous resolution. Please bear with us in the meantime.