Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

[Marcos Caceres]

On Wednesday, March 20, 2024 at 4:57:56 AM UTC+11 Sanket Joshi (Edge) wrote:

Hi Marcos,

The spec for the writing suggestions attribute 
 doesn't specify how UAs 
should implement writing suggestions under the hood, it just aims to 
provide developers with a way to control whether the writing suggestions 
are shown on their site or not. 


Right, but I think what we missed in the spec is describing how this plays 
with input events, and composition events, which is where this is now 
causing issues. 
 

I don't think this attribute or its on-by-default state carries inherent 
compat risk. 


It might if the predictive text fires events and participates in the DOM 
(as it does in WebKit). 
 

I think any compat issues/quirks would depend on the implementation of 
writing suggestions, which will vary from browser to browser. I responded 
in the Github issue too, but we'll likely need to get to the bottom of what 
is breaking those sites with Safari's implementation of writing 
suggestions. We can continue discussions on Github.


Yes, let's do that. Just think that because we didn't discuss input and 
composition events as part of standardization, we might have overlooked 
this aspect. 

Again, it depends on how this is implemented... like floating bubbles 
on-top of text might not fire events... but combining this with input and 
composition events seems to have issues. We might have been overly 
ambitious on the WebKit side making it participate in the composition / 
event set of events, but not sure. 
 


Thanks,
Sanket
On Tuesday, March 19, 2024 at 12:02:18 AM UTC-7 yoav...@chromium.org wrote:

Thanks for the heads up, Marcos! :)

On Tue, Mar 19, 2024 at 3:51 AM Marcos Caceres  wrote:

Hi Blink-Dev Friends!

We (WebKit) hit some web compat issues with this feature while testing our 
implementation is Safari Tech Preview. 

Could you please take a look at:
https://github.com/whatwg/html/issues/10209

And see if there is a way to leave this on by default somehow without 
affecting websites? 

Looking forward to discussions. 
Marcos 

On Friday, March 15, 2024 at 9:29:19 AM UTC+11 sligh...@chromium.org wrote:

LGTM3

On Thursday, March 14, 2024 at 2:59:45 PM UTC-7 Mike Taylor wrote:

LGTM2
On 3/14/24 12:43 AM, Domenic Denicola wrote:

Awesome! LGTM1.

On Thu, Mar 14, 2024 at 1:35 PM 'Stephanie Zhang' via blink-dev <
blin...@chromium.org> wrote:

Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name" 
field to kWritingSuggestions and removed the "Non-finch justification" 
field. 

On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola wrote:

On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
blin...@chromium.org> wrote:

We do have a runtime feature flag 'WritingSuggestions 
'.
 
We didn't think a Finch Trial was necessary, as the bulk of the changes were 
just adding the attribute and IDL functions 
. Since 
everything is implemented on the blink side, is a Finch feature flag still 
necessary? If it is, then I'll add that flag :)


A runtime feature flag automatically generates 

 
a Finch flag, unless you turn that off :). So I think this is just a matter 
of updating the Chrome Status entry.
 


On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:



On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:

*Contact emails*
*sa...@microsoft.com*, *dan...@microsoft.com*, 
*stephanie.zh...@microsoft.com*

*Explainer*
*https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
 


*Specification*
*https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions* 


*Summary*
UAs are starting to provide writing suggestions to users as they type on 
various editable fields across the web. While this is generally useful for 
users, there are cases when developers may want to turn off UA-provided 
writing assistance, such as extensions or sites that wish to provide 
similar functionality on their own. To that end, developers need a solution 
that would turn on/off UA-provided writing assistance. The new attribute 
'writingsuggestions' has values 'true'/'false' that would allow developers 
to turn on/off browser-provided writing suggestions. The attribute's state 
for an element can also be inherited from ancestor elements, thereby 
allowing developers to control this functionality at a per-element or 
per-

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

[Daniel Bratell]

LGTM3

/Daniel

On 2024-03-20 23:54, Mike Taylor wrote:


LGTM2. Good luck!

On 3/20/24 4:30 PM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Mar 20, 2024 at 8:35 PM David Adrian  wrote:

> What's our plan to mitigate that risk? Slow rollout? Enterprise
policy? Both? Something else entirely?

We also worked with a variety of vendors to fix incompatibilities
that were brought to our attention, including Vercel, ZScaler,
and PayPal CN (who have all since patched prior to any level of
stable deployment).

> I'll LGTM once the review gates are flipped

Ack.
On Wednesday, March 20, 2024 at 1:58:33 AM UTC-4
yoav...@chromium.org wrote:

On Tue, Mar 19, 2024 at 10:23 PM David Benjamin
 wrote:

> I'm guessing we're talking about MITM middleboxes, is
that correct?
> What's our plan to mitigate that risk? Slow rollout?
Enterprise policy? Both? Something else entirely?

Whether the middlebox MITMs the TLS connection is not
terribly important. As long as they attempt to parse the
ClientHello, they will need to handle the larger
ClientHellos. They already do in that there's nothing
stopping session tickets, etc., making the ClientHello
large already, but Kyber makes it more likely.

We have already done a slow rollout. This has been
running on 10% stable for several months now, and so far
things seem to be fine. Some initial compat problems, but
largely fixed now. We're far, far, /far/ past the point
that there's nothing more we can smoke out without
proceeding to 100%.

And, yeah, the plan to mitigate the remaining risk is an
enterprise policy, PostQuantumKeyAgreementEnabled, that
admins can set while their middlebox vendors become
post-quantum-ready. The admin policy has been in place
for quite some time now, and has been communicated in
enterprise release notes. Also the presence of any such
incompatibility on an enterprise network blocks
/any/ deployment of post-quantum algorithms, so
ultimately the middleboxes will just need to get fixed.
The various ecosystem pressures towards getting to
post-quantum are particularly strong in enterprise
anyway, so hopefully admins will be more likely to
understand why it's important for them to fix those.

https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled


Makes sense, thanks!!

I'll LGTM once the review gates are flipped.


On Wed, Mar 20, 2024 at 2:34 AM Yoav Weiss (@Shopify)
 wrote:



On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via
blink-dev  wrote:


Contact emails

dad...@google.com


Explainer


https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Specification


https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Summary

Protect current Chrome TLS traffic against future
quantum cryptanalysis by deploying the Kyber768
quantum-resistant key agreement algorithm. This
is a hybrid X25519 + Kyber768 key agreement based
on an IETF standard. This specification and
launch is outside the scope of W3C. This key
agreement will be launched as a TLS cipher, and
should be transparent to users.

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html



Blink component

Internals>Network>SSL




Search tags

tls ,
kem ,
kyber
,
postquantum



TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Post-quantum secure ciphers are larger than
classical ciphers. This may cause compatibility
issues with middleboxes.


I'm guessing we're talking about M

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

The privacy/security/enterprise/debuggability gates are requested on Chrome 
Status. Testing gate to be requested later.

"Unimportant" cross origin frames means they are cross-origin, visible but 
use non-large proportion (<75%) of page's visible area and have not 
received a user gesture. All 3 conditions should be met. The criteria are 
too long so we use "unimportant" concept here.

This intervention is spec-compliant. The spec mentions "the 
SetTimeout/SetInterval API does not guarantee that timers will run exactly 
on schedule. Delays due to CPU load, other tasks, etc, are to be expected". 
The wait length of time is implementation-defined, "which is intended to 
allow user agents to pad timeouts as needed to optimize the power usage of 
the device". In Safari, DOM timers of non-interacted cross origin frames 
are aligned to 30ms after reaching max nesting level (>=5). In Firefox, all 
DOM timers of frames (both same origin and cross origin) are aligned to 
16ms. See details in "Interoperability and Compatibility Risks", "Safari 
views", "Firefox views".
On Thursday, March 21, 2024 at 1:27:16 AM UTC+8 mike...@chromium.org wrote:

