Yeap, M109 to M104 inclusive is enough for this OT. Bests, Victor
On Mon, Oct 31, 2022 at 10:58 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Even though this is not a typical OT, I don't think it should go beyond > the current policy of 6 milestone before showing significant progress > towards shipping. > Would M109 to M114 (inclusive) be enough? > > On Mon, Oct 31, 2022 at 3:36 PM Victor Tan <victor...@chromium.org> wrote: > >> Sorry for the unclear end milestone, we would like to experiment from >> M109 to M115. >> >> Bests, >> Victor >> >> On Mon, Oct 31, 2022 at 10:34 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> When do you expect the experiment to end? >>> >>> On Mon, Oct 31, 2022 at 3:32 PM Victor Tan <victor...@chromium.org> >>> wrote: >>> >>>> We are expected to start in M109 Beta until 2023 Q2. We will document >>>> more in the web blog post. >>>> >>>> Bests, >>>> Victor >>>> >>>> On Mon, Oct 31, 2022 at 10:12 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> That's fair. What is the experiment's timeline? >>>>> >>>>> On Mon, Oct 31, 2022 at 3:09 PM Victor Tan <victor...@chromium.org> >>>>> wrote: >>>>> >>>>>> > How would the OT work for the Accept-Language values of the >>>>>> very-first request sent to the origin? >>>>>> As described in the implementation doc >>>>>> <https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#bookmark=id.ob15kaq2dmkv>, >>>>>> there are some limitations for the current OT architecture, we can't >>>>>> validate the response OT token before we send the request. >>>>>> For the very first request, we are still sending the full >>>>>> Accept-Language user's list, after we validate the response, all >>>>>> subsequent >>>>>> requests start to send a reduced Accept-Language header. >>>>>> >>>>>> Bests, >>>>>> Victor >>>>>> >>>>>> On Mon, Oct 31, 2022 at 8:18 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> How would the OT work for the Accept-Language values of the >>>>>>> very-first request sent to the origin? Or are we expecting this request >>>>>>> to >>>>>>> send higher entropy, but not to hide potential breakage with later >>>>>>> requests >>>>>>> sending lower entropy? >>>>>>> >>>>>>> On Thu, Oct 27, 2022 at 7:57 PM Victor Tan <victor...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> victor...@chromium.org, miketa...@chromium.org >>>>>>>> >>>>>>>> Explainer >>>>>>>> >>>>>>>> https://github.com/Tanych/accept-language >>>>>>>> >>>>>>>> Specification >>>>>>>> >>>>>>>> Variants header: >>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06 >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> We want to reduce the amount of information the Accept-Language >>>>>>>> header exposes in HTTP requests and JS interface navigator.languages. >>>>>>>> Instead of sending all user’s Accept-Language, we only send the user’s >>>>>>>> most >>>>>>>> preferred language after language negotiation in the Accept-Language >>>>>>>> header. navigator.languages returns the same value as >>>>>>>> navigator.language >>>>>>>> during this experiment. >>>>>>>> >>>>>>>> We would like to run an origin trial for sites to opt into the >>>>>>>> Reduce Accept-Language origin trial to proactively test for breakage. >>>>>>>> See >>>>>>>> below for more details. >>>>>>>> >>>>>>>> Implementation Doc >>>>>>>> >>>>>>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY >>>>>>>> >>>>>>>> Blink component >>>>>>>> >>>>>>>> Privacy>Fingerprinting >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting> >>>>>>>> >>>>>>>> Risks >>>>>>>> >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> The compatibility risk is low since we're planning to reduce the >>>>>>>> amount of information in the Accept-Language header and >>>>>>>> navigator.languages, rather than remove the header or change value >>>>>>>> format >>>>>>>> in the header. Most existing Accept-Language detection code should >>>>>>>> continue >>>>>>>> to work. >>>>>>>> >>>>>>>> As for interoperability, no signal for other vendors. For >>>>>>>> multilingual sites to rely on the Accept-Language header, developers >>>>>>>> would >>>>>>>> need to depend on a user's full Accept-Language list for some browsers >>>>>>>> and >>>>>>>> a primary user's Accept-Language for others. >>>>>>>> >>>>>>>> Another signal is that the Chrome incognito model already reduced >>>>>>>> the Accept-Language header and JS interface navigator.languages to one >>>>>>>> language. The Accept-Language header can potentially expand to two if >>>>>>>> the >>>>>>>> first Accept-Language includes a region code, like en-US, the reduced >>>>>>>> Accept-Language header will be en-US,en;q=0.9. >>>>>>>> >>>>>>>> Experiment Summary >>>>>>>> >>>>>>>> The experiment is going to be a little different from a normal >>>>>>>> Origin Trial. The goal is enabling developers to test and ensure >>>>>>>> compatibility with our proposed changes. It’s incredibly important we >>>>>>>> give >>>>>>>> developers any chance to test systems at every level since this change >>>>>>>> represents vast dependencies on the introduced headers. >>>>>>>> >>>>>>>> As for enabling with the origin trial itself, there will be two >>>>>>>> components controlled by the same origin trial: >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> Reducing the information in navigator.languages if the origin >>>>>>>> trial enabled. >>>>>>>> - >>>>>>>> >>>>>>>> The Accept-Language HTTP request header contains the user’s >>>>>>>> primary preferred language, this can change if we detect a more >>>>>>>> preferred >>>>>>>> language during the language negotiation process. >>>>>>>> >>>>>>>> Because of the experimental nature of reducing Accept-Language, a >>>>>>>> valid origin token must be sent in the response header by origins which >>>>>>>> opt-in the origin trial. Also two new headers Variants >>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2> >>>>>>>> (indicating sites supporting languages) accept-language and >>>>>>>> Content-Language <https://datatracker.ietf.org/doc/html/rfc3282> >>>>>>>> need to be sent in the response header in order to make the language >>>>>>>> negotiation to work correctly. >>>>>>>> >>>>>>>> Please see the design and implementation document >>>>>>>> <https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit#heading=h.b6kmd248xsy4>for >>>>>>>> more information. >>>>>>>> >>>>>>>> Experiment Goals >>>>>>>> >>>>>>>> The goal of this origin trial is to enable developers to test how >>>>>>>> reducing the Accept-Language request header and the JS getter >>>>>>>> navigator.languages will affect their systems, especially to >>>>>>>> understand the >>>>>>>> user cases on navigator.languages. We hope this can provide sufficient >>>>>>>> time >>>>>>>> for developers to test. We can validate our current plans for reducing >>>>>>>> Accept-Language and safely roll out them to the web based on their >>>>>>>> feedback. >>>>>>>> >>>>>>>> We will be relying heavily on user and developer feedback to >>>>>>>> identify where breakage occurs, or where use cases are not accounted >>>>>>>> for, >>>>>>>> especially for multilingual sites depending on the Accept-Language >>>>>>>> header, >>>>>>>> and navigator.languages. We will create a GitHub repository and a >>>>>>>> public >>>>>>>> mailing list for gathering feedback. When the origin trial is ready, we >>>>>>>> plan to publish developer guidance on how to enroll and provide >>>>>>>> feedback. >>>>>>>> >>>>>>>> Experiment Risks >>>>>>>> >>>>>>>> There are some risks, as many multilingual sites have come to rely >>>>>>>> on the value in Accept-Language header and JS interfaces >>>>>>>> navigator.languages to send the right representation pages to the user. >>>>>>>> Site breakage can take many forms, both obvious and non-obvious. >>>>>>>> However, >>>>>>>> since sites are in control of the Origin-Trial, Variants and >>>>>>>> Content-Language headers, a site can quickly opt out of the experiment >>>>>>>> when >>>>>>>> breakage is encountered. >>>>>>>> >>>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>> >>>>>>>> No (All but WebView) >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>> ? >>>>>>>> >>>>>>>> No (We fully test in browser_tests, WPT has limits to cover all the >>>>>>>> test cases in Accept-Language header). >>>>>>>> >>>>>>>> Flag name >>>>>>>> >>>>>>>> ReduceAcceptLanguageOriginTrial >>>>>>>> Tracking bug >>>>>>>> >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1306905 >>>>>>>> Launch bug >>>>>>>> >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484 >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> >>>>>>>> https://chromestatus.com/feature/5188040623390720 >>>>>>>> <https://chromestatus.com/feature/5188040623390720#details> >>>>>>>> >>>>>>>> -- >>>>>>>> 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/CAJh4P7EvtPH_NQX_mJevEXu2fbePPQ7aYhfdBd%2BYB1J-5cn74g%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7EvtPH_NQX_mJevEXu2fbePPQ7aYhfdBd%2BYB1J-5cn74g%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/CAJh4P7F4efsTF5PWM17X7v8J-xBzsOf53DWgEE%2Brw5Ye%3D5dBmw%40mail.gmail.com.
