- What information does this feature expose, and for what purposes?
This feature exposes two large categories of information:
-
The implicit behavior of the underlying language model, in terms of what responses it provides to given inputs.
-
The availability information for various capabilities of the API, so that web developers know what capabilities are available in the current browser, and whether using them will require a download or the capability can be used readily.
The privacy implications of both of these are discussed in the explainer.
- Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
We believe so. It's possible that we could remove the exposure of the after-download vs. readily information. However, it would almost certainly be inferrable via timing side-channels. (I.e., if downloading a language model or fine-tuning is required, then the web developer can observe the creation of the summarizer/writer/rewriter object taking longer.)
- Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No. Although it's imaginable that the backing language model could be fine-tuned on PII to give more accurate-to-this-user outputs, we intend to disallow this in the specification.
- How do the features in your specification deal with sensitive information?
We do not deal with sensitive information.
- Do the features in your specification introduce state that persists across browsing sessions?
Yes. The downloading of language models, and any collateral necessary to support various options, persists across browsing sessions.
- Do the features in your specification expose information about the underlying platform to origins?
Possibly. If a browser does not bundle its own models, but instead uses the operating system's functionality, it is possible for a web developer to infer information about such operating system functionality.
- Does this specification allow an origin to send data to the underlying platform?
Possibly. Again, in the scenario where the model comes from the operating system, such data would pass through OS libraries.
- Do features in this specification enable access to device sensors?
No.
- Do features in this specification enable new script execution/loading mechanisms?
No.
- Do features in this specification allow an origin to access other devices?
No.
- Do features in this specification allow an origin some measure of control over a user agent's native UI?
No.
- What temporary identifiers do the features in this specification create or expose to the web?
None.
- How does this specification distinguish between behavior in first-party and third-party contexts?
It does not currently distinguish, although some of the anti-fingerprinting mitigations might involve partitioning download status, which is kind of like distinguishing between first- and third-party contexts.
- How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
One possible area of discussion here is whether backing these APIs with cloud-based models make sense in such modes, or whether they should be disabled.
Otherwise, we do not anticipate any differences.
- Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
There is no specification yet, but there is a privacy considerations section in the explainer.
We do not anticipate significant security risks for these APIs at this time.
- Do features in your specification enable origins to downgrade default security protections?
No.
- What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
Ideally, nothing special should happen. In particular, summarizer/writer/rewriter objects should still be usable without interruption after navigating back. We'll need to add web platform tests to confirm this, as it's easy to imagine implementation architectures in which keeping these objects alive while the Document is in the back/forward cache is difficult.
(For such implementations, failing to bfcache Documents with active summarizer/writer/rewriter objects would a simple way of being spec-compliant.)
- What happens when a document that uses your feature gets disconnected?
As with the previous question, nothing special should happen: the objects should still stay alive and be usable.
As with the previous question, it's easy to imagine implementations where this is difficult to implement. We may need to add a check in the specification to prevent such usage, if prototyping shows that the difficulty is significant.
- What should this questionnaire have asked?
Seems fine.