LGTM
/Daniel
On 2025-04-17 03:46, Domenic Denicola wrote:
Contact emails
dome...@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/#rewriter-api
Summary
A JavaScript API for transforming and rephrasing input text in the
requested ways, backed by an AI language model.
Blink component
Blink>AI>Rewrite
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAI%3ERewrite%22>
TAG review
https://github.com/w3ctag/design-reviews/issues/991
TAG review status
Pending
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 rewritten 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 input data
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://flags
rewriter-api-for-gemini-nano
Finch feature name
EnableAIRewriterAPI
Requires code in //chrome?
True
Tracking bug
https://issues.chromium.org/issues/358214322
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).
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/5112320150470656?gate=5159400139128832
Links to previous Intent discussions
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9Jhe7o59mX5tJPD%3DcZQb2oL3mNi-T57wA86fPXn55OPw%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/CAM0wra8dnNHXKM26MvQxZ6LBE16PUbvH6-GH5B3Z2WDv4uH0WQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8dnNHXKM26MvQxZ6LBE16PUbvH6-GH5B3Z2WDv4uH0WQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/43dc2e6f-7e6c-4654-9546-b8db5d6733b0%40gmail.com.