> You should be able to see all the various bits for approvals in your 
> chromestatus entry now, can you fill them out please?
>
> There have been a few questions/comments about the lack of clarity of what 
> "unimportant cross-origin frames" are. What exactly is the definition? You 
> mention that Safari has a similar intervention - how similar is it? Do we 
> know? I wonder if there is alignment for this "unimportant cross-origin 
> frame" concept, if we shouldn't specify that somehow.
> On 3/15/24 2:58 AM, Zheda Chen wrote:
>
> *Intent to Ship: Add JavaScript timer wake up alignment for unimportant 
> cross-origin frames*
>
> Contact emails
> zheda...@intel.com, fdo...@chromium.org
>
> Specification
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>
> Summary 
>
> Align wake ups of JavaScript timers for unimportant cross-origin frames. 
> Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to 
> performance concerns. This is very conservative and actually some 
> unimportant frames are eligible to use JS timer alignment. WebKit uses the 
> policy to align DOM timer of non-interacted cross origin frames to 30ms. 
> This feature adds JavaScript timer wake up alignment for unimportant frames 
> on foreground pages. Unimportant frames means they are cross origin, 
> visible but have non-large proportion of page’s visible area, and have no 
> user interaction. The alignment interval is 32ms. [1] 
> https://chromium-review.googlesource.com/c/chromium/src/+/4589092
>
>
> Blink component
> Blink>PerformanceAPIs>Timers 
> 
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> "Other vendors already have interoperable implementation" Safari has a 
> similar intervention. DOM timers of non-interacted cross origin frames are 
> aligned to 30ms. In Firefox, all DOM timers (both same-origin and 
> cross-origin) in foreground pages would be aligned to 16ms. "A mature 
> specification in the relevant standards body" This intervention is 
> spec-compliant. The spec mentions "the SetTimeout/SetInterval API does not 
> guarantee that timers will run exactly on schedule. Delays due to CPU load, 
> other tasks, etc, are to be expected. ". The wait length of time is 
> implementation-defined, "which is intended to allow user agents to pad 
> timeouts as needed to optimize the power usage of the device. " 
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html "A 
> shared test suite for that specification" It isn't clear what should be 
> tested specifically for this intervention since the spec allows waiting for 
> an "implementation-defined" length.
>
>
> *Gecko*: Shipped/Shipping
> In Firefox, all DOM timers of frames (both same origin and cross origin) 
> are aligned to 16ms
>
> *WebKit*: Shipped/Shipping
> In Safari, DOM timers of non-interacted cross origin frames are aligned to 
> 30ms after reaching max nesting level (>=5)
>
> *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?
>
> None
>
>
> Debuggability 
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?
> Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
> Yes 
>
> This intervention doesn't require changes to the spec. Timers are already 
> covered by Web Platform Tests.
>
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> ThrottleUnimportant

Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

[Yoav Weiss (@Shopify)]

On Thu, Mar 21, 2024 at 8:07 AM Marcos Caceres  wrote:

>
>
> On Wednesday, March 20, 2024 at 4:57:56 AM UTC+11 Sanket Joshi (Edge)
> wrote:
>
> Hi Marcos,
>
> The spec for the writing suggestions attribute
>  doesn't specify how
> UAs should implement writing suggestions under the hood, it just aims to
> provide developers with a way to control whether the writing suggestions
> are shown on their site or not.
>
>
> Right, but I think what we missed in the spec is describing how this plays
> with input events, and composition events, which is where this is now
> causing issues.
>

Once the dust settles and we understand why this is causing issues in
WebKit, and if/how the Edge implementation has avoided those issues, it'd
make sense to revisit the spec here and codify what implementers should be
doing to avoid such issues, and ensure interoperability. (either as a note,
or as part of the normative spec language, depending on what the
investigation would come up with)


>
> I don't think this attribute or its on-by-default state carries inherent
> compat risk.
>
>
> It might if the predictive text fires events and participates in the DOM
> (as it does in WebKit).
>
>
> I think any compat issues/quirks would depend on the implementation of
> writing suggestions, which will vary from browser to browser. I responded
> in the Github issue too, but we'll likely need to get to the bottom of what
> is breaking those sites with Safari's implementation of writing
> suggestions. We can continue discussions on Github.
>
>
> Yes, let's do that. Just think that because we didn't discuss input and
> composition events as part of standardization, we might have overlooked
> this aspect.
>
> Again, it depends on how this is implemented... like floating bubbles
> on-top of text might not fire events... but combining this with input and
> composition events seems to have issues. We might have been overly
> ambitious on the WebKit side making it participate in the composition /
> event set of events, but not sure.
>
>
>
> Thanks,
> Sanket
> On Tuesday, March 19, 2024 at 12:02:18 AM UTC-7 yoav...@chromium.org
> wrote:
>
> Thanks for the heads up, Marcos! :)
>
> On Tue, Mar 19, 2024 at 3:51 AM Marcos Caceres  wrote:
>
> Hi Blink-Dev Friends!
>
> We (WebKit) hit some web compat issues with this feature while testing our
> implementation is Safari Tech Preview.
>
> Could you please take a look at:
> https://github.com/whatwg/html/issues/10209
>
> And see if there is a way to leave this on by default somehow without
> affecting websites?
>
> Looking forward to discussions.
> Marcos
>
> On Friday, March 15, 2024 at 9:29:19 AM UTC+11 sligh...@chromium.org
> wrote:
>
> LGTM3
>
> On Thursday, March 14, 2024 at 2:59:45 PM UTC-7 Mike Taylor wrote:
>
> LGTM2
> On 3/14/24 12:43 AM, Domenic Denicola wrote:
>
> Awesome! LGTM1.
>
> On Thu, Mar 14, 2024 at 1:35 PM 'Stephanie Zhang' via blink-dev <
> blin...@chromium.org> wrote:
>
> Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name"
> field to kWritingSuggestions and removed the "Non-finch justification"
> field.
>
> On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola wrote:
>
> On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <
> blin...@chromium.org> wrote:
>
> We do have a runtime feature flag 'WritingSuggestions
> '.
> We didn't think a Finch Trial was necessary, as the bulk of the changes were
> just adding the attribute and IDL functions
> .
> Since everything is implemented on the blink side, is a Finch feature flag
> still necessary? If it is, then I'll add that flag :)
>
>
> A runtime feature flag automatically generates
> 
> a Finch flag, unless you turn that off :). So I think this is just a matter
> of updating the Chrome Status entry.
>
>
>
> On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic Denicola wrote:
>
>
>
> On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:
>
> *Contact emails*
> *sa...@microsoft.com*, *dan...@microsoft.com*,
> *stephanie.zh...@microsoft.com*
>
> *Explainer*
>
> *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md*
> 
>
> *Specification*
>
> *https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions*
> 
>
> *Summary*
> UAs are starting to provide writing suggestions to users as they type on
> various editable fields across the web. While this

