LGTM to experiment in M128-131 inclusive.
/Daniel
On 2024-09-09 18:58, Victor Tan wrote:
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 <https://tranco-list.eu/>, 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 366sites (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
On Wednesday, August 21, 2024 at 12:07:29 PM UTC-4 Victor Tan wrote:
Hi Alex,
I will try to get approval to publish some data if that helps.
Victor
On Wed, Aug 21, 2024 at 11:58 AM Alex Russell
<slightly...@chromium.org> wrote:
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
On Wednesday, August 21, 2024 at 1:26:24 AM UTC-7 Mike Taylor
wrote:
Thanks for the thoughtful article and feedback Yoav -
we'll chat about it internally.
On 8/20/24 11:24 PM, Yoav Weiss (@Shopify) wrote:
<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/
<https://blog.yoav.ws/posts/improving_language_negotiation/>
On Wed, Aug 7, 2024, 17:41 Victor Tan
<victor...@chromium.org> wrote:
Email Body
Contact emails
victor...@chromium.org
<mailto:victor...@chromium.org>,
miketa...@chromium.org <mailto:miketa...@chromium.org>
Explainer
https://github.com/explainers-by-googlers/reduce-accept-language
<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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
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
<https://github.com/mozilla/standards-positions/issues/1014>)
WebKit: Shipped
(https://github.com/WebKit/standards-positions/issues/338
<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
<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
byweb-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 the Accept-Language header).
Flag name on chrome://flags
#reduce-accept-language
Finch Flag name
kReduceAcceptLanguage
Tracking bug
https://issues.chromium.org/issues/40218547
<https://issues.chromium.org/issues/40218547>
Launch bug
https://launch.corp.google.com/launch/4317282
<https://launch.corp.google.com/launch/4317282>
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
<mailto:blink-dev+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HuVnM9iE1%2BMF2pY%3DP%3DVNHmtP%2B1oZdUQ2Hm2bMjrW04Dw%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/8d538dcc-db6c-4cc4-9012-fa2f984d4c83n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d538dcc-db6c-4cc4-9012-fa2f984d4c83n%40chromium.org?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/b7850295-f428-4264-b341-63c47219d803%40gmail.com.
