Intent to Prototype: Proofreader API
Queenie Zhang
queeni...@google.com, yaej...@google.com
Explainer
https://github.com/explainers-by-googlers/proofreader-api/blob/main/README.md
Specification
None
Summary
A JavaScript API for proofreading input text with suggested corrections, backed by an AI language model.
Blink component
Motivation
Browsers and operating systems are increasingly offering proofreading capability to help their users compose. By exposing this built-in model, we allow web applications to gain access to proofreading capability with the help of a language model, while avoiding every website needing to download their own multi-gigabyte language model, or sending input text to third-party APIs. The Proofreader API in particular exposes a high-level API for interfacing with a language model in order to proofread inputs for a variety of use cases [1], with three specific proofreading functionalities: error correction, error labeling, and error explanation.
[1]: https://github.com/explainers-by-googlers/proofreader-api?tab=readme-ov-file#use-cases
`
Initial public proposalhttps://github.com/webmachinelearning/proposals/issues/7
TAG review
None
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 able to run one. 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, which could help extend it to more users. And the high-level nature of the API, which hides the details of the specific language model, prompts, etc., makes it harder for developers to depend on specific outputs: they are getting generalizable data structure featuring three optional high-level proofreading functionalities, i.e. corrected text, error labeling and explanation in plain text format. 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 prototyping period.
Gecko: No signal
WebKit: No signal
Web developers: Developers have expressed interest in our explainer and proposed more potential use cases for the API: https://github.com/explainers-by-googlers/proofreader-api/issues
Other signals:
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
Debuggability
None
Is this feature fully tested by web-platform-tests?
No
We hope to work on web platform tests for this feature, but how much we can guarantee as testable beyond the surface API is unclear, given the nondeterministic nature of the output.
Flag name on about://flags
proofreader-api-for-gemini-nano
Finch feature name
AIProofreaderAPI
Non-finch justification
None
Requires code in //chrome?
True
Tracking bug
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5164677291835392?gate=5184634964672512
This intent message was generated by Chrome Platform Status.