[blink-dev] Intent to Prototype: FedCM as a trust signal for the Storage Access API

[Johann Hofmann]

Contact emails

johann...@chromium.org, cfred...@chromium.org, y...@chromium.org

Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm

Specification

None

Summary

Reconciles the Federated Credential Management (FedCM) and Storage Access
APIs by making a prior permission grant via FedCM a valid reason to
automatically approve a storage access request.

When a user grants permissions to using their identity with a 3rd party
Identity Provider (IdP) on a Relying Party (RP), many IdPs require
third-party cookies to function correctly and securely. This proposal aims
to satisfy that requirement in a private and secure manner by updating the
Storage Access API (SAA) permission checks to not only accept the
permission grant that is given by a storage access prompt, but also the
permission grant that is given by a FedCM prompt.

A key property of this mechanism is limiting the grant to cases explicitly
allowed by the RP via the FedCM identity-credentials-get permissions
policy, enforcing a per-frame control for the RP and preventing passive
surveillance by the IdP beyond the capabilities that FedCM already grants,
as outlined in the Privacy Considerations

of the explainer.


Blink component

Blink>StorageAccessAPI


Motivation

FedCM is an API that mediates federated user identity flows through the
application of (ideally) well-understood, purpose-driven user interfaces.
Using the navigator.credentials API, it exposes a high-entropy user
identifier (token) from an IdP to an RP.

This kind of token-based authentication/authorization is commonly used in
federated identity flows, which FedCM intends to address. Other login
schemes, particularly for Single-Sign-On (SSO), frequently rely on the
presence of (cross-site) cookies.

These kinds of flows can currently be solved by the Storage Access API,
which mediates permission for documents to access cross-site cookies.
However, as SAA lacks additional context on the nature of the request for
cross-site cookie access, its UI in browsers tends to be generic and
unintuitive. It’s also primarily designed to solve use cases for
authenticated embeds, which makes it difficult to fit seamlessly onto SSO
flows (without sacrificing some of the anti-abuse mechanics of SAA such as
the prior user gesture requirement).

Due to its arguably much more intuitive user experience for mediating user
identity, FedCM would be a good fit to cover these login-oriented use cases
instead. To do this, it needs to be compatible with identity flows that
require cookies to work. This is where a well-designed integration with SAA
can help, by providing secure access to cross-site cookies based on FedCM
grants as an additional trust signal.

Initial public proposal

https://github.com/fedidcg/FedCM/issues/467

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None


Gecko: No official signal, positive initial thoughts
.

WebKit: No signal

Web developers: Positive, some public support in FedID CG
 as
well as in direct partner discussions.

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?

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

True

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648

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

Re: [blink-dev] Intent to Extend Experiment: Capture all screens

['Vladimir Levin' via blink-dev]

On Mon, Mar 18, 2024 at 11:17 AM 'Simon Hangl' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello blink-dev,
>
> We’d like to ask for an extension to our Origin Trial, from M124 to M130.
> This is due to a dependency on isolated web apps, which are delayed.
>

The intent process only allows extensions of 3 milestones at a time. It
also requires evidence of substantial progress on the feature. It sounds
like here, the original experiment did not go as planned due to a
dependency. Do you know if the isolated web apps feature is ready now? In
other words, is this dependency satisfied?


