On 4/1/25 5:00 PM, Jeffrey Yasskin wrote:
Have you proposed that a standards body adopt this into a working
group of some sort? Especially since Safari is doing something
similar, it seems like the WHATWG might be willing to adopt this into
the Fetch standard.
I think it may be possible to standardize the "only send one language"
aspect, but not the rest (until other vendors express support). But my
take on https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-language
is that this is already covered. If approved to ship, we're happy to
take on the work to move this to Fetch (I can also work on a PR if
that's useful now).
I'm also somewhat concerned about the internationalization concerns
expressed in
https://github.com/explainers-by-googlers/reduce-accept-language/issues/10.
I couldn't get `curl` to reproduce the content negotiation claimed in
https://github.com/explainers-by-googlers/reduce-accept-language/issues/10#issuecomment-2093906527
(e.g. Wikipedia seems to react to navigator.language and not
Accept-Language), but it'd be good to at least get all the Googlers on
that thread to agree on the facts about website behavior.
I appreciate the concerns raised, but I don't share them. Our
experiments (and Safari's behavior) show that this change is
web-compatible. Solving for navigator.languages may be trickier, but
that's why we've split it out from the proposal.
Jeffrey
On Tue, Apr 1, 2025 at 7:56 AM Victor Tan <victor...@chromium.org> wrote:
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. Instead of sending every user's
language preferences via Accept-Language, we propose to 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”). To minimize compatibility
risks, this intent only covers HTTP. We plan to reduce the related
navigator.languages JS getters in the future.
We would like to start rolling out in M136.
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, rather than remove the header or change
value format in the header. Most existing Accept-Language
detection code should continue to work. The 1% stable experiment
from M128 to M132 inclusive showed that there is no interesting
movement on crashes, latency metrics, and manually language
translation metrics. Also, we didn’t receive compatibility bug
reports. Our study of the top 10k sites provided by Tranco shows
that few sites actually use the Accept-Language header. For
subresources, we found no impact to CSS or images. For
JavaScripts, there are only a few sites that have different locale
bundles loaded when requesting with different Accept-Language.
Only a few embedded iframes (~30 unique origins, ~2.6% of all
unique subresource origins) have changed content based on a
different requesting Accept-Language header.
For the interoperability issues, it might create inconsistencies
between browsers for sites using the Accept-Language header, since
some provide a user's full Accept-Language list, while others only
provide the user's primary language. Another signal is that the
Chrome incognito model already reduces the Accept-Language header
and JS interface navigator.languages to a single language, and
Safari ships this same behavior.
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:No signals, but some concerns have been raised
about the client-side language negotiation implications
(https://github.com/explainers-by-googlers/reduce-accept-language/issues/10
<https://github.com/explainers-by-googlers/reduce-accept-language/issues/10>).
However, for this launch, we intend to reduce only the
Accept-Language HTTP header. Client-side language negotiation may
not be impacted at this phase, since tools use navigator.languages
for language negotiation. Additionally, most existing tools have a
fallback language if they do not find a language they support.
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
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, for WPT, we have tests for JS
getter and it has limits to set different users’ language
preference to cover all the test cases in the Accept-Language HTTP
header regarding the language negotiation). But otherwise, the
simple case is covered.
Flag name on chrome://flags
#reduce-accept-language-http
Finch Flag name
kReduceAcceptLanguageHTTP
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.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HisRSZYAgG99BpAR_Kjwxx26czQx05NqH-apXdSJo_3g%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HisRSZYAgG99BpAR_Kjwxx26czQx05NqH-apXdSJo_3g%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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c76519b-0336-4270-b44a-4f2a153ec22c%40chromium.org.
