[blink-dev] Intent to Prototype: WebAuthn remote desktop support

['Martin Kreichgauer' via blink-dev]

Contact emailsmarti...@google.com

Explainer
https://github.com/w3c/webauthn/wiki/Explainer:-Remote-Desktop-Support

Specificationhttps://w3c.github.io/webauthn/

Summary

Allow remote desktop clients to execute WebAuthn requests on behalf of
another origin so that users browsing on a remote desktop host or virtual
machine can use WebAuthn in those environments.


Blink componentBlink>WebAuthentication


Motivation

Users may want to browse websites that require WebAuthn for authentication
on a computer that they can't access physically, like a remote desktop
server or a virtual machine. If the remote desktop client is a native app,
they can potentially accomplish this already by forwarding raw device
access to a USB security key from the local machine to the remote one. This
isn't possible for web-based clients however. This feature would enable a
web-based remote desktop client, that is explicitly trusted by the user or
their enterprise administrator, to make WebAuthn requests on behalf of
another site authenticating the user on a remote host.


Initial public proposalhttps://github.com/w3c/webauthn/issues/1577

TAG review

TAG review statusPending

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals: (Not an explicit signal of support, but there are various
remote/virtual desktop clients that are implemented as native apps and
support device pass-through, which effectively enables the use case.)

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?



Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?True

Estimated milestones

No milestones specified


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

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/CAB%3DfcEZ6awn%2Bgs_3N9AqLA%2Bvb0V%2B2TKQZXdbNtRV8L_h3LdtZw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[blink-dev] Intent to Experiment: Viewport-height client hint

['Max Curran' via blink-dev]

Contact emails

curran...@chromium.org, ryanst...@chromium.org

Explainer

https://github.com/WICG/responsive-image-client-hints/blob/master/Viewport-Height-Explainer.md

Specification

https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-height

Summary

Currently, Responsive Image Client Hints provide a way for origins to
obtain the viewport’s width. However, no such attribute exists for viewport
height. We’ve observed that to optimize the loading of content that appears
in viewport, it is essential for the origins to adapt HTML response based
on viewport height.


Blink component

Blink>Loader


TAG review

https://github.com/w3ctag/design-reviews/issues/615

TAG review status

Issues addressed

Link to origin trial feedback summary

https://github.com/WICG/responsive-image-client-hints/issues

Risks

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/79)