> Contact emails
>
> simo...@google.com
>
> Explainer
>
> https://github.com/screen-share/capture-all-screens/blob/main/README.md
>
> Specification
>
> https://screen-share.github.io/capture-all-screens
>
> Design docs
>
> https://screen-share.github.io/capture-all-screens
>
> https://github.com/screen-share/capture-all-screens/blob/main/README.md
>
>
> https://docs.google.com/document/d/13el0NriAUpAzLUw96V7zQiMSjgH9zVaTXUHtuaq8-HI/edit?resourcekey=0-jRPpeLth1odq6M5iFLswig
>
> Summary
>
> Capture all the screens currently connected to the device using
> getAllScreensMedia(). Calling getDisplayMedia() multiple times requires
> multiple user gestures, burdens the user with choosing the next screen each
> time, and does not guarantee to the app that all the screens were selected.
> getAllScreensMedia() improves on all of these fronts. (As this feature has
> extreme privacy ramifications, it is only exposed behind an enterprise
> policy, and users are warned before recording even starts, that recording
> *could* start at some point.)
>
>
> Blink component
>
> Blink>GetDisplayMediaSet
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/856
>
> TAG review status
>
> Complete
>
> Chromium Trial Name
>
> GetAllScreensMedia
>
> Link to origin trial feedback summary
>
> https://github.com/screen-share/capture-all-screens/issues
>
> Origin Trial documentation link
>
> https://github.com/screen-share/capture-all-screens
>
> Risks
>
> Interoperability and Compatibility
>
> This API is only available to origins allowlisted by administrators
> through a policy. The policy itself is non-standard, limiting even
> theoretical interoperability.This API rejects requests from pages that are
> not allow-listed through an administrator. The likelihood of this API being
> adopted by a browser that does not provide administrators mechanisms to
> manage clients is low.
>
>
> Gecko: N/A
>
> WebKit: N/A
>
> Web developers: Positive (
> https://github.com/screen-share/capture-all-screens/issues/9)
>
> Other signals:
>
> Ergonomics
>
> No
>
>
> Activation
>
> The challenge for developers is the limitation of the API to origins
> allowlisted by an enterprise policy.
>
>
> Security
>
> 1. Risk of malicious sites exploiting the API and gaining access to
> sensitive information on users' devices. This risk is mitigated by the API
> only being accessible to origins allowlisted by an enterprise policy.
>
>
> 2. Risk of users loading private information that gets recorded and made
> available to apps affiliated with their device's admin. This risk is
> mitigated by informing users that recording might start at any moment
> before the API becomes accessible. (In CrOS, this warning is delivered in
> the log-in screen, and when users log-in despite the warning, this is
> tantamount to assent.)
>
>
> 3. Risk of users forgetting that their screens are being recorded. This
> risk is mitigated through a persistent notification.
>
>
>
> Goals for experimentation
>
> Learn about the experience of web developers and how this API fulfills
> their needs.
>
> Reason this experiment is being extended
>
> This API will eventually be released for isolated contexts, which are
> delayed. Hence, we are asking for an extension of the origin trial.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> No
>
> This API is initially implemented on CrOS, where demand for it is
> greatest, and where we have the most flexibility in offering users early
> warning that their screens may be recorded if they proceed past the log-in
> screen. Lessons learned from shipping this API on CrOS will be used when
> deciding how to correctly implement such warnings on other platforms.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No, as WPTs don’t support setting of managed policies. The API is tested
> by a number of unit- and browser- tests (Test files
> 
> ).
>
> DevTrial instructions
>
> https://github.com/screen-share/capture-all-screens/blob/main/HOWTO.md
>
> Flag name on chrome://flags
>
> enable-get-all-screens-media
>
> F

Re: [blink-dev] Intent to Ship: Protected Audience: Downsampled forDebugOnly & Increase number of component ads

[Chris Harrelson]

LGTM3

On Wed, Mar 13, 2024 at 9:09 AM Mike Taylor  wrote:

> LGTM2
> On 3/13/24 11:45 AM, Yoav Weiss (@Shopify) wrote:
>
> LGTM1
>
> On Monday, March 11, 2024 at 4:21:36 PM UTC-4 Paul Jensen wrote:
>
> On Wed, Mar 6, 2024 at 12:07 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>
>
> On Mon, Mar 4, 2024 at 7:00 PM Paul Jensen 
> wrote:
>
>
>
> On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>
>
> On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> Contact emails
>
> pauljen...@chromium.org
>
>
> Explainer
>
> Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
>
> Increase number of component ads: https://github.com/WICG/
> turtledove/pull/1003
>
>
> Specification
>
> Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
>
> Increase number of component ads: https://github.com/WICG/
> turtledove/pull/1004
>
>
> Summary
>
> Downsampled forDebugOnly:
>
> The forDebuggingOnly.reportAdAuctionWin() and 
> forDebuggingOnly.reportAdAuctionLoss()
> (fDO) APIs were added to the Protected Audience (PA) API to allow debugging
> from within bidding and scoring scripts in PA auctions.  We originally
> intended to remove these APIs at third-party cookie deprecation (3PCD)
> time, but received feedback that they were essential for doing root cause
> analysis in escalation situations (i.e. critical crash).  Instead of
> removing debug reports entirely, we now plan to heavily downsample them at
> 3PCD time as follows: they will only send a report with a 1/1000
> probability.  Furthermore, if a report is sent, the browser will not send
> another for 3 years (“lockout”), and if a report is not sent (999/1000 of
> the time), future calls to the fDO API from the calling origin will be
> ignored for 2 weeks 90% of the time and 1 year 10% of the time
> (“cooldown”).  To avoid biasing towards new browser installs (which aren’t
> in lockout or cooldown), we may place new browser installs initially in a
> shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO
> caller is in the “lockout” or “cooldown” periods.
>
> Increase number of component ads:
>
> Today, PA allows selection of ads containing 20 component ads (aka product
> level ads).  We plan to increase this number from 20 to 40 as we received
> feedback that ads with higher numbers of components were critical (e.g. for
> ads that rotate through 3 sets of 12 products).
>
>
> Can you expand on the implications of increasing that number? What's the
> tradeoff involved?
>
>
> As discussed on github here
>  and in person here
> ,
> we've heard from adtechs that large portions of their ad inventory cannot
> be displayed without allowing higher numbers of component ads, so
> increasing this number restores more publisher site revenue.  The downsides
> to increasing this number are fairly minor:  There's a negligible privacy
> impact as the component ads are not shared with PA reporting scripts, are
> required to be k-anonymous, and when displayed, each component ad can be
> isolated from each other in separate Fenced Frames.
>
>
> I understand the benefits of increasing the number of ads, but are there
> any pointers to past discussion/analysis RE the privacy impact? I
> understand it's not huge (and it's not my role to judge the privacy risk -
> that's what the privacy review is for). I'd just love to better understand
> this :D
>
>
> WRT the privacy impact, as it's negligible, there isn't much to discuss so
> there isn't much prior discussion/analysis other than in this email thread
> and in the two links I posted before.  If there's some aspect you'd like to
> discuss further or dig into more, I'm happy to engage.
>
>
> Fair enough. I'd have loved more discussion on this, but it's not a
> blocker.
>
>
>
>
>
>
>
>
>
>
>
> Blink component
>
> Blink>InterestGroups
> 
>
>
> TAG review
>
> The parent proposal, Protected Audience, is still pending:
> https://github.com/w3ctag/design-reviews/issues/723
>
>
> TAG review status
>
> Pending
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> Downsampled forDebugOnly: No expected breakage before 3PCD as the
> downsampling will not be performed until then.  For now only the status of
> whether a fDO caller is in the “lockout” or “cooldown” periods is exposed.
> After 3PCD, the downsampling will surely disrupt some potential uses of the
> reporting channel, but this is an essential privacy requirement of the
> Protected Audience API.
>
> Increase number of component ads: This is an increase to the limit, so no
> breakage is expected.

[blink-dev] Intent to Experiment: Skip Preload Scanning

[Alex N. Jose]

Contact emailsale...@chromium.org

Explainer
https://docs.google.com/document/d/1wiaTL5TeONTZamycMVMjo76nMcbhHNYznQy7I_zCVRY/edit?usp=sharing

SpecificationNone

Summary

Skips the PreloadScan step of the browser to explore performance tradeoffs
for pages with no sub-resource fetches. PreloadScan step of Chromium is
implemented as a blocking step that benefits performance of pages with
sub-resource fetches, via implementation of the speculative prefetch.
However, for pages that don’t benefit from this step, i.e., for pages with
no sub-resources, this is additional processing overhead with little
benefit. For advanced web users who would like to benefit by reducing this
overhead, this experiment provides a page-level control to disable the
PreloadScanner. Data collected from this experiment could evaluate if a
modified API or a different implementation of HTMLPreloadScanner would be
helpful.


Blink componentBlink>Loader


TAG reviewNone

TAG review statusPending

Risks


Interoperability and Compatibility

None


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

None


Goals for experimentation



Ongoing technical constraints

None


Debuggability

None


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

Is this feature fully tested by web-platform-tests

?No

No, since in this iteration we don’t have a web exposed API, and the valid
OriginTrial token itself is currently used to trigger the feature. We plan
to fully test the API via web-platform-tests once they are proposed.


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


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

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/CAC6ceCFrGCOFXgV9OuevjgA%2BZgXa-dE%2Bdd8f%2BZ8QC2w-ecAxCw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Skip Preload Scanning

[Mike Taylor]

Hi Alex,

What milestones are you requesting for the Origin Trial?

thanks,
Mike

On 3/21/24 3:18 PM, Alex N. Jose wrote:



Contact emails

ale...@chromium.org


Explainer

https://docs.google.com/document/d/1wiaTL5TeONTZamycMVMjo76nMcbhHNYznQy7I_zCVRY/edit?usp=sharing


Specification

None


Summary

Skips the PreloadScan step of the browser to explore performance 
tradeoffs for pages with no sub-resource fetches. PreloadScan step of 
Chromium is implemented as a blocking step that benefits performance 
of pages with sub-resource fetches, via implementation of the 
speculative prefetch. However, for pages that don’t benefit from this 
step, i.e., for pages with no sub-resources, this is additional 
processing overhead with little benefit. For advanced web users who 
would like to benefit by reducing this overhead, this experiment 
provides a page-level control to disable the PreloadScanner. Data 
collected from this experiment could evaluate if a modified API or a 
different implementation of HTMLPreloadScanner would be helpful.




Blink component

Blink>Loader 




TAG review

None


TAG review status

Pending


Risks



Interoperability and Compatibility

None



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


None



Goals for experimentation



Ongoing technical constraints

None



Debuggability

None



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

No


Is this feature fully tested by web-platform-tests

?

No

No, since in this iteration we don’t have a web exposed API, and the 
valid OriginTrial token itself is currently used to trigger the 
feature. We plan to fully test the API via web-platform-tests once 
they are proposed.




Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5190976638550016

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/CAC6ceCFrGCOFXgV9OuevjgA%2BZgXa-dE%2Bdd8f%2BZ8QC2w-ecAxCw%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/6d9f68ce-2eb4-4989-98ad-ff68603205be%40chromium.org.

Re: [blink-dev] Intent to Experiment: Skip Preload Scanning

[Alex N. Jose]

> What milestones are you requesting for the Origin Trial?
M125 to M131

On Thu, Mar 21, 2024 at 2:44 PM Mike Taylor  wrote:

> Hi Alex,
>
> What milestones are you requesting for the Origin Trial?
>
> thanks,
> Mike
> On 3/21/24 3:18 PM, Alex N. Jose wrote:
>
> Contact emails ale...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1wiaTL5TeONTZamycMVMjo76nMcbhHNYznQy7I_zCVRY/edit?usp=sharing
>
> Specification None
>
> Summary
>
> Skips the PreloadScan step of the browser to explore performance tradeoffs
> for pages with no sub-resource fetches. PreloadScan step of Chromium is
> implemented as a blocking step that benefits performance of pages with
> sub-resource fetches, via implementation of the speculative prefetch.
> However, for pages that don’t benefit from this step, i.e., for pages with
> no sub-resources, this is additional processing overhead with little
> benefit. For advanced web users who would like to benefit by reducing this
> overhead, this experiment provides a page-level control to disable the
> PreloadScanner. Data collected from this experiment could evaluate if a
> modified API or a different implementation of HTMLPreloadScanner would be
> helpful.
>
>
> Blink component Blink>Loader
> 
>
> TAG review None
>
> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *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?
>
> None
>
>
> Goals for experimentation
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)? No
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> No, since in this iteration we don’t have a web exposed API, and the valid
> OriginTrial token itself is currently used to trigger the feature. We plan
> to fully test the API via web-platform-tests once they are proposed.
>
>
> Flag name on chrome://flags None
>
> Finch feature name None
>
> Non-finch justification None
>
> Requires code in //chrome? False
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5190976638550016
>
> 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/CAC6ceCFrGCOFXgV9OuevjgA%2BZgXa-dE%2Bdd8f%2BZ8QC2w-ecAxCw%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/CAC6ceCETtJBfzZROvHo23KqJTrMKtmb6rA6duOpiDTKSussz8A%40mail.gmail.com.

