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

['Jeff Kaufman' via blink-dev]

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.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Dave Tapuska]

Ya I only ran into this when investigating how visibility really works.
Such as visibilityChanged events and document.visibilityState do not change
for a hidden iframe. (which I guess is correct based on its definition,
because those are about the tab being in the foreground or not). The only
problem I have with this definition is that the CSS spec declares it as
"rendered" and if someone is considering that as pixels on the display that
isn't quite correct.

I did find enough stack overflow articles about people asking about
interactions with the parent document. I don't think making it work for
same origin iframes vs cross origin iframes is something that would give
much benefit.

dave.

On Fri, May 20, 2022 at 2:39 PM Joey Arhar  wrote:

> > Oh that is what was debated here
> 
>
> I think that the use of "document" there was about being in the viewport
> and being painted, not about iframes.
>
> Currently, isVisible doesn't look at parent iframes. I don't think there's
> anything wrong with adding that functionality for LocalFrames, but doing so
> for RemoteFrames would probably have security/privacy considerations.
>
> On Thu, May 19, 2022 at 5:17 PM Dave Tapuska 
> wrote:
>
>> So how does this method work for iframes that have their visibility
>> hidden? Is it intended to work for that?
>>
>> 
>>  
>> 
>>
>> div's isVisible will always be true. Perhaps isVisible needs a caveat
>> that it only works for the current document. Oh that is what was debated
>> here
>> 
>> .
>>
>> dave.
>>
>> On Thu, May 19, 2022 at 6:52 PM Mike Taylor 
>> wrote:
>>
>>> Given the CSSWG resolution in
>>> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
>>> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>>>
>>> Thanks for addressing Mozilla's feedback.
>>>
>>> On 5/5/22 4:26 PM, Joey Arhar wrote:
>>>
>>> > Can you ask for signals?
>>>
>>> https://github.com/mozilla/standards-positions/issues/634
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>>>
>>> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss 
>>> wrote:
>>>


 On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:

> Contact emails jar...@chromium.org
>
> Explainer
> https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md
>
> Specification
> https://drafts.csswg.org/cssom-view/#dom-element-isvisible
>
> Summary
>
> Element.isVisible() returns true if the element is visible, and false
> if it is not. It checks a variety of factors that would make an element
> invisible, including display:none, visibility, content-visibility, and
> opacity.
>
>
> Blink component Blink>DOM
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/734
>
> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> This feature is not particularly contentious or complicated, but is
> mostly useful in the presence of content-visibility.
>
>
> Gecko: No signal
>
> WebKit: No signal
>

 Can you ask for signals?


>
> Web developers: No signals
>

 Would be good to gather signals here as well.


>
> Other signals:
>
> Ergonomics
>
> This feature could be used in tandem with content-visibility or
> details elements. Usage of this API will not make it hard for Chrome to
> maintain good performance.
>
>
> Activation
>
> This feature is easy to feature detect and polyfill.
>
>
> Security
>
> I have no security risks/considerations for this feature.
>
>
> 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?
>
> This does not deprecate or change any existing APIs and does not have
> any risk for WebView.
>
>
> Debuggability
>
> This feature does not need any new debugging features.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
>
> Flag name --enable-blink-features=isVisible
>
> Requires code in //chrome? False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1309533
>
> Estimated milestones
>
> 103
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Joey Arhar]

> Oh that is what was debated here


I think that the use of "document" there was about being in the viewport
and being painted, not about iframes.

Currently, isVisible doesn't look at parent iframes. I don't think there's
anything wrong with adding that functionality for LocalFrames, but doing so
for RemoteFrames would probably have security/privacy considerations.

On Thu, May 19, 2022 at 5:17 PM Dave Tapuska  wrote:

