Intent to Extend Experiment : Writer API
Deepti Bogadi
Contact emails
kenji...@chromium.org, m...@chromium.org, ay...@chromium.org
Explainer
https://github.com/explainers-by-googlers/writing-assistance-apis/blob/main/README.md
Specification
https://webmachinelearning.github.io/writing-assistance-apis/#writer-api
Summary
The Writer API can be used for writing new material given a writing task prompt, backed by an on-device AI language model. Developers will be able to use this API to generate textual explanations of structured data, composing a post about a product based on reviews or product description, expanding on pro and con lists into full views and more. An enterprise policy (GenAILocalFoundationalModelSettings) is available to disable the underlying model downloading which will render the API unavailable.
Blink component
Blink > AI > Writing Assistance
Web Feature ID
No information provided
TAG review
https://github.com/w3ctag/design-reviews/issues/991
TAG review status
Pending
Origin Trial Name
Writer API
Chromium Trial Name
AIWriterAPI
Origin Trial documentation link
https://github.com/webmachinelearning/writing-assistance-apis/blob/main/README.md#writer-api
WebFeature UseCounter name
Writer_Create
Risks
Interoperability and Compatibility
This feature has definite interoperability and compatibility risks, due to the likelihood that different implementations will use different language models, prompts, and fine-tunings, and even within a single implementation such as Chrome, these pieces will likely change over time. Additionally, not all browsers and operating systems will have a built-in language model to expose, and not all devices will be powerful enough to run one effectively. We are taking a variety of steps to attempt to mitigate these risks. For example, the specification is designed to allow the API to be backed by a cloud-based language model. This approach could extend the functionality to a wider range of devices and users. The API is designed to abstract away the specifics of the underlying language model, including prompts and fine-tuning. This prevents developers from relying on specific outputs, ensuring they receive newly-written text rather than structured data that might vary across implementations. Finally, the API surface is designed with many clear points of failure, that encourage the developer to probe for capabilities ahead of time and fall back to other techniques if a capability is not available. Nevertheless, interoperability and compatibility risk remains high for these sorts of APIs, and we'll be closely monitoring it during the experiment period.
Gecko: Negative (https://github.com/mozilla/standards-positions/issues/1067)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/393)
Web developers: Mixed signals (https://github.com/WICG/proposals/issues/163) Prototyping with partners behind a flag revealed enthusiasm and many prototypes built, from which we drew the discussion of potential use cases [1]. Feedback on the WICG thread was more mixed. Some themes we saw include: asking for more capabilities (e.g. full prompting of a language model instead of higher-level APIs (our response at [2]); multi-modal support); desire to make sure the API actually works robustly in many real-world use cases; removal of any safety/ethical safeguards; and confusion about client-side vs. cloud APIs. [1]: https://github.com/WICG/writing-assistance-apis/blob/main/README.md#summarizer-api [2]: https://github.com/WICG/writing-assistance-apis/blob/main/README.md#directly-exposing-a-prompt-api
Other signals:
Activation
This feature would definitely benefit from having polyfills, backed by any of: cloud services, lazily-loaded client-side models using WebGPU, or the web developer's own server. We anticipate seeing an ecosystem of such polyfills grow as more developers experiment with this API.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No information provided
Goals for experimentation
Although developers have prototyped using the behind-a-flag implementation and given good feedback, several partners are interested in testing out the API with real users. We're looking forward to getting feedback from such testing, especially with regards to output quality, multilingual support, and what types of writing tasks are handled well vs. poorly. We also want to understand whether we've found the right set of options to offer to control the output, and whether the resulting output reflects those controls to the extent that developers expect.
Reason this experiment is being extended
Writer API suffers from perceived quality issues and a critical language support disconnect. These APIs are currently not production-ready for many use cases, particularly those outside of English. In addition, we are also seeing low adoption in the OT phase for this API. Hence, we are requesting the extension of the trial to give us time to collect more feedback from our partners and make the API more robust and resilient.
Ongoing technical constraints
As discussed above, not all devices are capable of running the language models required to implement this API. The availability() function allows developers to feature-detect whether the current device can support the API.
Debuggability
It is possible that giving DevTools more insight into the nondeterministic states of the model, e.g. random seeds, could help with debugging. See related discussion at https://github.com/explainers-by-googlers/prompt-api/issues/9.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
Not all platforms will come with a language model. In particular, in the initial stages we are focusing on Windows, Mac, and Linux.
Is this feature fully tested by web-platform-tests?
No
The API surface is reasonably well tested with mocked models, but production model downloading and non-deterministic outputs are not fully tested at the web-platform-tests layer. The explainer discusses this in https://github.com/WICG/writing-assistance-apis/blob/main/README.md#specifications-and-tests.
DevTrial instructions
https://docs.google.com/document/d/1v6-fOC13zS3S-bOLuqIRbzgmia_aPGJl-wzOx4ItSVE/edit?usp=sharing
Flag name on about://flags
writer-api-for-gemini-nano
Finch feature name
AIWriterAPI
Requires code in //chrome?
True
Tracking bug
https://issues.chromium.org/issues/357967382
Launch bug
https://launch.corp.google.com/launch/4396832
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
Yes: this feature depends on a language model, which is bridged to the open-source parts of the implementation via the interfaces in //services/on_device_model.
Estimated milestones
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
At this point all known proposed changes have been incorporated into the specification and implementation.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4712595362414592?gate=6282634527375360
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9qMAkT%3DiUBbDGfd_zcH7uEqze-H1r5DWUa8OFbtZGZ1Q%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9G-fLtpDFO1%2BdR1JS_1XWgczg%2BRte1_h32FUziSe-yLw%40mail.gmail.com
This intent message was generated by Chrome Platform Status.