[blink-dev] Re: RuntimeEnabledFeatures flags that we might be able to remove

[David Baron]

I've updated the spreadsheet of stable feature flags

to include features that shipped to stable in M121 and M122, and to remove
flags that have been removed since my last update.  (I left the previous
version of the sheet in the second tab.)  As before, hopefully this will
prompt some removal of flags that we don't need any longer.

-David

On Fri, Jan 12, 2024 at 11:39 AM David Baron  wrote:

> Since we've recently been more careful about creating feature flags for
> changes that have the possibility of breaking content, we've also been
> creating more feature flags than before.  This means that we're also
> creating a larger number of feature flags that have shipped to stable, been
> shown to be safe, and have served their purpose.  Many of these flags (and
> associated flag-controlled code) can hopefully be removed.
>
> I made a spreadsheet of feature flags that have been shipped in stable
> 
>  along
> with the stable milestone they shipped in.  The sheet should be publicly
> viewable and editable by any Chromium committer.  The sheet itself has
> notes about how I made it (briefly: mostly with
> third_party/blink/tools/list_stable_features.py).
>
> This sheet is presented as data to help folks remember to remove flags
> that they were intending to remove.  I'm sure there are a bunch of flags
> listed that shouldn't be removed, but also plenty that can be removed
> (either now or soon).
>
> Feel free to add notes to the sheet, update owners as needed, and to write
> CLs to remove flags that we don't need anymore.
>
> -David
>