> So how does this method work for iframes that have their visibility
> hidden? Is it intended to work for that?
>
> 
>  
> 
>
> div's isVisible will always be true. Perhaps isVisible needs a caveat that
> it only works for the current document. Oh that is what was debated here
> .
>
> dave.
>
> On Thu, May 19, 2022 at 6:52 PM Mike Taylor 
> wrote:
>
>> Given the CSSWG resolution in
>> https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343,
>> LGTM1 to ship assuming we're not shipping `checkInert` with the rest.
>>
>> Thanks for addressing Mozilla's feedback.
>>
>> On 5/5/22 4:26 PM, Joey Arhar wrote:
>>
>> > Can you ask for signals?
>>
>> https://github.com/mozilla/standards-positions/issues/634
>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html
>>
>> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:
>>>
 Contact emails jar...@chromium.org

 Explainer
 https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md

 Specification
 https://drafts.csswg.org/cssom-view/#dom-element-isvisible

 Summary

 Element.isVisible() returns true if the element is visible, and false
 if it is not. It checks a variety of factors that would make an element
 invisible, including display:none, visibility, content-visibility, and
 opacity.


 Blink component Blink>DOM
 

 TAG review https://github.com/w3ctag/design-reviews/issues/734

 TAG review status Pending

 Risks


 Interoperability and Compatibility

 This feature is not particularly contentious or complicated, but is
 mostly useful in the presence of content-visibility.


 Gecko: No signal

 WebKit: No signal

>>>
>>> Can you ask for signals?
>>>
>>>

 Web developers: No signals

>>>
>>> Would be good to gather signals here as well.
>>>
>>>

 Other signals:

 Ergonomics

 This feature could be used in tandem with content-visibility or details
 elements. Usage of this API will not make it hard for Chrome to maintain
 good performance.


 Activation

 This feature is easy to feature detect and polyfill.


 Security

 I have no security risks/considerations for this feature.


 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?

 This does not deprecate or change any existing APIs and does not have
 any risk for WebView.


 Debuggability

 This feature does not need any new debugging features.


 Is this feature fully tested by web-platform-tests
 
 ? Yes

 Flag name --enable-blink-features=isVisible

 Requires code in //chrome? False

 Tracking bug
 https://bugs.chromium.org/p/chromium/issues/detail?id=1309533

 Estimated milestones

 103


 Anticipated spec changes

 Open questions about a feature may be a source of future web compat or
 interop issues. Please list open issues (e.g. links to known github issues
 in the project for the feature specification) whose resolution may
 introduce web compat/interop risk (e.g., changing to naming or structure of
 the API in a non-backward-compatible way).
 https://github.com/w3c/csswg-drafts/issues/7232

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

 Links to previous Intent discussions Intent to prototype:
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK01yGZ0LVb6M_8WdeC5OM0qfUv5T1TUO%3D1if1G%2BKogRw%40mail.gmail.com
 


 This intent message was generated by Chrome Platform Status
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from 

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

[Otto van der Schaaf]

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/efadf7e5-dba9-4d9a-abfc-6506955a03f1n%40chromium.org.

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

['Victor Tan' via blink-dev]

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 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/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS object-view-box

[Yoav Weiss]

On Fri, May 20, 2022, 17:31 Yoav Weiss  wrote:

>
>
> On Thu, May 19, 2022 at 6:22 PM Khushal Sagar 
> wrote:
>
>> Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org,
>> vmp...@chromium.org
>>
>> Explainerhttps://github.com/w3c/csswg-drafts/issues/7058
>>
>
> A short explainer with a few examples would go a long way to reassure me
> that what I think the feature does after reading this issue is actually
> what it does :)
>

Saw https://ishadeed.com/article/css-object-view-box passing by, and it
does an amazing job at explaining this!


