Contact emailsdome...@chromium.org, kenjibah...@chromium.org,
m...@chromium.org, btri...@chromium.org, ds...@chromium.org,
a...@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

A JavaScript API for writing new material given a writing task prompt,
backed by an AI language model.


Blink componentBlink>AI>Write
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAI%3EWrite%22>

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/991

TAG review statusPending

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*: Defer (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?

None


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.

Ongoing technical constraints

None


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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?No

We plan to expand the web platform test coverage of the API surface over
the course of the origin trial. The core algorithm might be difficult to
test, given the nondeterministic nature of the output. 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://flagswriter-api-for-gemini-nano

Finch feature nameEnableAIWriterAPI

Requires code in //chrome?True

Tracking bughttps://issues.chromium.org/issues/357967382

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
Origin trial desktop first 137
Origin trial desktop last 142
DevTrial on desktop 129

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).
We're discussing what the best defaults are for length and format at
https://github.com/webmachinelearning/writing-assistance-apis/issues/51 .
Origin trial feedback will likely be helpful in resolving this.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4712595362414592?gate=6179566004207616

Links to previous Intent discussionsIntent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9qMAkT%3DiUBbDGfd_zcH7uEqze-H1r5DWUa8OFbtZGZ1Q%40mail.gmail.com


This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9G-fLtpDFO1%2BdR1JS_1XWgczg%2BRte1_h32FUziSe-yLw%40mail.gmail.com.

Reply via email to