Re: [blink-dev] Re: Intent to Ship: Subresource loading with Web Bundles

[Daisuke Enomoto]

Hello

I am sharing the feedback from the Origin Trial with 12 participants:

   -

   10 of them responded "Extremely likely" to "How likely are you to keep
   using this feature?"
   -

   Qualitative feedback:


   -

   "I'm very excited about the CSP interpretation change rolling out in M92"
   -

   "looking forward to the CSP fix!"
   -

   "I'm very glad you're working on this!"
   -

   "This feature is great! I'd love to see it fully launch"

Daisuke


On Sat, May 21, 2022 at 5:38 AM 'Jeff Kaufman' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks, Otto!  As someone who used to work on mod_pagespeed I wanted to
> give a bit more context on how web bundles improve on what is possible for
> automatic site optimization tools like mod_pagesped:
>
> 1. Combining many small images into a single file otherwise requires
> spriting (with css to identify which area of the image you want for each
> usage) and mod_pagespeed's ability to do that automatically (sprite_images
> filter ) is
> limited.  It needs to understand the site's css and the publisher needs to
> have already set their css up to minimize the changes required.  With
> bundles it is much simpler: you put all the tiny image files in the bundle,
> and you rewrite the URLs to point into the bundle.
>
> 2. Combining many small css or js files into a single file (combine_css
> , combine_js
> ) requires hacks to
> prevent invalid css or js from breaking the rest.  It's reasonably common
> that publishers will have  that
> doesn't parse, and if you blindly concatenate with other css you will
> change the layout on the page. Since automatic site optimization tools like
> mod_pagespeed want to make the site load faster without making any changes
> to how the site looks, that isn't acceptable.  Same issue with js.
>
> 3. Today you need to have separate files for combined images, css, and
> js.  With web bundles there can be just one.
>
> Jeff
>
> On Friday, May 20, 2022 at 1:11:16 PM UTC-4 Otto van der Schaaf wrote:
>
>> As a maintainer of mod_pagespeed , I
>> would love to see this ship.
>>
>>
>> On Wednesday, May 4, 2022 at 5:42:15 PM UTC+2 slightlyoff via
>> Chromestatus wrote:
>>
>>> Microsoft would like to see this ship ASAP. LGTM1
>>>
>> --
> 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/45f97f97-7db0-42ee-bea8-d01ddb344ba6n%40chromium.org
> 
> .
>

-- 
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/CAA5e698aaK%3DnmW7_8ni14m2qn1-51f1uLWNPPsp1FozYNN0p7Q%40mail.gmail.com.

[blink-dev] Blink bug status as of 2022-05-23

[tkent]

Title: Blink bug summary




Blink bug status as of 2022-05-23

Component
Open


Slow Triage
Pri-0/1



⭐
No owner
Oldest