>>
>> Specificationhttps://drafts.csswg.org/css-images-4/#the-object-view-box
>>
>> Summary
>>
>> object-view-box allows the author to specify a subset within an image
>> that should draw within the content box of the target replaced element.
>> This enables an author to create an image with a custom glow or shadow
>> applied, with proper ink-overflow behavior like a CSS shadow would have.
>>
>> Blink componentBlink
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/740
>>
>
> Seems like the TAG review is very recent and we need to give it some time..
>
>
>>
>>
>> TAG review statusPending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>>
>> Gecko: Worth prototyping (
>> https://github.com/mozilla/standards-positions/issues/626)
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-March/032166.html)
>>
>> Web developers: Positive
>> This property is a pre-requisite for Shared Element Transitions () which
>> has positive feedback from developers (source
>> ).
>>  Multiple
>> customers who are excited about SET need this feature to achieve their
>> desired UX, since their designs have visual overflows such as shadows.
>>
>> Other signals:
>>
>> WebView application risks
>>
>> None
>>
>>
>>
>> Debuggability
>>
>> The property can be debugged in the devtools style panel similar to other
>> CSS properties.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag nameCSSObjectViewBox
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1303102
>>
>> Estimated milestones
>>
>> M104
>>
>> Anticipated spec changesNone
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5213032857731072
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz11QzapF4BEX_QTu2FKsT2CEhphkyq%2BnorFgWA_G4qQw%40mail.gmail.com
>> 
>>
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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/CAMLuWUzJ_U4NRn1sF-eBOYHKifZYYwL-Xisq2twHw6B%3D3-WdmA%40mail.gmail.com
>> 
>> .
>>
>

-- 
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/CAL5BFfXhrzwGhWwEcgXhVU9X%2B5WMj5uM%2BvdnWWr_-vX2OTTn0g%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype and Ship: Multi-Screen Window Placement: Fullscreen Companion Window

[Sean Voisen]

Hi all — I'd just like to share a note of support for this enhancement to 
the API from Adobe and the Frame.io team. With the multi-screen window 
placement API, we can give users with multiple monitors the option to put 
the player on one monitor in full-screen, with media browsing and 
commenting on another screen. (This could include popups on the 
non-full-screen monitor as per the enhancement.) For our users, this will 
be a welcome improvement - especially for editors who are quite accustomed 
to reserving one monitor for their “program monitor”.

Thanks!
Sean
On Thursday, May 12, 2022 at 9:54:40 AM UTC-7 Mike Wasserman wrote:

