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.
On 8/11/24 1:14 AM, Eli Grey wrote:
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
<https://github.com/explainers-by-googlers/reduce-accept-language>
TAG reviewTo 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.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3f0c568a-83fe-4da0-ad5a-b4d2f691ce25%40chromium.org.
