Hi Domenic, et al., This intent came up in the OWP sec review today. We wonder whether there's XSS potential, and how input with plain text interspersed with tags is meant to be handled:
Several of the use cases seem to hint at the input being HTML strings (e.g. "pages with complicated DOM"). If the intended input would indeed be HTML strings, and the output is intended to be parsed & inserted into the DOM, then this basically implements a new XSS factory. In addition to the existing re-parsing risks, it would add new ones based on translation (e.g. "<schrift>" turning into "<script>"). The browser's built-in translation functionality can avoid this by only manipulating text nodes; but this would be difficult to replicate in a string-based API. Can you clarify what happens with HTML tags in the input string, and whether that is a supported use case? Maybe the API can be reformulated to seperate string-based from HTML-based inputs? It'd be good to add a note to the 'risks' section, so this isn't forgotten when this has taken a more concrete shape. Thanks, Daniel On Thu, Apr 25, 2024 at 8:30 AM Domenic Denicola <dome...@chromium.org> wrote: > Contact emailsdome...@chromium.org, fer...@chromium.org, > kenjibah...@chromium.org > > Explainer > https://github.com/explainers-by-googlers/translation-api/blob/main/README.md > > SpecificationNone yet, although the explainer does contain IDL which > could help a bit > > Summary > > This proposal introduces a new JavaScript API for exposing a browser's > existing language translation abilities to web pages. > > > Blink componentBlink > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> > > Motivation > > Browsers are increasingly offering language translation to their users. > Such translation capabilities can also be useful to web developers. This is > especially the case when browser's built-in translation abilities cannot > help, such as: - translating user input or other interactive features; - > pages with complicated DOMs which trip up browser translation; - providing > in-page UI to start the translation; or - translating content that is not > in the DOM, e.g. spoken content. To perform translation in such cases, web > sites currently have to either call out to cloud APIs, or bring their own > translation models and run them using technologies like WebAssembly and > WebGPU. > > > Initial public proposalhttps://github.com/WICG/proposals/issues/147 > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/948 > > TAG review statusPending > > Risks > > > Interoperability and Compatibility > > This feature has definite interoperability risks, including which > languages are available across different browsers, how they are exposed, > the quality of translations, and whether developers need the translations > to be on-device or not. We can ameliorate some of these through API design, > by making it clear that various methods might fail and that a fallback is > required. Others, like translation quality, may end up as > quality-of-implementation issues, similar to other machine learning-based > APIs like shape detection. > > > *Gecko*: No signal ( > https://github.com/mozilla/standards-positions/issues/1015) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/339) > > *Web developers*: No signals We have heard privately of this need from > various partners. Publicly, we have a few thumbs-up on the WICG proposal > but no substantive comments yet. > > *Other signals*: > > Activation > > This feature would definitely benefit from having polyfills, backed by any > of: cloud services, lazily-loaded on-device 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 > > > Debuggability > > Basic tooling should be sufficient > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?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. For example, > since no specific languages are guaranteed to be supported, it's not clear > we can actually test translations. APIs to mock the results might help here. > > > Flag name on chrome://flagsNone yet, although we're working on one > > Finch feature nameTranslationAPI > > Requires code in //chrome?True > > Tracking bughttps://issues.chromium.org/issues/322229993 > > Estimated milestones > > No milestones specified > > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5172811302961152 > > 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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8n%2BfTnOL502H8D6e2xXWT2zQj_2-gc6_8L4oBh1GWT5A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8n%2BfTnOL502H8D6e2xXWT2zQj_2-gc6_8L4oBh1GWT5A%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPP7fGhY9ynFMOTdQSFkLx%2BViKWEVLCLfCHy3BMt_jTWig%40mail.gmail.com.
