I am happy to see you working on reducing the fingerprinting surface on
the web, and this seems like a worthwhile place get rid of some entropy.
Though, just like some other comments here suggest, I also suspect that
just a single language might not be enough.
There is a disparity between the languages that are primary languages
for people on this planet, and the languages used for content on the
web. The web has a dominance of languages that are shared by many, such
as English, Chinese, Russian, Spanish and Persian. If someone's primary
language is a smaller language they will face a couple of bad options:
1. Use a common second language as primary language, and miss out on
content in the language they understand best.
2. Accept that they will get some default language on pages and hope
that is one they can read.
3. Hope that every multi-language site they visit is rewritten to
negotiate a language.
I think expanding from one to two languages will be enough to cover many
of the use cases, and I don't think that will add much information
(TBD). Here in Sweden, I expect a majority to have [sv, en] for
instance, in Catalonia it might be [ca, es] and so on.
A compromise might be to always keep the first "common" language though
it adds the problem of determining what is a "common" language.
I'm a bit concerned that this might cause issues that will be invisible
for those that live entirely on the English speaking web so I hope you
take care to avoid such biases.
/Daniel
On 2022-05-23 16:05, Victor Tan wrote:
Yea, we definitely will collect metrics on those performance. thanks
for your comments.
On Sunday, May 22, 2022 at 2:08:02 PM UTC-4 Harald Alvestrand wrote:
I hope you will be recording the percentage of extra round trips,
split on main language preference. This may be a disproportionate
impact on people without English as their first language.
On Sun, May 22, 2022 at 6:15 PM Victor Tan
<victor...@chromium.org> wrote:
The browser will only do language negotiation if necessary.
Yea, you are right, it would take an extra round trip in some
cases. We also plan to save some selections in memory to avoid
introducing large latency.
On Sunday, May 22, 2022 at 12:11:23 PM UTC-4 Harald Alvestrand
wrote:
So one extra round trip per page?
On Sun, May 22, 2022 at 5:31 PM Victor Tan
<victor...@chromium.org> wrote:
Hi Harald,
The browser will do language negotiation with resend
the request (only happen once) with accept-language:en
to get a result with English page.
Victor
On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald
Alvestrand wrote:
So if my config is (no, en), the site supports
(fr, en), the first response will be in French
with a Vary:(fr, en) header? Will the browser
automatically detect that a better alternative is
available and re-ask, imposing an extra RTT, or
will the result remain French?
fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via
blink-dev <blink-dev@chromium.org>:
NOTES: This intend won't implement Variants in
the HTTP cache. It only focus on using
Variants http header as a support-languages
head which in the definition on section 2
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06#section-2>.
On Thursday, May 19, 2022 at 10:20:29 AM UTC-4
vict...@chromium.org wrote:
Contact emails
vict...@chromium.org, abe...@chromium.org
Explainer
https://github.com/Tanych/accept-language
<https://github.com/Tanych/accept-language>
Specification
Variants header:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06>
Summary
Support the HTTP Variants header and
implement the reduction of information
that could be used for fingerprinting in
the Accept-Language header, so that Chrome
only sends the user’s most preferred
language in the Accept-Language header on
the initial request.
Blink component
Privacy>Fingerprinting
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
Motivation
The Accept-Language header is a source of
passive fingerprinting information about
users, as it can contain a high degree of
entropy, particularly if the user has many
accepted languages.
Chrome (and other browsers) send a full
list of the user's accepted languages on
every HTTP request via the Accept-Language
header. While some sites use this
information for content negotiation,
servers can also passively capture this
information without the user's awareness,
to fingerprint a user.
We propose to only send a single
language—one of the user’s preferred
languages determined by the language
negotiation process—in the Accept-Language
request header by default. Here’s what
that would look like when a user tries to
access https://example.com:
Get / HTTP/1.1
Host: example.com <http://example.com>
Accept-Language: en
HTTP/1.1 200 OK
Content-Language: en
Vary: Accept-Language
Variants: Accept-Language=(en)
As the response shows, in addition
to the Content-Language in the
response header, sites will
respond with a Variants
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06>header
(support for which will be
prototyped as part of this
intent), the value of which
includes all the languages the
site supports. Browsers can use
the Variants header to do language
negotiation if sites offer a page
in a language that doesn’t match
the user's preferred languages.
Initial public proposal
https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
<https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835>
TAG review
To be filed.
Risks
Interoperability and Compatibility
We are reducing the number of languages
sent in the Accept-Language header to
protect user privacy. The main source of
risk is that sites rely on all or part of
a user’s preferred languages instead of
the most preferred language. We feel it’s
important to minimize the breakage of the
features depending on Accept-Language as
much as possible, to maintain stability of
the web ecosystem. To mitigate the risk of
this change, we intend to gradually roll
it out via Finch configuration and keep
monitoring health metrics and bug reports
from the community.
Gecko: No signals
WebKit: No signals
Web developers: See the explainer for
details.
Debuggability
No special DevTools support needed.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
It will be.
Flag name
reduce-accept-language
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1306905
<https://bugs.chromium.org/p/chromium/issues/detail?id=1306905>
*Launch bug*
https://bugs.chromium.org/p/chromium/issues/detail?id=1307484
<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
<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/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%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/e1bef704-a140-4271-923c-59bb69861f32n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1bef704-a140-4271-923c-59bb69861f32n%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/aa55c380-c8ad-be95-4086-bf79d873358f%40gmail.com.