WebKit: Negative (
https://lists.webkit.org/pipermail/webkit-dev/2020-November/031576.html)
Likely to be neutral based on discussion in
https://github.com/mozilla/standards-positions/issues/79

Web developers: No signals

Other signals:

Activation

None


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?


Goals for experimentation

Client hints opt-ins from origins are session-sticky which makes it
difficult to experiment with using origin trials since origin trials
operate at document-level. We plan to run an A/B experiment using Chrome’s
field trial infrastructure. Our plan is to enable the feature for at most
1% users to collect metrics, and ship this feature only if it shows
performance improvement for origins that choose to use this feature.


Reason this experiment is being extended

Due to Chrome approvals taking longer than expected, and partners still
needing to implement how to use the client hint, we have not been able to
experiment yet. We would like to extend the origin trial from M101 to M104.

Ongoing technical constraints

Debuggability

N/A


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests

?

Yes

Flag name

kViewportHeightClientHintHeader

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1184863

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1184862

Estimated milestones

OriginTrial desktop last

101 → 104

OriginTrial desktop first

99

OriginTrial android last

101 → 104

OriginTrial android first

99



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5646861215989760

Links to previous Intent discussions

Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Q2wcqY2UyNs/m/rPePdX_NBwAJ


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/CA%2BEneNNpr4CxoeqmHxgyTK3shuoN3f5T6hpfzkoT-zY2wR1SgA%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Add .avif to permitted Web Share file extensions

['Thomas Steiner' via blink-dev]

MDN documents the supported file types (
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share#shareable_file_types).
If AVIF gets added (which, as a user, I would love), the support table on
MDN should be updated accordingly.

Thanks,
Tom

-- 
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/CALgRrL%3D6tUAk%2B_gupFD4C6WnKuEKPx8Q-Qdqn3%2BZHr%2BmPg9HDA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

['Titouan Rigoudy' via blink-dev]

Hi all,

Thanks for the timely question, I was about to send an update here.

We have fixed nearly all of the blockers identified in the above doc. The
only outstanding issue is the aforementioned crash, which required a bit
more design work than the rest. That work has been completed and CLs to fix
the problem are now in review; they should land shortly and make it in
Chrome 102.

We would like to ship again in Chrome 102 in warning-only mode, just as we
last tried in Chrome 98. Preflights will be sent but their results will not
be enforced. Failed preflights will show warnings in DevTools, but requests
will otherwise continue unimpeded.

Things will stay that way for at least 3 milestones. We will gather
compatibility data by monitoring failed preflights, then circle back here
to garner approvals to turn on enforcement. That launch will be accompanied
by a deprecation trial for web developers to sign up for a time extension
if they failed to notice the warnings in time.

Cheers,
Titouan

On Wed, Apr 6, 2022 at 3:29 AM Logan Wei  wrote:

> Hello,  is there now an updated timeline to roll out this change?  Will
> the trial restart in Chrome 102 or a later version?
>
> On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:
>
>> Hi all,
>>
>> Here's the promised doc:
>> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>> (public, comment access for committers only)
>>
>> Cheers,
>> Titouan
>>
>> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  wrote:
>>
>>> Thanks for the update Titouan. Looking forward to reading your doc.
>>>
>>> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>>>
>>> Hi all,
>>>
>>> Just to let you know that due to a couple issues, chief among which a
>>> renderer crash (crbug.com/1279376), we are rolling this feature back
>>> from Chrome 98.
>>>
>>> A few issues have been identified and will block our next attempt at
>>> shipping this. In the meantime, we gathered some useful information about
>>> impact and notified developers of the upcoming change. I'll write a doc
>>> summarizing the timeline and lessons learned, then share as appropriate
>>> here.
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson 
>>> wrote:
>>>
 LGTM3 for step 1.

 On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor 
 wrote:

> LGTM2 for step 1.
>
> On 12/6/21 5:31 AM, Titouan Rigoudy wrote:
>
> *assuming I get 2 more LGTMs, that is.
>
> On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy 
> wrote:
>
>> Thanks! I'll come back for further discussion with UKM data in hand.
>>
>> Cheers,
>> Titouan
>>
>> On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss 
>> wrote:
>>
>>> I agree UKM analysis should not block step 1, as it holds little
>>> risk. (There's still some risks that servers will choke in the face of
>>> preflights, but that seems minor compared to the enforcement risk)
>>>
>>> Therefore,* LGTM1 for step 1* (preflights with no enforcement), but
>>> not further (yet). Please come back to this thread with any data you may
>>> have as a result of adding UKMs.
>>>
>>> On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Yoav, do you think UKM analysis should block sending preflights
 without enforcing their success? I believe sending these will allow us 
 to
 get more precise information on the affected websites through the
 usecounter recorded in crrev.com/c/3310846. I can then analyze UKM
 data and use the results to inform the decision whether and when to
 switch enforcement on?

 Cheers,
 Titouan

 On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy 
 wrote:

> I agree!
>
> Cheers,
> Titouan
>
> On Thu, Dec 2, 2021 at 5:17 PM Mike West 
> wrote:
>
>> _I_ don't think we should do that, but I'd defer to Titouan's
>> preference. :)
>>
>> -mike
>>
>>
>> On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor 
>> wrote:
>>
>>> Thanks - I also don't think there's a lot of value in this
>>> particular header being the odd-one-out, just wanted to confirm 
>>> we're not
>>> going to ship "true" first and try to change that to ?1 later 
>>> (which is
>>> always challenging).
>>>
>>> On 12/2/21 11:11 AM, Mike West wrote:
>>>
>>> I'm not sure it makes sense to introduce a structured header
>>> here, given that it's layering on top of CORS headers that I don't 
>>> think
>>> there's substantial interest in changing.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Dec 2, 2021 at 4:55 PM 'Titouan Rigoudy' via blink-dev <
>>> 

[blink-dev] Intent to Prototype: Add .avif to permitted Web Share file extensions

[Jihwan Kim]

Contact emailsbluewhale.m...@gmail.com, ericwillig...@chromium.org

Explainerhttps://github.com/w3c/web-share/blob/master/docs/explainer.md

Specification

Summary

The .avif image file should be able to be shared by Web Share. Adding avif
to the other allowed image file types will help spread the use of it.


Blink componentBlink


Motivation

A website might like their users to be able to share their pictures and
other files through social media, email, chat, etc. Since Web Share API is
already shipped to more platforms like ChromeOS and Windows, but .avif is
not supported yet. .avif showed better compression efficiency and better
detail preservation than JPEG. In this regard, adding avif to web share
will help spread the use of avif.


Initial public proposal

TAG review

TAG review statusPending

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?



Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

Tracking bughttps://crbug.com/1190122

Estimated milestones

No milestones specified


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

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/CAPJHA1qS0yL8iy7JKiV7osCN63Oica2zcc5D2xwe55enMoektQ%40mail.gmail.com.

[blink-dev] Are you interested in hosting a talk at BlinkOn 16? Sign up now!

[Ashley Haman]

Bcc: blink-dev@ and BlinkOn 16 attendees

TLDR: We're now accepting breakout talk sign ups

through Wednesday, May 4th and lightning talk sign ups

through Wednesday, April 20th for BlinkOn 16 in 1H 2022.

Hi everyone,



BlinkOn 16 is fast approaching, and we're looking forward to hosting you
virtually on May 18-19, 2022 PDT! If you haven't already done so, don't
forget to register now .



Over the next few weeks, we'll be sending you important information, so you
may want to add our email address, blin...@chromium.org, to your contacts.
For starters, please find some information and action items below:



   1.

   Breakout Talks
   1.

  If you'd like to host a 25-minute breakout talk (presentation,
  discussion, etc.), sign up here
  

  by Wednesday, May 4th



   1.

   Lightning Talks
   1.

  If you'd like to host a 3-minute lightning talk, sign up here
  

  by Wednesday, April 20th