-- 
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/CAG0MU3hvobd6Q9ehGToK%3DeixkCGbwXkTSheF0kVi53RcCcK%2Big%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Yoav Weiss (@Shopify)]

On Thu, Mar 21, 2024 at 10:11 AM Zheda Chen  wrote:

> The privacy/security/enterprise/debuggability gates are requested on
> Chrome Status. Testing gate to be requested later.
>
> "Unimportant" cross origin frames means they are cross-origin, visible but
> use non-large proportion (<75%) of page's visible area and have not
> received a user gesture. All 3 conditions should be met. The criteria are
> too long so we use "unimportant" concept here.
>
> This intervention is spec-compliant. The spec mentions "the
> SetTimeout/SetInterval API does not guarantee that timers will run exactly
> on schedule. Delays due to CPU load, other tasks, etc, are to be expected".
> The wait length of time is implementation-defined, "which is intended to
> allow user agents to pad timeouts as needed to optimize the power usage of
> the device". In Safari, DOM timers of non-interacted cross origin frames
> are aligned to 30ms after reaching max nesting level (>=5). In Firefox,
> all DOM timers of frames (both same origin and cross origin) are aligned to
> 16ms. See details in "Interoperability and Compatibility Risks", "Safari
> views", "Firefox views".
>

I believe the question Mike asked is not if this is spec compliant, but if
the specifics of this should be more tightly specified, given that both
WebKit and Chromium find a similar intervention useful.