Whole Blink16,851(-21)69,907(-118)1,070(-1)991(-20)285Jan 2015
Uncategorized11(-1)17(-4)13(+1)2Mar 2022
Blink>Accessibility355(+2)1,210(+2)03211Jul 2019
Blink>Animation250(-3)1,377(+2)2(+1)9(-1)7Apr 2021
Blink>AppManifest31196231Jan 2020
Blink>AudioOutputDevices1035100
Blink>BackgroundFetch386016218Sep 2018
Blink>BackgroundSync1543543Nov 2020
Blink>BatteryStatus953622Nov 2016
Blink>Bindings286(+6)996(+5)6(+1)21(+1)6Apr 2016
Blink>Bluetooth121572(-18)3(+3)22Jan 2020
Blink>CSS480(-4)3,525031May 2022
Blink>Canvas321(+6)1,201(+6)12151Jun 2016
Blink>CaptureFromElement2072331Feb 2022
Blink>Compositing205(-2)735(-1)1(-2)30Dec 2021
Blink>Contacts1127020Apr 2020
Blink>ContentIndexing424110May 2020
Blink>DOM208(+4)902(+20)04(+1)1Mar 2022
Blink>DataTransfer269(-2)1,246(-6)1(-1)164Nov 2017
Blink>DocumentMetadata1123211Feb 2020
Blink>Editing9823,722(-4)18(+2)11(-3)6Apr 2020
Blink>EnumerateDevices26893(+1)10Feb 2022
Blink>FeaturePolicy48150(-15)19(+2)77Jun 2021
Blink>FencedFrames72(+3)127(+4)1621(+3)9May 2021
Blink>FoldableAPIs647000
Blink>Fonts373(-3)1,870(-6)8(+1)3(-1)0Mar 2022
Blink>Forms433(-3)2,063(-7)4(+1)31Mar 2022
Blink>Fullscreen79(+1)270(-1)15(+1)0Aug 2020
Blink>GamepadAPI112(+1)387(+2)020Feb 2019
Blink>GarbageCollection150406(+1)4(+1)72Jan 2020
Blink>Geolocation49312(+2)0(-1)52May 2018
Blink>Geometry47(+1)147(+1)2(-1)00
Blink>GetDisplayMedia153(-1)521821(-1)3Dec 2019
Blink>GetUserMedia112471(-30)17(+2)16(-1)0Jan 2021
Blink>HID42(+1)137(+1)1(+1)00
Blink>HTML492(+5)2,110(+14)1(-1)3(-1)1Apr 2022
Blink>Handwriting55400
Blink>History33(+1)122(+2)1(+1)10Oct 2021
Blink>HitTesting46(-1)187(-7)01(-1)1May 2022
Blink>Identity92(+3)125(+2)18273May 2021
Blink>Image112(-1)591(-1)0(-2)10Feb 2022
Blink>ImageCapture19692(+1)00
Blink>Infra144(-10)436(-24)17(-10)10Apr 2022
Blink>Input826(+2)2,807(+6)7(+6)39(+1)20Apr 2019
Blink>InterestCohort11(-3)17(-10)13(-2)0Apr 2022
Blink>InterestGroups4886262(+1)0Feb 2021
Blink>Internals233(-1)678(-3)1214723Aug 2017
Blink>_javascript_1,057(-22)2,992(-25)74(+1)90(-18)11Aug 2015
Blink>Layout1,028(-1)5,683(+10)13(+3)21(-4)3Aug 2021
Blink>LazyLoad40179000
Blink>Loader512(-6)2,293(-5)5(+1)20(-2)3Feb 2017
Blink>Managed11000
Blink>MathML233392(+1)11Jun 2020
Blink>Media878(-3)3,119(-8)7998(-2)33Aug 2015
Blink>MediaRecording47(-1)257(-4)311Feb 2021
Blink>MediaStream92(+2)443(+4)17(+1)70Feb 2021
Blink>MemoryAllocator181(+2)600(+4)2(-2)43(+1)2Sep 2015
Blink>Messaging36133(+1)20(-1)84Feb 2017
Blink>NFC635000
Blink>Network445(-5)2,168(-12)11(+1)4111Aug 2015
Blink>PageLifecycle612292821Aug 2017
Blink>Paint674(-3)2,315(-85)0111Jul 2021
Blink>Payments142(+5)387(+6)07(+2)1Oct 2019
Blink>PerformanceAPIs186(+4)691(+5)2(-6)41Apr 2022
Blink>PermissionsAPI36147(+1)1320Oct 2021
Blink>Portals133(-1)38611138Mar 2020
Blink>PresentationAPI40(-1)130(-2)0(-1)20May 2019
Blink>Previews22000
Blink>PrivateAggregation81
Blink>PushAPI29125521Jul 2021
Blink>ReportingObserver7(-2)16(-1)0(-1)10Aug 2021
Blink>SVG321(+1)1,872(+1)0(-3)11Feb 2022
Blink>SavePage11173182(-1)63Jan 2015
Blink>Scheduling238(+1)1,848(+5)106(-1)122Oct 2017
Blink>Screen1846(-2)020Apr 2022
Blink>ScreenOrientation27721822Feb 2021
Blink>Scroll7522,6305(+5)4024Dec 2019
Blink>SecurityFeature5412,319(+3)4(+1)34(-1)13Sep 2017
Blink>Sensor25145010Apr 2020
Blink>Serial281351(+1)10Jun 2021
Blink>ServiceWorker316(-2)1,6808(+3)40Sep 2021
Blink>ShapeDetection23100021Jun 2019
Blink>Speech1135218873Sep 2019
Blink>Storage609(-11)3,402(+3)2(+1)57(+1)14Sep 2015
Blink>TextAutosize25239000
Blink>TextEncoding27(+1)99(+1)733Jul 2021
Blink>TopicsAPI29020Jan 2022
Blink>URLPattern34000
Blink>USB36182(-2)2(+2)20Jan 2021
Blink>Vibration921(+1)900
Blink>ViewSource19(+1)162(+1)000
Blink>WakeLock748000
Blink>WebAudio156(-1)687(+2)14(-2)61Oct 2020
Blink>WebAuthentication109332(-5)2520(+1)4Jan 2020
Blink>WebCrypto26661642Dec 2019
Blink>WebFonts28(+1)122(+1)100
Blink>WebGL649(+2)2,148(+2)2(-10)22(+2)0Jun 2020
Blink>WebGPU125(+2)364(+1)3171May 2020
Blink>WebHD12000
Blink>WebMIDI261274(+1)20Nov 2016
Blink>WebML8(+1)19(+2)400
Blink>WebOTP36(+1)158(+1)13(+1)30Sep 2020
Blink>WebRTC493(+2)2,735(+9)23(-2)51(+1)8Feb 2018
Blink>WebShare48253611Aug 2021
Blink>WebXR105415140Sep 2019
Blink>WindowDialog64(-1)575(-2)011Mar 2020
Blink>Workers158824(+2)3(+1)00
Blink>XML33161020Apr 2022