If you have any questions, visit chromium.org/events or email us at
blin...@chromium.org.

Thanks,

BlinkOn Planning Committee

-- 
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/CANgQeaDveAdrjZZZN8qxDQ%2BdbJi7bhhQ4rKmqQa8FwKT%3DrbZJg%40mail.gmail.com.

[blink-dev] Re: Intent to Experiment: Network State Partitioning (again)

[Yoav Weiss]

LGTM to experiment M101-M102
On Monday, April 4, 2022 at 7:46:03 PM UTC+2 Mike Taylor wrote:

>
>
>
>
>
>
>
>
>
> * Contact emails brgoldst...@chromium.org , 
> miketa...@chromium.org , mme...@chromium.org 
>   Summary We would like to run another experiment for 
> the Network State Partitioning effort to better understand the performance 
> impacts of double-keying (top frame site) vs triple-keying (top frame site 
> and frame site). I’ve omitted all of the information contained in previous 
> intents that hasn’t changed. Here’s a link to the last (triple-key) I2E 
> .
>  
> Links to previous Intent discussions Intent to prototype: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6KKXv1PqPZ0/m/nm2z5I_MBAAJ
>  
> 
>  
> Intent to Extend Experiment: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/sLC_W6B8big/m/5sk787RQBAAJ
>  
> 
>  
> Intent to Ship: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/tJa6uzXu_IA/m/IN6UhwKtAwAJ
>  
> 
>   
> Blink component Internals>Network 
> 
>  
> Goals for experimentation We want to roll this out to 1% of Stable traffic 
> (i.e., this is not an Origin Trial) to be able to compare to the previous 
> experiment. Estimated milestones We’d like to run at 1% on Stable for ~1 
> milestone (ideally in M101 or perhaps 102 depending the timing of a bug fix 
> ). 
> Tracking bug https://crbug.com/993801  Launch bug 
> https://crbug.com/1166303  Link to entry on the 
> Chrome Platform Status https://chromestatus.com/feature/6713488334389248 
>  *
>

-- 
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/dbc19566-628a-4dde-b7e2-5e66bab5f29cn%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Network Access preflight requests for subresources

[Logan Wei]

Hello,  is there now an updated timeline to roll out this change?  Will the 
trial restart in Chrome 102 or a later version?  

On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote:

> Hi all,
>
> Here's the promised doc: 
> https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit
>  
> (public, comment access for committers only)
>
> Cheers,
> Titouan
>
> On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor  wrote:
>
>> Thanks for the update Titouan. Looking forward to reading your doc.
>>
>> On 2/17/22 9:25 AM, Titouan Rigoudy wrote:
>>
>> Hi all, 
>>
>> Just to let you know that due to a couple issues, chief among which a 
>> renderer crash (crbug.com/1279376), we are rolling this feature back 
>> from Chrome 98.
>>
>> A few issues have been identified and will block our next attempt at 
>> shipping this. In the meantime, we gathered some useful information about 
>> impact and notified developers of the upcoming change. I'll write a doc 
>> summarizing the timeline and lessons learned, then share as appropriate 
>> here.
>>
>> Cheers,
>> Titouan
>>
>> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM3 for step 1.
>>>
>>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor  wrote:
>>>
 LGTM2 for step 1.

 On 12/6/21 5:31 AM, Titouan Rigoudy wrote:

 *assuming I get 2 more LGTMs, that is.

 On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy  
 wrote:

> Thanks! I'll come back for further discussion with UKM data in hand. 
>
> Cheers,
> Titouan
>
> On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss  
> wrote:
>
>> I agree UKM analysis should not block step 1, as it holds little 
>> risk. (There's still some risks that servers will choke in the face of 
>> preflights, but that seems minor compared to the enforcement risk) 
>>
>> Therefore,* LGTM1 for step 1* (preflights with no enforcement), but 
>> not further (yet). Please come back to this thread with any data you may 
>> have as a result of adding UKMs.
>>
>> On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Yoav, do you think UKM analysis should block sending preflights 
>>> without enforcing their success? I believe sending these will allow us 
>>> to 
>>> get more precise information on the affected websites through the 
>>> usecounter recorded in crrev.com/c/3310846. I can then analyze UKM 
>>> data and use the results to inform the decision whether and when to 
>>> switch enforcement on? 
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy  
>>> wrote:
>>>
 I agree! 

 Cheers,
 Titouan

 On Thu, Dec 2, 2021 at 5:17 PM Mike West  
 wrote:

> _I_ don't think we should do that, but I'd defer to Titouan's 
> preference. :) 
>
> -mike
>
>
> On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor  
> wrote:
>
>> Thanks - I also don't think there's a lot of value in this 
>> particular header being the odd-one-out, just wanted to confirm 
>> we're not 
>> going to ship "true" first and try to change that to ?1 later (which 
>> is 
>> always challenging).
>>
>> On 12/2/21 11:11 AM, Mike West wrote:
>>
>> I'm not sure it makes sense to introduce a structured header 
>> here, given that it's layering on top of CORS headers that I don't 
>> think 
>> there's substantial interest in changing. 
>>
>> -mike
>>
>>
>> On Thu, Dec 2, 2021 at 4:55 PM 'Titouan Rigoudy' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Hi Mike, 
>>>
>>> There is no support for structured headers so far, for 
>>> consistency reasons, and there has been no movement to deprecate 
>>> the "true" 
>>> value for Access-Control-Allow-Credentials. The value of such a 
>>> deprecation 
>>> seems minimal.
>>>
>>> I could pretty easily add support for the structured "?1" value 
>>> on top of the "true" token for the new 
>>> Access-Control-Allow-Private-Network 
>>> header, and specify that, but I'm not sure it would be terribly 
>>> useful. Do 
>>> you think otherwise?
>>>
>>> Cheers,
>>> Titouan
>>>
>>> On Thu, Dec 2, 2021 at 4:45 PM Mike Taylor  
>>> wrote:
>>>
 Hi Titouan,

 I'm curious what the plan is for structured headers. 
 https://github.com/WICG/private-network-access/issues/45 is 
 marked as blocked - has there been other progress or thinking 
 behind the 
 

Re: [blink-dev] Intent to Ship: Add Save Data Client Hint

[Daniel Bratell]

LGTM3

/Daniel

On 2022-03-30 18:03, Chris Harrelson wrote:
LGTM2. Save-Data is already shipped (for a long time), and this seems 
like a step in the right direction, without introducing a new header.


On Wed, Mar 30, 2022 at 5:49 AM Mike West  wrote:

LGTM1.

This approach seems like a pretty reasonable compromise to me,
thanks for iterating on it a bit.

-mike


On Thu, Mar 24, 2022 at 8:59 PM Ari Chivukula
 wrote:

After discussion with @Mike West
 and @Mike Taylor
 the direction is being
changed, and the new approach is:
(1) Keep the existing Save-Data header name
(2) Keep the existing Save-Data value (`on` instead of `?1`)
(3) Keep the existing Save-Data delegation by default to first
and third parties
(4) Keep the existing omission of Save-Data when the
value sent would be the empty string
(5) Add a new permissions policy, CH-Save-Data, which allows
Save-Data delegation to be restricted if desired


https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit
https://github.com/WICG/savedata/pull/5
https://github.com/WICG/client-hints-infrastructure/pull/101

We can revisit re-naming in the future if desired, after this
is launched.

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 16, 2022 at 6:48 AM Ari Chivukula
 wrote:

As for usage, it's hard to gauge because it's sent by
default when Android Lite Mode is on. We're betting on the
limited cases in which it's ever sent going to zero (with
the removal of Android Lite Mode) to facilitate this.

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 16, 2022 at 6:46 AM Ari Chivukula
 wrote:

(1) There's a thought to pipe OS-level data saver
settings into (Sec-CH-)Save-Data, but this work is not
underway as far as I know.

(2) We're not making `Save-Data` subject to
`Sec-CH-Save-Data`'s permissions policy
(`CH-Save-Data`). What I'm saying is that "explicitly
requesting Sec-CH-Save-Data or modifying the
CH-Save-Data permissions policy *will prevent* the old
`Save-Data` header from being sent."

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 16, 2022 at 1:29 AM Mike West
 wrote:

On Tue, Mar 15, 2022 at 7:57 PM Ari Chivukula
 wrote:

(1) Can we omit the header when the value
would be `?0` (false)?

I'm fine with that, and it would be worth
updating the existing client hint standard to
allow the conflation of empty/missing values
in cases where headers are sent by default.
It's not worth the bytes to clarify the header
is empty, especially when it's about saving
data :-P


SGTM. That seems like a reasonable pattern to
document: I filed

https://github.com/WICG/client-hints-infrastructure/issues/99.

(2) Why add this new name if we have the
existing header? Can't we just have the
permission policy apply to the old name?

Chrome on Android is removing 'lite mode',
which is the only case I'm aware of which
causes `Save-Data: on` to be sent. We have a
chance here to add the new name and policy,
then follow up with a removal of the old name
while it's not even being sent. The removal
isn't a part of this intent, but in any case
where `Sec-CH-Save-Data` is explicitly
requested or the `CH-Save-Data` policy is
touched the old `Save-Data` header wouldn't be
sent at all under this intent.


Hrm. This sounds quite different from what was in
the original intent. :) Two followups, if you
don't mind:

1.  Does this intent also introduce a new
triggering mechanism which would cause the header
to be sent? My assumption was that we'd be basing
this on the user's "lite mode" choice. If we're
removing that, what's left?

2.  If you're additionally planning to change
`Save-Data`'s behavior to make 

Re: [blink-dev] Intent to Extend Experiment (2nd): Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Thank you!

On Wed, Apr 6, 2022 at 11:55 PM Yoav Weiss  wrote:

> LGTM to extend the experimentation to M102, given the API changes with
> regards to the BroadcastChannel.
> Please note that this experiment is reaching the typical time limits of
> OTs, and experimentation beyond that would require significant
> justification and 3 LGTMs.
>
> On Wed, Apr 6, 2022 at 4:48 PM Hiroki Nakagawa 
> wrote:
>
>> Hi Yoav,
>>
>> The requested timeline is from M101 to M102. The current timeline is from
>> M94 to M100, and the experiment is still running
>>
>> On Wed, Apr 6, 2022 at 11:39 PM Yoav Weiss 
>> wrote:
>>
>>> What's the requested timeline for experimentation? Is the experiment
>>> currently still running?
>>>
>>> On Mon, Apr 4, 2022 at 4:42 PM Hiroki Nakagawa 
>>> wrote:
>>>
 Contact emails

 nhir...@chromium.org, navigation-...@chromium.org

 Explainer

 This feature:
 
 https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md

 This trial:
 https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md

 Larger project:
 
 https://github.com/WICG/nav-speculation/blob/main/README.md

 Specification

 https://wicg.github.io/nav-speculation/prerendering.html

 Design docs


 https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing

 Summary

 Prerendering loads a web page before it is needed, so that when the
 actual navigation to that page occurs, it can be shown instantly. See the 
 previous
 intent
 
 for details of the feature.



 

 - A partner finished an experiment and confirmed that latency on their
 service is reduced by 45%.

 - The intent-to-ship for Omnibox prerendering
 
 is approved. This is a different prerendering trigger, but the underlying
 prerendering system and the specifications are common. We’re also going to
 send the intent-to-ship for speculation rules prerendering soon.

 - We’d like to extend the experiment to address issues raised in the
 intent-to-ship for Omnibox prerendering (e.g., BroadcastChannel in
 prerendered pages) and verify changes merged after the last milestone of
 the experiment (M100).

 Blink component

 Internals>Preload>Prerender
 

 TAG review

 https://github.com/w3ctag/design-reviews/issues/667

 TAG review status

 Pending

 Risks

 No updates. See the previous intent
 
 .

 Goals for experimentation

 To evaluate how the prerendering feature works on real sites before
 shipping it by default. This is a large feature and it's risky to ship
 without trying it first on real sites. We will be evaluating performance,
 stability, and correctness, and any other feedback the sites have when they
 use this feature.

 Reason this experiment is being extended

 We’d like to extend the experiment to address issues raised in the
 intent for Omnibox prerendering and verify changes merged after the last
 milestone of the experiment (M100).

 Ongoing technical constraints

 None

 Debuggability

 Currently DevTools does not work for prerendered pages. On activation,
 DevTools must be closed and reopened in order to inspect the page. We have
 plans to add DevTools support for prerendering. A meta bug for this work is
 at https://crbug.com/1217029.



 As a very small support, prerendered pages are visible in
 chrome://process-internals. Also final results of prerendering are shown in
 chrome://histograms.



 

 We started implementing the DevTools support for prerendering. As a
 first step, we will expose prerender activation/cancellation result to the
 DevTools (https://crbug.com/1249776)

 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 No. This feature is only supported on Android at first. As the feature
 is a cross-cutting one, where almost all of Chrome's features must be
 potentially taught 

[blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

Contact emails

aric...@chromium.org, miketa...@chromium.org

Specification

https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute

Summary

When cookies are set with an explicit Expires/Max-Age attribute the value
will now be capped to no more than 400 days in the future. Previously,
there was no limit and cookies could expire multiple millennia in the
future.



Blink component

Internals>Network>Cookies




Motivation

The draft of rfc6265bis

now contains an upper limit for Cookie Expires/Max-Age attributes. As
written:

`The user agent MUST limit the maximum value of the [Max-Age/Expiration]
attribute. The limit MUST NOT be greater than 400 days (3456 seconds)
in duration. The RECOMMENDED limit is 400 days in duration, but the user
agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that
are greater than the limit MUST be reduced to the limit.`



400 days was chosen as a round number close to 13 months in duration. 13
months was chosen to ensure that sites one visits roughly once a year
(e.g., picking health insurance benefits) will continue to work.



According to measurements in Chrome, of all cookies set, about 20% have an
Expires/Max-Age further than 400 days in the future. Of that 20%: half
target 2 years, a quarter target 10 years or more, and the remainder are
spread over the rest of the range.

TAG review

Just an FYI  (this is
a small change that has already landed in the draft spec and has support
from other browsers, but we'll send an FYI issue to the TAG).

Compatibility

Existing cookies will not expire sooner, but any attempts to update/re-set
them will limit the new expiration date to 400 days at most.


Interoperability

Safari is already partially compliant (it an upper age limit of 7 days when
cookies are set client side but no limit when set by the server), while
Firefox and Chrome both support cookies with expiration dates orders of
magnitude longer than a millenia in the future.

Gecko: Positive 

WebKit: Positive


Web developers: None Yet, but attempting to gather some
.

Debuggability

Attempts to set cookies with lifetimes past 400 days will be highlighted in
the Issues tab

.

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

There’s some
,
but more will be added once testdriver.js supports it
.

Tracking bug

https://crbug.com/1264458

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4887741241229312

-- 
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/CAGpy5DJdgcDqgJQOq%3DHdvLzMV%2BRupiW7Wqv2swPco%2BQzWtziSQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment (2nd): Same-origin prerendering triggered by the speculation rules API

[Yoav Weiss]

LGTM to extend the experimentation to M102, given the API changes with
regards to the BroadcastChannel.
Please note that this experiment is reaching the typical time limits of
OTs, and experimentation beyond that would require significant
justification and 3 LGTMs.

On Wed, Apr 6, 2022 at 4:48 PM Hiroki Nakagawa  wrote:

> Hi Yoav,
>
> The requested timeline is from M101 to M102. The current timeline is from
> M94 to M100, and the experiment is still running
>
> On Wed, Apr 6, 2022 at 11:39 PM Yoav Weiss  wrote:
>
>> What's the requested timeline for experimentation? Is the experiment
>> currently still running?
>>
>> On Mon, Apr 4, 2022 at 4:42 PM Hiroki Nakagawa 
>> wrote:
>>
>>> Contact emails
>>>
>>> nhir...@chromium.org, navigation-...@chromium.org
>>>
>>> Explainer
>>>
>>> This feature:
>>> 
>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>>
>>> This trial:
>>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>>
>>> Larger project:
>>> 
>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>>
>>> Summary
>>>
>>> Prerendering loads a web page before it is needed, so that when the
>>> actual navigation to that page occurs, it can be shown instantly. See the 
>>> previous
>>> intent
>>> 
>>> for details of the feature.
>>>
>>>
>>>
>>> 
>>>
>>> - A partner finished an experiment and confirmed that latency on their
>>> service is reduced by 45%.
>>>
>>> - The intent-to-ship for Omnibox prerendering
>>> 
>>> is approved. This is a different prerendering trigger, but the underlying
>>> prerendering system and the specifications are common. We’re also going to
>>> send the intent-to-ship for speculation rules prerendering soon.
>>>
>>> - We’d like to extend the experiment to address issues raised in the
>>> intent-to-ship for Omnibox prerendering (e.g., BroadcastChannel in
>>> prerendered pages) and verify changes merged after the last milestone of
>>> the experiment (M100).
>>>
>>> Blink component
>>>
>>> Internals>Preload>Prerender
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/667
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> No updates. See the previous intent
>>> 
>>> .
>>>
>>> Goals for experimentation
>>>
>>> To evaluate how the prerendering feature works on real sites before
>>> shipping it by default. This is a large feature and it's risky to ship
>>> without trying it first on real sites. We will be evaluating performance,
>>> stability, and correctness, and any other feedback the sites have when they
>>> use this feature.
>>>
>>> Reason this experiment is being extended
>>>
>>> We’d like to extend the experiment to address issues raised in the
>>> intent for Omnibox prerendering and verify changes merged after the last
>>> milestone of the experiment (M100).
>>>
>>> Ongoing technical constraints
>>>
>>> None
>>>
>>> Debuggability
>>>
>>> Currently DevTools does not work for prerendered pages. On activation,
>>> DevTools must be closed and reopened in order to inspect the page. We have
>>> plans to add DevTools support for prerendering. A meta bug for this work is
>>> at https://crbug.com/1217029.
>>>
>>>
>>>
>>> As a very small support, prerendered pages are visible in
>>> chrome://process-internals. Also final results of prerendering are shown in
>>> chrome://histograms.
>>>
>>>
>>>
>>> 
>>>
>>> We started implementing the DevTools support for prerendering. As a
>>> first step, we will expose prerender activation/cancellation result to the
>>> DevTools (https://crbug.com/1249776)
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No. This feature is only supported on Android at first. As the feature
>>> is a cross-cutting one, where almost all of Chrome's features must be
>>> potentially taught about prerendered pages, we are starting with a
>>> single platform and expanding later.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 

Re: [blink-dev] Intent to Extend Experiment (2nd): Same-origin prerendering triggered by the speculation rules API

[Hiroki Nakagawa]

Hi Yoav,

The requested timeline is from M101 to M102. The current timeline is from
M94 to M100, and the experiment is still running

On Wed, Apr 6, 2022 at 11:39 PM Yoav Weiss  wrote:

> What's the requested timeline for experimentation? Is the experiment
> currently still running?
>
> On Mon, Apr 4, 2022 at 4:42 PM Hiroki Nakagawa 
> wrote:
>
>> Contact emails
>>
>> nhir...@chromium.org, navigation-...@chromium.org
>>
>> Explainer
>>
>> This feature:
>> 
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>>
>> This trial:
>> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>>
>> Larger project:
>> 
>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>
>> Specification
>>
>> https://wicg.github.io/nav-speculation/prerendering.html
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>>
>> Summary
>>
>> Prerendering loads a web page before it is needed, so that when the
>> actual navigation to that page occurs, it can be shown instantly. See the 
>> previous
>> intent
>> 
>> for details of the feature.
>>
>>
>>
>> 
>>
>> - A partner finished an experiment and confirmed that latency on their
>> service is reduced by 45%.
>>
>> - The intent-to-ship for Omnibox prerendering
>> 
>> is approved. This is a different prerendering trigger, but the underlying
>> prerendering system and the specifications are common. We’re also going to
>> send the intent-to-ship for speculation rules prerendering soon.
>>
>> - We’d like to extend the experiment to address issues raised in the
>> intent-to-ship for Omnibox prerendering (e.g., BroadcastChannel in
>> prerendered pages) and verify changes merged after the last milestone of
>> the experiment (M100).
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/667
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> No updates. See the previous intent
>> 
>> .
>>
>> Goals for experimentation
>>
>> To evaluate how the prerendering feature works on real sites before
>> shipping it by default. This is a large feature and it's risky to ship
>> without trying it first on real sites. We will be evaluating performance,
>> stability, and correctness, and any other feedback the sites have when they
>> use this feature.
>>
>> Reason this experiment is being extended
>>
>> We’d like to extend the experiment to address issues raised in the intent
>> for Omnibox prerendering and verify changes merged after the last milestone
>> of the experiment (M100).
>>
>> Ongoing technical constraints
>>
>> None
>>
>> Debuggability
>>
>> Currently DevTools does not work for prerendered pages. On activation,
>> DevTools must be closed and reopened in order to inspect the page. We have
>> plans to add DevTools support for prerendering. A meta bug for this work is
>> at https://crbug.com/1217029.
>>
>>
>>
>> As a very small support, prerendered pages are visible in
>> chrome://process-internals. Also final results of prerendering are shown in
>> chrome://histograms.
>>
>>
>>
>> 
>>
>> We started implementing the DevTools support for prerendering. As a first
>> step, we will expose prerender activation/cancellation result to the
>> DevTools (https://crbug.com/1249776)
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No. This feature is only supported on Android at first. As the feature
>> is a cross-cutting one, where almost all of Chrome's features must be
>> potentially taught about prerendered pages, we are starting with a
>> single platform and expanding later.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Partially tested [cs
>> ].
>> We’re now upstreaming wpt_internals/ tests [doc
>> 
>> ].
>>
>> Flag name
>>
>> Prerender2
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> 

Re: [blink-dev] Intent to Extend Experiment (2nd): Same-origin prerendering triggered by the speculation rules API

[Yoav Weiss]

What's the requested timeline for experimentation? Is the experiment
currently still running?

On Mon, Apr 4, 2022 at 4:42 PM Hiroki Nakagawa  wrote:

> Contact emails
>
> nhir...@chromium.org, navigation-...@chromium.org
>
> Explainer
>
> This feature:
> 
> https://github.com/WICG/nav-speculation/blob/main/same-origin-explainer.md
>
> This trial:
> https://github.com/WICG/nav-speculation/blob/main/same-origin-chrome-origin-trial.md
>
> Larger project:
> 
> https://github.com/WICG/nav-speculation/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/nav-speculation/prerendering.html
>
> Design docs
>
>
> https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit?usp=sharing
>
> Summary
>
> Prerendering loads a web page before it is needed, so that when the actual
> navigation to that page occurs, it can be shown instantly. See the previous
> intent
> 
> for details of the feature.
>
>
>
> 
>
> - A partner finished an experiment and confirmed that latency on their
> service is reduced by 45%.
>
> - The intent-to-ship for Omnibox prerendering
> 
> is approved. This is a different prerendering trigger, but the underlying
> prerendering system and the specifications are common. We’re also going to
> send the intent-to-ship for speculation rules prerendering soon.
>
> - We’d like to extend the experiment to address issues raised in the
> intent-to-ship for Omnibox prerendering (e.g., BroadcastChannel in
> prerendered pages) and verify changes merged after the last milestone of
> the experiment (M100).
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/667
>
> TAG review status
>
> Pending
>
> Risks
>
> No updates. See the previous intent
> 
> .
>
> Goals for experimentation
>
> To evaluate how the prerendering feature works on real sites before
> shipping it by default. This is a large feature and it's risky to ship
> without trying it first on real sites. We will be evaluating performance,
> stability, and correctness, and any other feedback the sites have when they
> use this feature.
>
> Reason this experiment is being extended
>
> We’d like to extend the experiment to address issues raised in the intent
> for Omnibox prerendering and verify changes merged after the last milestone
> of the experiment (M100).
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> Currently DevTools does not work for prerendered pages. On activation,
> DevTools must be closed and reopened in order to inspect the page. We have
> plans to add DevTools support for prerendering. A meta bug for this work is
> at https://crbug.com/1217029.
>
>
>
> As a very small support, prerendered pages are visible in
> chrome://process-internals. Also final results of prerendering are shown in
> chrome://histograms.
>
>
>
> 
>
> We started implementing the DevTools support for prerendering. As a first
> step, we will expose prerender activation/cancellation result to the
> DevTools (https://crbug.com/1249776)
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No. This feature is only supported on Android at first. As the feature is
> a cross-cutting one, where almost all of Chrome's features must be
> potentially taught about prerendered pages, we are starting with a single
> platform and expanding later.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Partially tested [cs
> ].
> We’re now upstreaming wpt_internals/ tests [doc
> 
> ].
>
> Flag name
>
> Prerender2
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1126305
>
> Launch bug
>
> https://crbug.com/1167987
>
> Estimated milestones
>
> The initial experiment timeline: M94 to M98 [I2E
> 
> ]
>
> The previous extended timeline: M99 to M100 [I2EE
>