> Hey Thomas,
>
> We don't necessarily need to change the web.dev article at this point, 
> but following up to explore API progress and related enhancements (e.g. 
> Fullscreen 
> Capability Delegation 
> ) 
> might be valuable to developers. Let's sync up soon.
>
> Thanks,
> Mike
>
>
> On Tue, May 10, 2022 at 1:25 AM Thomas Steiner  wrote:
>
>> Hi Mike,
>>
>> As far as I understand, no developer-facing changes are introduced by 
>> this intent, so the article 
>>  doesn't need changing, 
>> unless you want to mention feature detection and how this is in particular 
>> *not* detectable. Please advise.   
>>
>> Cheers,
>> Tom
>>
>>
>> On Tue, May 10, 2022 at 2:35 AM Mike Wasserman  wrote:
>>
>>> Contact emails
>>>
>>> m...@chromium.org
>>>
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md
>>>
>>> Specification
>>>
>>>
>>> https://github.com/w3c/window-placement/blob/main/EXPLAINER_initiating_multi_screen_experiences.md#spec-changes
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA
>>>
>>> Summary
>>>
>>> Fullscreen Companion Window allows sites to place fullscreen content and 
>>> a popup window on separate screens from a single user activation.
>>>
>>> This is a small requested enhancement of the Multi-Screen Window 
>>> Placement feature: https://chromestatus.com/feature/5252960583942144
>>>
>>> Blink component
>>>
>>> Blink>Screen>MultiScreen 
>>> 
>>>
>>> TAG review
>>>
>>>
>>> https://github.com/w3ctag/design-reviews/issues/602#issuecomment-1121694034
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> The main risk is that this feature fails to become an interoperable part 
>>> of the web platform if other browsers do not implement it. Scripted 
>>> attempts to open a popup window after requesting fullscreen would likely be 
>>> blocked by user agents that do not implement this feature, even if they 
>>> implement the basic Multi-Screen Window Placement API.
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/636)
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032223.html)
>>>
>>> Web developers: Positive (
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1233970) This 
>>> functionality is requested by a prominent API partner
>>>
>>> Ergonomics
>>>
>>> There is currently no way to detect feature support before attempted 
>>> usage; see 
>>> https://docs.google.com/document/d/1RRlGQharWVnmxKTomfKhNiaeE31L7iXHeXVfifOvwJA/edit?pli=1#heading=h.vu2lz7aeddz6
>>>
>>> Activation
>>>
>>> Developers can make immediate use of this API enhancement.
>>>
>>> Security
>>>
>>> This feature was designed from the ground-up to adhere to the strictest 
>>> usable security measures possible, as an incremental enhancement of 
>>> existing web platform APIs. See the design document for details.
>>>
>>> WebView application risks
>>>
>>> None
>>>
>>> Debuggability
>>>
>>> Existing mechanisms support debugging fullscreen and popup window open 
>>> requests.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?
>>>
>>> No. An existing automated/manual WPT covers the ability to open 
>>> cross-screen popups . We aim to 
>>> extend test coverage for this specific scenario soon <
>>> https://crbug.com/1323361>.
>>>
>>> DevTrial instructions
>>>
>>> https://github.com/w3c/window-placement/blob/main/HOWTO.md
>>>
>>> Flag name
>>>
>>> --enable-blink-features=WindowPlacement
>>>
>>> Requires code in //chrome?
>>>
>>> True - 
>>> https://docs.google.com/spreadsheets/d/1QV4SW4JBG3IyLzaonohUhim7nzncwK4ioop2cgUYevw/edit#gid=0=34:34
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/1233970
>>>
>>> Launch bug
>>>
>>> https://crbug.com/1315615
>>>
>>> Sample links
>>>
>>> https://michaelwasserman.github.io/window-placement-demo/
>>>
>>> (See DevTrial instructions)
>>>
>>> Estimated milestones
>>>

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

[Victor Tan]

NOTES: This intent won't implement Variants in HTTP cache behavior. It only 
focus on taking advantage of the definition of Section 2 

 as 
a Support-Languages header in this case

On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 Victor Tan wrote:

> Contact emails
>
> victor...@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 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/ec45210f-9d45-4a37-8bc6-989f4ba7f7f6n%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS object-view-box

[Yoav Weiss]

On Thu, May 19, 2022 at 6:22 PM Khushal Sagar 
wrote:

> Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org,
> vmp...@chromium.org
>
> Explainerhttps://github.com/w3c/csswg-drafts/issues/7058
>

A short explainer with a few examples would go a long way to reassure me
that what I think the feature does after reading this issue is actually
what it does :)


>
> Specificationhttps://drafts.csswg.org/css-images-4/#the-object-view-box
>
> Summary
>
> object-view-box allows the author to specify a subset within an image that
> should draw within the content box of the target replaced element. This
> enables an author to create an image with a custom glow or shadow applied,
> with proper ink-overflow behavior like a CSS shadow would have.
>
> Blink componentBlink
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/740
>

Seems like the TAG review is very recent and we need to give it some time..


>
>
> TAG review statusPending
>
> Risks
>
> Interoperability and Compatibility
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/626)
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2022-March/032166.html)
>
> Web developers: Positive
> This property is a pre-requisite for Shared Element Transitions () which
> has positive feedback from developers (source
> ).
>  Multiple
> customers who are excited about SET need this feature to achieve their
> desired UX, since their designs have visual overflows such as shadows.
>
> Other signals:
>
> WebView application risks
>
> None
>
>
>
> Debuggability
>
> The property can be debugged in the devtools style panel similar to other
> CSS properties.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag nameCSSObjectViewBox
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1303102
>
> Estimated milestones
>
> M104
>
> Anticipated spec changesNone
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5213032857731072
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUz11QzapF4BEX_QTu2FKsT2CEhphkyq%2BnorFgWA_G4qQw%40mail.gmail.com
> 
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CAMLuWUzJ_U4NRn1sF-eBOYHKifZYYwL-Xisq2twHw6B%3D3-WdmA%40mail.gmail.com
> 
> .
>