A value is the number of bugs in a component and its sub-components.
e.g. The 'Blink>Layout' row contains all of bugs in sub-components of
Blink>Layout in addition to Blink>Layout bugs.
The data was fetched with a permission of a general @google.com account.
It takes account of non-public bugs, but doesn't have the owner field and
the open date field of Restrict-View bugs.
Links from delta parts in the 'Open' columns don't represent
anchor numbers precisely because a query depends on the currnet date and
it doesn't contain issues of which component was changed






-- 
You received this 

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

['Harald Alvestrand' via blink-dev]

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  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 
>> 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
> 
> .
>
> 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
>> Specification
>>
>> Variants header:
>> 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
>> 
>>
>> 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
>>
>> 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
>> 
>> 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
>>
>>
>>
>> TAG review
>>
>> To be filed.
>>
>> RisksInteroperability 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
>> 

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

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  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  
 
 .

 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 
> Specification
>
> Variants header: 
> 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 
> 
>
> 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
>
> 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 
>  
> 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
>  
>
>
> TAG review
>
> To be filed.
>
> RisksInteroperability 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 
> 

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

['Harald Alvestrand' via blink-dev]

So one extra round trip per page?


On Sun, May 22, 2022 at 5:31 PM Victor Tan  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
>>> 
>>> .
>>>
>>> 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
 Specification

 Variants header:
 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
 

 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

 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
 
 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



 TAG review

 To be filed.

 RisksInteroperability 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
 
 ?

 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


 *Launch bug*
 https://bugs.chromium.org/p/chromium/issues/detail?id=1307484

 *Link to entry on the Chrome Platform Status*
 https://chromestatus.com/feature/5188040623390720

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

[Victor Tan]

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  
>> 
>> .
>>
>> 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 
>>> Specification
>>>
>>> Variants header: 
>>> 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 
>>> 
>>>
>>> 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
>>>
>>> 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 
>>>  
>>> 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
>>>  
>>>
>>>
>>> TAG review
>>>
>>> To be filed.
>>>
>>> RisksInteroperability 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 
>>> 
>>> ?
>>>
>>> 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
>>>
>>>
>>> *Launch bug*
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484  
>>>
>>> *Link to entry on the Chrome Platform Status*
>>> https://chromestatus.com/feature/5188040623390720 
>>> 
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To