Intent to Experiment: Reduce Accept-Language

[Victor Tan]

Email Body

Contact emails

vict...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/explainers-by-googlers/reduce-accept-language 

TAG review

To be filed.

Summary

In order to reduce the amount of passively available entropy in HTTP requests, we want to reduce the amount of information the Accept-Language header exposes in HTTP requests and JS interface navigator.languages. Instead of sending every user's language preferences via Accept-Language, we only send the user’s most preferred language after language negotiation in the Accept-Language header. For the HTTP Accept-Language header, we will potentially expand a base language based on the language-region pair (e.g., if the preferred language is “en-US” we will expand to “en-US, en;q=0.9”). The JS getter navigator.languages returns the same value as navigator.language. 

We would like to run a Finch 1% experiment from M128 to M131 inclusive.

Blink component

Privacy>Fingerprinting

Risks

Interoperability and Compatibility

The compatibility risk is relatively low for most users 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. This experiment should help us validate this assumption and identify corner cases.

As for interoperability, for multilingual sites to rely on the Accept-Language, 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, and Safari ships this behavior for many users today. 

Gecko: Pending (https://github.com/mozilla/standards-positions/issues/1014) 

WebKit: Shipped (https://github.com/WebKit/standards-positions/issues/338) Safari already reduced the Accept-Language to a single language in most cases.

Web developers: Some web developers are concerned about the client-side language negotiation implications (https://github.com/Tanych/accept-language/issues/10).

Experiment Goals

The goal of this experiment is to ensure web compatibility with our proposed changes. Developers can also test how reducing the Accept-Language request header and the JS getter navigator.languages will affect their systems via the  chrome://flags/#reduce-accept-language flag, especially to understand the impact on client side language negotiation via navigator.languages. 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.

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 - which is the point of running this experiment. If we are confident the design is largely web-compatible, we will request a Deprecation Trial for sites to be able to have time to migrate or modify how their sites work.

Debuggability

Both of these settings and the resulting network requests are visible in DevTools.

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?

No (We fully test in browser_tests, WPT has limits to cover all the test cases in the Accept-Language header).

Flag name on chrome://flags

#reduce-accept-language

Finch Flag name

kReduceAcceptLanguage

Tracking bug

https://issues.chromium.org/issues/40218547 

Launch bug

https://launch.corp.google.com/launch/4317282

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5188040623390720 

[Alex Russell]

Hey Victor,

As you know, removal of entropy is not in and of itself a useful goal. A large number of users on the web are bi-lingual. Is there any analysis that this will do more good than harm?

Thanks,

Alex

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HuVnM9iE1%2BMF2pY%3DP%3DVNHmtP%2B1oZdUQ2Hm2bMjrW04Dw%40mail.gmail.com.

[Philip Jägenstedt]

Looking at the alternatives considered, I wonder if you've also explored identifying common combinations of languages, and limiting the header to the most common current values of the header? The combination of a small language like Swedish and a large language (English, Chinese, Spanish, etc) in some order is probably very common.

Heads up that I am going OOO, so I won't be able to follow up, so don't block this intent on me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQg8LzabF30UNUk_gdaniXdZcKKR%3D_dEwpz2WjfOVog4XQ%40mail.gmail.com.

[Victor Tan]

Hey Alex,

We already have done lots of analysis on how sites actually use the accept-language. 

We definitely will analyze whether this could cause any web compatibility issue, etc. during the experiment. 

Also, This proposal is not just simply reducing the language to one language, there are options for sites if they care about multi-languages.

Victor

[Mike Taylor]

Hey Philip,

Yes - we have discussed this a little bit, and are open to finalizing on that as a solution. But we'd like to gather some baseline metrics on the most minimal version first (which is the point of this experiment), and explore other solutions depending on compat impact (which we plan to measure in a handful of ways, including number of times users are trying to use the in-browser translation feature).

later,
Mike

[Eli Grey]

Restricting accept-language to 'common combinations' is fundamentally at odds with personal agency. This can break the web for people with uncommon combinations of accepted languages. This change would effectively discriminate against these people by denying them access to websites in their preferred languages that previously worked just fine.

Language preferences should not be ignored just because they're unique, and therefore trackable.

On Wednesday, August 7, 2024 at 8:41:48 AM UTC-7 vict...@chromium.org wrote:

Email Body

Contact emails

vict...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/explainers-by-googlers/reduce-accept-language 

TAG reviewTo be filed.

[Yoav Weiss (@Shopify)]

<api owner hat off>

I wrote a few words about this proposal and how I think we can avoid some of the tradeoffs it is making and end up with better user experience *and* more privacy: https://blog.yoav.ws/posts/improving_language_negotiation/

[Mike Taylor]

Thanks for the feedback - but if you re-read the explainer, you'll note that preferred languages will continue to work with the proposed Avail-Language API.

[Mike Taylor]

Thanks for the thoughtful article and feedback Yoav - we'll chat about it internally.

[Alex Russell]

Sorry for the slow response.

Victor: it would be good to see some of that data if and when y'all can publish it. The API OWNERS aren't generally keen to take breakage risks on faith.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Victor Tan]

Hi Alex,

I will try to get approval to publish some data if that helps. 

Victor

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Victor Tan]

Hey Alex (and others),

Here’s a few questions we asked ourselves to hopefully answer questions you or others might have, in order to feel comfortable with moving forward with this experiment:

1. What do we hope to learn from this 1% stable experiment that we can’t already get from UMA or pre-release experimental data?

   1. With this 1% stable experiment, we would like to test the following hypotheses:

      1. Reducing accept-language won’t cause site breakage or meaningful compatibility issues since the majority of users only have 1 or 2 language preferences: e.g., on Mac 68% users have a single language, and 95% of users have 2 or fewer. That said, breaking the experience for upwards of 5% of users is clearly a bad situation to be in and unshippable - hence we’re trying to gather more information. 

      2. The feature won’t introduce significant regressions to LCP.

   2. In Chrome 109, we ran an Origin Trial to test these assumptions - but we had only a few origins participating. It’s hard to draw useful conclusions about the feature design from this data, unfortunately.

   3. In our pre-release studies we observe the following:

      1. LCP changes are neutral.

      2. For language related metrics: 

         1. We don’t see any significant changes in the number of languages that users choose to always translate via the built-in Translate UI.

         2. It's also neutral for other manually translated language metrics from UI.

      3. That said, the pre-release population is quite small and gathering data for 1% of users would help us better understand potential impact.

2. What % of top sites are using Accept-Language? Do we know what % of traffic those sites represent?

   1. What % of top sites are using Accept-Language

      1. From our crawl-based study on the top 10K sites data provided by Tranco, only only 773 sites (773/7889*100 = 9.8%) respond to different languages when setting different values on the Accept-Language header. 

      2. For top 10K sites in UK,  only 366 sites (366/9744*100 = 3.7%) respond to different languages when setting different values on the Accept-Language header.

   2. What % of traffic those sites represent

      1. We don’t have this data handy, but from the top 10k sites that support multiple languages, ~200 of 773 contain google in the origin.

3. Do we already know how frequently `Content-Language` or HTML `lang` (where they exist in responses) are different from the first language preference? This should help us estimate some “wrong language breakage”.

   1. Content-language metrics:

      1. Nearly 96% of sites don’t send a Content-Language header or the content is empty in the header including most of the large sites. 2.2% of content-language headers matches any user’s accept-language, only 1.4% of content-language headers matches the user’s first language. So there’s not a lot of useful data to use here to make compat predictions.

   2. HTML lang metrics:

      1. 77% of html lang matches the user's first language, and 5% match any user’s language preference. 17% is empty. 

   3. You can infer an upper bound of breakage from this, but there’s so much missing data sent by servers that it’s hard to have a lot of confidence just based on this. And we suspect that upper bound is way larger than actual potential breakage would be.

Hope those are helpful.

Bests Regards,

Victor

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell]

LGTM to experiment in M128-131 inclusive.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d538dcc-db6c-4cc4-9012-fa2f984d4c83n%40chromium.org.