-- 
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/CAL5BFfXK6Kg5fff9whky3-Xn0CStGWucmO%3DbsYrQJcs42%2BrMpA%40mail.gmail.com.

[blink-dev] Re: Is end date of “Trial for RTCPeerConnection Plan B SDP Semantics” could be postpone?

['Henrik Boström' via blink-dev]

Hi,

See recent conversations over 
at https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/35NFPYdumMs 
for more details but the short answer is that the trial will not be 
extended.

On Thursday, May 12, 2022 at 6:59:38 PM UTC+2 hank...@gmail.com wrote:

> Hi:
>
>  we had an system still use plan B solution, is any chance or solution 
> postpone plan B ?
>
>

-- 
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/5c342370-2d06-40e4-bf90-421b6f5f61e3n%40chromium.org.

Re: [blink-dev] Intent stage "Evaluate readiness to ship": web-share permission policy

[Marcos Caceres]

Hi All, 

Coming back to this as it's now starting to cause Web compatibly issues 
across both Firefox and SafariTP (both of which implement `'self'`). 

I'm still worried that the ability to share files and other content (and 
even URLs, as we've seen in the past) is quite a powerful feature with 
security implications.

However, we (other implementers) are facing a losing battle with Web 
compatibly here :( 

If it's too far gone, could we compromise with a "*" policy. But I'd like 
to get again get a sense if we can go with 'self'.   


On Monday, November 2, 2020 at 4:22:58 PM UTC+11 Matt Giuca wrote:

> Pinging on this. It's been awhile and I don't think we've seen any update 
> on it. (Nobody from YouTube responded on the internal bug.)
>
> Eric, did measurements land and if so, what milestone will we start seeing 
> results in?
>
> On Fri, 4 Sep 2020 at 05:06, Chris Harrelson  wrote:
>
>> Hi Eric,
>>
>> Did the analysis relating to Youtube complete? Do you think this will be 
>> safe to turn on, because the Youtube case was sufficiently special?
>>
>> Chris
>>
>> On Sun, Aug 23, 2020 at 10:03 PM Eric Willigers  
>> wrote:
>>
>>>
>>> On Friday, August 21, 2020 at 5:15:18 AM UTC+10, Mike West wrote:

 Have you followed up with YouTube internally? As Eric notes, it seems 
 bad that this broke sharing in Canary.

>>>
>>> I have raised a YouTube issue internally, showing how to detect if 
>>> Feature Policy forbids sharing.
>>>
>>>
>>>
>>> -- 
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e554e75c-f1cc-4a68-bac9-a7e8477c916bo%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/6948552f-e384-461d-a5c5-13cc1fb13775n%40chromium.org.

Re: [blink-dev] Intent to Experiment: Reverse Origin Trial for WebRTC's Plan B SDP semantics

[Henrik Boström]

> Our video system still uses Plan B SDP, and we find that if we use 
chrome(M89), the video still can work normally now
> So, if we don't upgrade the browser, will it be affected after May 25th?

That's correct, in M89 Plan B was always allowed and the Deprecation Trial 
did not exist yet. So even after the trial ends, M89 will still continue to 
support Plan B.
The deprecation/removal of Plan B only affects more recent versions than 
that.

> However, we cannot make it before May 25th. Is there any alternative? 
Thanks!

It's not possible to extend the trial because the M102 stable release 
candidate does not contain the deprecation trial flag anymore. To be clear:
- In M101, attempting to set sdpSemantics to "plan-b" without a trial or 
after the trial has ended *throws an exception*.
- In M102, sdpSemantics is *ignored* and you get "unified-plan" even if you 
ask for "plan-b" (regardless of trial status). M102 stable release is 
scheduled for May 24, rollout happens gradually.

So there will be no way of getting Plan B on recent versions using any API.
Incidentally, you can still change the default SDP semantics (what you get 
when it is not overriden by the sdpSemantics API) using a command line flag 
*if* you're launching Chrome from a command line:
--disable-features=RTCUnifiedPlanByDefault
Obviously this is not something normal web users would do (and it would 
affect all websites) so I'm not sure this helps, but FYI that exists in 
case you're in control of the user's environment.

Also as a side note - the exact removal timeline is a little different on 
CrOS than other platforms due to a bug in a dependency, but CrOS is also 
sensitive to trial ending and the trial not existing in M102. More info at 
https://crbug.com/1327544.

On Thursday, May 19, 2022 at 10:36:56 PM UTC+2 luk19...@gmail.com wrote:

> Hi,
>
> Continue V Chang's Problem.
> Our video system still uses Plan B SDP, and we find that if we use 
> chrome(M89), the video still can work normally now
> So, if we don't upgrade the browser, will it be affected after May 25th? 
> It's very important for us, I am looking forward to your reply, thank you!
>
> V Chang 在 2022年5月13日 星期五上午12:59:28 [UTC+8] 的信中寫道：
>
>> Hi Henrik,
>>
>> Yes. We have an big issue on fixing the problem to run without this 
>> trial, which will cause our end users not be able to make video call to 
>> call center for banking service. 
>> We are still working on fixing the problem. However, we cannot make it 
>> before May 25th. Is there any alternative? Thanks!
>>
>>
>> Henrik Boström 在 2022年5月12日 星期四下午2:26:43 [UTC+8] 的信中寫道：
>>
>>> UMAs show Plan B usage is down to 0.0473% and we already extended 
>>> the deprecation trial by 6 months for those who did not notice the 1 year 
>>> warning/canary exception prior to that. Because of this, support for Plan B 
>>> including the Plan B deprecation trial flag was removed in M102 which is 
>>> currently Beta and soon getting its Stable cut.
>>>
>>> Big issue? Are you not able to migrate in time?
>>>
>>> On Thu, 12 May 2022 at 04:47, V Chang  wrote:
>>>
 [Urgent Support]
 Hi, 
 Is there any possibility to extend the Trial for RTCPeerConnection Plan 
 B SDP Semantics?
 We are helping our client on the call center video solution. However, 
 we have a big issue regarding this trial support end on May 25th 2022.  
 Please advise. Thank you for your support in advance.



 Web Development 在 2021年12月17日 星期五上午12:22:55 [UTC+8] 的信中寫道：

> I registered for  RTCPeerConnection Plan B SDP Semantics   and 
> everything working fine in windows and android chrome browser.
> But  in android webView it showing Origin trial "UNKNOWN 
> ValidTokenNotProvided"
> Does it support in android system webview?
>
> On Friday, July 30, 2021 at 2:25:18 AM UTC+5:30 mike...@chromium.org 
> wrote:
>
>> Hi Abhi,
>>
>> Assuming you're looking for the deprecation trial ("reverse origin 
>> trial") for Plan B SDP semantics, 
>> https://developer.chrome.com/origintrials/#/view_trial/3892235977954951169
>>  
>> should be the right link.
>>
>> (there's no visual differentiation between regular and deprecation 
>> trials in the UI, but maybe that would be a nice feature to add)
>>
>> later,
>> Mike
>>
>> On 7/29/21 3:44 AM, 'Abhi Shanmu' via blink-dev wrote:
>>
>> Hi, 
>>
>> I am unable to find reverse origin trial listed in this page for me 
>> to register. 
>> https://developer.chrome.com/origintrials/#/trials/active
>> How can I register my domains for the reverse origin trial?
>> Thanks,
>> Abhi
>> On Thursday, July 8, 2021 at 5:00:06 PM UTC+1 Yash Gogia wrote:
>>
>>> Hi,
>>>
>>> The guide that talks about origin trials, mentions that there is a 
>>> built-in safeguard that automatically disables an experimental feature 
>>> globally if its usage exceeds