> On Thursday, March 21, 2024 at 1:27:16 AM UTC+8 mike...@chromium.org
> wrote:
>
>> You should be able to see all the various bits for approvals in your
>> chromestatus entry now, can you fill them out please?
>>
>> There have been a few questions/comments about the lack of clarity of
>> what "unimportant cross-origin frames" are. What exactly is the definition?
>> You mention that Safari has a similar intervention - how similar is it? Do
>> we know? I wonder if there is alignment for this "unimportant cross-origin
>> frame" concept, if we shouldn't specify that somehow.
>> On 3/15/24 2:58 AM, Zheda Chen wrote:
>>
>> *Intent to Ship: Add JavaScript timer wake up alignment for unimportant
>> cross-origin frames*
>>
>> Contact emails
>> zheda...@intel.com, fdo...@chromium.org
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>> Summary
>>
>> Align wake ups of JavaScript timers for unimportant cross-origin frames.
>> Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to
>> performance concerns. This is very conservative and actually some
>> unimportant frames are eligible to use JS timer alignment. WebKit uses the
>> policy to align DOM timer of non-interacted cross origin frames to 30ms.
>> This feature adds JavaScript timer wake up alignment for unimportant frames
>> on foreground pages. Unimportant frames means they are cross origin,
>> visible but have non-large proportion of page’s visible area, and have no
>> user interaction. The alignment interval is 32ms. [1]
>> https://chromium-review.googlesource.com/c/chromium/src/+/4589092
>>
>>
>> Blink component
>> Blink>PerformanceAPIs>Timers
>> 
>>
>> TAG review
>> None
>>
>> TAG review status
>> Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> "Other vendors already have interoperable implementation" Safari has a
>> similar intervention. DOM timers of non-interacted cross origin frames are
>> aligned to 30ms. In Firefox, all DOM timers (both same-origin and
>> cross-origin) in foreground pages would be aligned to 16ms. "A mature
>> specification in the relevant standards body" This intervention is
>> spec-compliant. The spec mentions "the SetTimeout/SetInterval API does not
>> guarantee that timers will run exactly on schedule. Delays due to CPU load,
>> other tasks, etc, are to be expected. ". The wait length of time is
>> implementation-defined, "which is intended to allow user agents to pad
>> timeouts as needed to optimize the power usage of the device. "
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html "A
>> shared test suite for that specification" It isn't clear what should be
>> tested specifically for this intervention since the spec allows waiting for
>> an "implementation-defined" length.
>>
>>
>> *Gecko*: Shipped/Shipping
>> In Firefox, all DOM timers of frames (both same origin and cross origin)
>> are aligned to 16ms
>>
>> *WebKit*: Shipped/Shipping
>> In Safari, DOM timers of non-interacted cross origin frames are aligned
>> to 30ms after reaching max nesting level (>=5)
>>
>> *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?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>> Yes
>>
>> Is this fe