date:20230927

Please also fill out the other chromestatus review categories for this
Intent, in particular for Privacy and Security, thanks.

On Tue, Sep 26, 2023 at 11:14 PM Yoav Weiss  wrote:

>
>
> On Mon, Sep 25, 2023 at 11:52 PM Alex Turner  wrote:
>
>> Contact emailsale...@chromium.org
>>
>> Specification
>>
>>-
>>
>>Null report fixes:
>>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>>-
>>
>>Debug mode eligibility changes:
>>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>>-
>>
>>Padding report payloads:
>>
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>>https://github.com/WICG/attribution-reporting-api/pull/1030
>>-
>>
>>Reducing delay:
>>
>> https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>>
>>
>> Summary
>>
>> We're planning a few bundled changes to Private Aggregation:
>>
>>-
>>
>>Null report fixes: Currently reports with no contributions are
>>inadvertently dropped. This change ensures that, when a context ID is
>>specified, a null report is sent even if budget is denied. Separately, it
>>fixes a bug causing budget to always be denied for null reports.
>>-
>>
>>Debug mode eligibility changes: Currently, debug mode is always
>>available. This change only allows debug mode for callers that are allowed
>>access to third-party cookies, silently dropping the debug mode otherwise.
>>Note that this will allow debug mode to automatically sunset when
>>third-party cookies are deprecated.
>>-
>>
>>Padding report payloads: To avoid the payload size being dependent on
>>the number of contributions, we will pad it with 'null' contributions to a
>>fixed length. **Note**: this change will also affect Attribution
>>Reporting’s aggregatable reports.
>>-
>>
>>Reducing delay: When a context ID is specified, we remove the
>>randomized 10-60 minute delay, which is superfluous as a report is always
>>sent in this case. Instead, we just wait until the Shared Storage 
>> operation
>>timeout.
>>
>>
>> Blink componentBlink>PrivateAggregation
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have
>> not requested a signal for these changes specifically.)
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>- Null report fixes: Increases the number of reports sent to
>>reporting endpoints, reporting endpoints using plaintext debug payloads
>>will need to handle the null report case.
>>
>> Do you know if current reporting endpoints are ready to handle this
> change?
>
>>
>>- Debug mode eligibility changes: Backwards incompatible for callers
>>using enableDebugMode() without third-party cookie eligibility.
>>
>> Were callers already ready to have the enableDebugMode() call fail? Does
> it throw, or silently fails?
>
>>
>>- Padding report payloads: Compatible with existing aggregation
>>service versions. Reporting endpoints will see larger payloads and null
>>contributions added to the plaintext debug payloads (if used).
>>- Reducing delay: Should not require any reporting endpoint changes,
>>reports will simply arrive earlier.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/805). We have not
>> requested a signal for these changes specifically. The Gecko position on
>> Shared Storage (one of the ways Private Aggregation is exposed) is negative.
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/189). We have not
>> requested a signal for these changes specifically
>>
>> *Web developers*: Positive for reducing delay
>>
>> *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
>>
>> No new debug capabilities beyond the existing internals page
>> (chrome://private-aggregation-internals) and temporary debug mode.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> All but Webview
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?WPTs will be added when features are enabled.
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature namePadding: PrivacySandboxAggregationServiceReportPadding
>> All other features: PrivateAggregationApiBundledEnhancements
>>
>> Requires code in //chrome?Only for settings checks
>>
>> Tracking bughttps://crbug.com/1481761
>>
>> Launch bughttps://launch.corp.google.com/launch/4272421
>>
>> Estimated milestones
>>
>> We intend to

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

LGTM3

On Wed, Sep 27, 2023 at 7:56 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-09-27 12:02, Yoav Weiss wrote:
>
> LGTM1
>
> On Wed, Sep 27, 2023 at 11:50 AM Philipp Hancke <
> philipp.han...@googlemail.com> wrote:
>
>> Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss <
>> yoavwe...@chromium.org>:
>>
>>>
>>>
>>> On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Great follow up to
 https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ.
 Big fan!

>>>
>> heh, great original I2S ;-)
>>
>>
>>> On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emails
> phan...@microsoft.com, h...@chromium.org
>
> Specification
> https://datatracker.ietf.org/doc/rfc8446
>

>>> This is an interesting simple case where I agree that an explainer for
>>> this would be superfluous (as the Summary sums up what you're planning to
>>> ship).
>>>
>>>

>
> Summary
>
> Randomize the order of DTLS ClientHello extensions, to reduce
> potential ecosystem brittleness.
>
>
> This is a WebRTC specific follow-up to
> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
>  which
> launched successfully a while back.
>
>
> WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP
> and also uses a SRTP specific extension (use_srtp defined in RFC 5764) to
> negotiate encryption keys.
>
> Middleboxes might expect the use_srtp flag in a certain position which
> changes with this feature.
>
>
> Blink component
> Blink>WebRTC
> 
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> It is possible that WebRTC's ClientHello extension ordering is already
> ossified. This change may cause compatibility issues with middleboxes, 
> SBCs
> or other network monitoring software. We will do a slow rollout and 
> monitor
> breakage.
>

>>> Presumably, this will be behind a base feature to support the slow
>>> rollout?
>>>
>>
>> It is guarded with WebRTC's internal FieldTrial which is overridden with
>> a base::FieldTrial in magic build ways.
>>
>> Also, I assume the TLS side of things went smoothly. Any reason to
>>> believe DTLS would be significantly worse?
>>>
>>
>> It did (see here
>> ). Our
>> very own dreaded middleboxes (SBC or "Session Border Controller";
>> callcenters use them) tend to be conservative in terms of deployment (see
>> e.g. this comment
>> )
>> but most of them use a single vendor for browser interop testing who can
>> help with reaching out (in addition to discuss-webrtc and the release
>> notes) which should minimize the potential for breakage.
>>
>>
>>>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/709) Applied to
> TLS and DTLS equally
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/92)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> n/a, not developer facing
>
>
> Activation
>
> n/a, not developer facing
>
>
> Security
>
> Using a fixed extension order can encourage server implementers to
> fingerprint Chrome and then assume specific implementation behavior. This
> can limit ecosystem agility when Chrome implements future modifications to
> DTLS, if the server implementations are not prepared for Chrome to change
> its ClientHello. Chrome will randomly order extensions, subject to the
> pre_shared_key constraint in the RFC. This will reduce the risk of server
> and middleboxes fixating on details of our current ClientHello. This 
> should
> make the DTLS ecosystem more robust to changes.
>
>
> 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
>
> n/a, inner function of TLS stack. Possible to inspect using tools like
> Wireshark
>
>
> 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
> 
> ?
> No
>
> Flag name on chrome://flags
> None
>
> Finch

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

Please fill out the other chromestatus review categories (privacy,
security, etc); we'll re-review once those are done.

On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> o...@google.com, pauljen...@chromium.org
>
> Explainer
>
> https://github.com/WICG/turtledove/pull/780
>
> Specification
>
> https://github.com/WICG/turtledove/pull/796
>
> Summary
>
> In online ad auctions for ad space, it’s sometimes useful to prevent
> showing an ad to certain audiences, a concept known as negative targeting.
> For example, you might not want to show a new customer advertisement to
> existing customers. New customer acquisition campaigns most often have this
> as a critical requirement. Protected Audience currently enables ads to
> target users that have been joined to a given interest group through some
> past activity on the web. This feature extends Protected Audience to enable
> negative targeting by allowing new ads to target only those users who have
> not been joined to a given interest group. In this way, we're enabling
> advertisers to target new groups of users using the existing
> privacy-preserving concepts of the Protected Audience API.
>
>
> 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
>
> None. This is an optional new feature of the Protected Audience API. Ad
> techs can use this new feature by specifying values for new fields in the
> auction config. Without explicit values for those new fields, there's no
> functional behavioral change as a result of this feature.
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
> in the Mozilla forum here
> , and in the
> Webkit forum here
> .
>
> Web developers: Adtech asked for this via Protected Audience Github issue
> #319 .
>
>
> Debuggability
>
> Additional bids sent into the auction are visible in their response
> headers via DevTools. You can determine if the additional bid was sent for
> scoring by adding a breakpoint in the scoring script in DevTools. Error
> scenarios, e.g. signature verification errors and joining origin mismatch
> on negative interest groups - are written to the console. We're considering
> additional DevTools enhancements to aid additional bids debugging.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> It will be supported on all platforms that support Protected Audience, so
> all but WebView.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> We plan to add WPTs to cover this API in the next month.
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> FledgeNegativeTargeting
>
> Requires code in //chrome?
>
> False
>
> Estimated milestones
>
> Shipping on desktop and Android in M118.
>
> Anticipated spec changes
>
> None related to this feature.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5021508157571072
>
> 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/5ebd44f6-57b2-448f-b32c-87d63acfa471n%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/CAOMQ%2Bw_AJmJko%2BzZZLxD%2BN4db5aZzaJ3T%3D7OH0NFLjALxeQm1A%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

LGTM3

We also briefly reviewed the other review categories (privacy, security,
etc) and deemed them unlikely to create an issue in this case.

On Wed, Sep 27, 2023 at 7:58 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2023-09-26 11:28, 'François Beaufort' via blink-dev wrote:
>
> I'm happy to answer the remaining questions if any.
>
> On Wed, Sep 20, 2023 at 7:13 PM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> On Wed, Sep 20, 2023 at 5:45 PM François Beaufort 
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss 
>>> wrote:
>>>


 On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev <
 blink-dev@chromium.org> wrote:

> Contact emails
>
> fbeauf...@google.com
>
> elada...@google.com
>
> Explainer
>
> https://github.com/WICG/conditional-focus/blob/main/README.md
>
> Specification
>
>
> https://www.w3.org/TR/screen-capture/#idl-def-CaptureStartFocusBehavior.focus-capturing-application
>
> Summary
>
> The Screen Capture API lets the user select a tab, window, or screen
> to capture as a media stream. Using the existing CaptureController
> setFocusBehavior() method, web apps control whether the captured tab
> or window will be focused when capture starts, or whether the browser will
> leave focus with whichever surface last had focus.
>
>
> The new enum value "focus-capturing-application" allows web apps to
> give a hint to the browser that the capturing page prefers to remain
> focused. The old value "no-focus-change" now indicates that the
> application prefers that the user agent not change focus, leaving focus
> with whichever surface last had focus following the user's interaction 
> with
> the user agent and/or operating system. In Chrome’s current 
> implementation,
> this means leaving the capturing application focused. In the future, if
> Chrome adopts the macOS picker, it could behave differently on Mac. This
> behavior could prove useful for a11y-conscious applications that prefer to
> minimize the number of focus-changes a user experiences, as those can be
> challenging for users with screen-readers.
>
> Blink component
>
> Blink>GetDisplayMedia
> 
>
> TAG review
>
> N/A We didn’t file a specific TAG review for this feature as the
> addition of this enum doesn’t have any architectural changes impact to the
> spec and the web in general.
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> None
>

 You mentioned a semantics change around "no-focus-change". I guess it
 doesn't have any ability to break pages, at worst users will get a
 different focus than they previously did. Is that correct?

>>>
>>> "focus-capturing-application" and "no-focus-change" behave the same in
>>> Chrome.
>>> This will not break pages as Chrome is the only browser to have shipped
>>> Conditional Focus.
>>>
>>
>> OK, thanks for clarifying!
>>
>>
>>>

>
> Gecko: No signal
>

 Can we file a position, as an FYI?

>>>
>>> Here it is: https://github.com/mozilla/standards-positions/issues/888
>>>
>>>


>
> WebKit: No signal - Youenn Fablet from Apple requested this API
> change in https://github.com/w3c/mediacapture-screen-share/issues/263.
>
> Web developers: No signal
>
> 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
>
> No DevTools changes are required, treated like any other
> attribute/enum.
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Supported on all platforms that support getDisplayMedia. Namely, all
> desktop platforms.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes. See
> https://wpt.fyi/results/screen-capture/getdisplaymedia-capture-controller.https.window.html
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> None
>
> Requires code in //chrome?
>
> No.
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1480383
>
> Estimated milestones
>
> Shipping on desktop
>
> 119
>
> 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

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

LGTM3

On Wed, Sep 27, 2023 at 8:11 AM Daniel Bratell  wrote:

> LGTM2 (for the original request, just to be clear)
>
> I assume it will have the normal flag that will allow it to be turned off
> if our interpretation is incorrect, since it is so hard to measure with a
> high accuracy.
>
> /Daniel
> On 2023-09-26 18:33, David Benjamin wrote:
>
> To clarify, I meant that we should apply this to WebRTC *in a
> separate launch*. This one will just be HTTPS. We don't have numbers or a
> flag for WebRTC right now, and we usually end up doing WebRTC separately
> anyway, for better or worse. :-)
>
> On Tue, Sep 26, 2023 at 12:31 PM David Benjamin 
> wrote:
>
>> Ah yeah, we should apply this to WebRTC too. Based on the kinds of issues
>> we've seen, hopefully that one will be easy (I wouldn't expect WebRTC to be
>> impacted by the kinds of server bugs we've seen), but certainly we'll need
>> numbers.
>>
>> Measurement is a little complicated for HTTPS (we had to do this fallback
>> dance to avoid a ton of false positives on old Schannel behavior, which is
>> why we had to pick up transient network errors as a different source of
>> false positives). But since WebRTC talks to different kinds of peers, I
>> suspect you all can just histogram the server-selected algorithm with
>> SSL_get_peer_signature_algorithm, and just assume that's an accurate enough
>> predictor. (TLS is client-offer / server-select, so we never learn the
>> server's full capabilities, only what it happened to pick in response to
>> our ClientHello. This makes measurements inherently more complex
>> 
>> than measuring JavaScript API usage, but in simple cases just measuring
>> the server selection gives good enough numbers.)
>>
>> On Tue, Sep 26, 2023 at 5:26 AM Philipp Hancke <
>> philipp.han...@googlemail.com> wrote:
>>
>>> Should/can this also be applied to WebRTC's DTLS connections?
>>>
>>> (we don't have numbers but that can be fixed)
>>>
>>> Am Mo., 25. Sept. 2023 um 19:13 Uhr schrieb Yoav Weiss <
>>> yoavwe...@chromium.org>:
>>>
 LGTM1 to remove support, given that 0.009% of TLS connections divided
 by ~30 is roughly at our typical threshold. Also given the dominance of
 subresource TLS connections, it's likely that breakage would hit one of
 those subresources, making it less likely to cause functional damage
 (compared to e.g. the navigation request TLS connection).

 On Mon, Sep 25, 2023 at 6:03 PM David Adrian 
 wrote:

> There are approximately 30x TLS connections relative to pageloads, due
> to subresources. Once you have a TLS connection open for a main frame, I'm
> not sure how many page loads happen across it. Probably a lot, but it's
> still dominated by subresources.
>
> In practice, the 0.02% bound appears to have shaken out to sub 0.01%
> (0.009%), determined by looking at differences in the "OK" result for
> Net.SSL_Connection_Error.
>
> On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wed, Sep 20, 2023 at 12:47 AM David Benjamin <
>> david...@chromium.org> wrote:
>>
>>> On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss 
>>> wrote:
>>>
 On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss 
 wrote:

> On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Mon, Sep 18, 2023 at 4:11 PM David Adrian 
>> wrote:
>>
>>> > This should probably be an "Intent to Deprecate and Remove"
>>> rather than an "Intent to Ship".
>>>
>>> You're absolutely right that it should be, unfortunately that's
>>> not the subject Chrome Status generated. I'll file an issue.
>>>
>>
>> Oops, yes, you did everything right here. There's already
>> https://github.com/GoogleChrome/chromium-dashboard/issues/2749
>> about changing this subject line, and now
>> https://github.com/GoogleChrome/chromium-dashboard/issues/3346
>> to align the Chrome Status UI with the launching-features page.
>>
>> > The RFC's introduction at
>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction
>>> is a pretty good explainer for why we should remove SHA-1 
>>> signatures.
>>>
>>> Agreed. Noting in general, there is a large process mismatch
>>> between TLS launches and the Blink launch process, as discussed in
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ.
>>> That's why this Intent looks a little different.
>>>
>>
> I wouldn't categorize it as a large process mismatch. But that's
> an orthogonal discussion.
>
>
>>
>>> As for the launch itself, I'll note it's been at 10% on

Re: [blink-dev] Intent to Ship: Deprecate TLS SHA-1 server signatures

LGTM2 (for the original request, just to be clear)

I assume it will have the normal flag that will allow it to be turned 
off if our interpretation is incorrect, since it is so hard to measure 
with a high accuracy.

/Daniel

On 2023-09-26 18:33, David Benjamin wrote:
To clarify, I meant that we should apply this to WebRTC /in a 
separate launch/. This one will just be HTTPS. We don't have numbers 
or a flag for WebRTC right now, and we usually end up doing WebRTC 
separately anyway, for better or worse. :-)

On Tue, Sep 26, 2023 at 12:31 PM David Benjamin 
 wrote:

Ah yeah, we should apply this to WebRTC too. Based on the kinds of
issues we've seen, hopefully that one will be easy (I wouldn't
expect WebRTC to be impacted by the kinds of server bugs we've
seen), but certainly we'll need numbers.

Measurement is a little complicated for HTTPS (we had to do this
fallback dance to avoid a ton of false positives on old Schannel
behavior, which is why we had to pick up transient network errors
as a different source of false positives). But since WebRTC talks
to different kinds of peers, I suspect you all can just histogram
the server-selected algorithm with
SSL_get_peer_signature_algorithm, and just assume that's an
accurate enough predictor. (TLS is client-offer / server-select,
so we never learn the server's full capabilities, only what it
happened to pick in response to our ClientHello. This makes
measurements inherently more complex

than measuring JavaScript API usage, but in simple cases just
measuring the server selection gives good enough numbers.)

On Tue, Sep 26, 2023 at 5:26 AM Philipp Hancke
 wrote:

Should/can this also be applied to WebRTC's DTLS connections?

(we don't have numbers but that can be fixed)

Am Mo., 25. Sept. 2023 um 19:13 Uhr schrieb Yoav Weiss
:

LGTM1 to remove support, given that 0.009% of TLS
connections divided by ~30 is roughly at our typical
threshold. Also given the dominance of subresource TLS
connections, it's likely that breakage would hit one of
those subresources, making it less likely to cause
functional damage (compared to e.g. the navigation request
TLS connection).

On Mon, Sep 25, 2023 at 6:03 PM David Adrian
 wrote:

There are approximately 30x TLS connections relative
to pageloads, due to subresources. Once you have a TLS
connection open for a main frame, I'm not sure how
many page loads happen across it. Probably a lot, but
it's still dominated by subresources.

In practice, the 0.02% bound appears to have shaken
out to sub 0.01% (0.009%), determined by looking at
differences in the "OK" result for
Net.SSL_Connection_Error.

On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss
 wrote:

On Wed, Sep 20, 2023 at 12:47 AM David Benjamin
 wrote:

On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss
 wrote:

On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss
 wrote:

On Tue, Sep 19, 2023 at 1:35 AM
'Jeffrey Yasskin' via blink-dev
 wrote:

On Mon, Sep 18, 2023 at 4:11 PM
David Adrian 
wrote:

> This should probably be an
"Intent to Deprecate and
Remove" rather than an "Intent
to Ship".

You're absolutely right that
it should be, unfortunately
that's not the subject Chrome
Status generated. I'll file an
issue.

Oops, yes, you did everything
right here. There's already

https://github.com/GoogleChrome/chromium-dashboard/issues/2749
about changing this subject line,
and now

https://github.com/GoogleChrome/chromium-dashboard/issues/3346
to align the Chrome Status UI with
the launching-features page.

>

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

LGTM2

/Daniel

On 2023-09-26 11:28, 'François Beaufort' via blink-dev wrote:

I'm happy to answer the remaining questions if any.

On Wed, Sep 20, 2023 at 7:13 PM Yoav Weiss wrote:

LGTM1

On Wed, Sep 20, 2023 at 5:45 PM François Beaufort
wrote:

On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss
wrote:

On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via
blink-dev wrote:

Contact emails

fbeauf...@google.com

elada...@google.com

Explainer

https://github.com/WICG/conditional-focus/blob/main/README.md

Specification

https://www.w3.org/TR/screen-capture/#idl-def-CaptureStartFocusBehavior.focus-capturing-application

Summary

The Screen Capture API lets the user select a tab,
window, or screen to capture as a media stream. Using
the existing CaptureController
setFocusBehavior()method, web apps control whether the
captured tab or window will be focused when capture
starts, or whether the browser will leave focus with
whichever surface last had focus.

The new enum value "focus-capturing-application"allows
web apps to give a hint to the browser that the
capturing page prefers to remain focused. The old
value "no-focus-change"now indicates that the
application prefers that the user agent not change
focus, leaving focus with whichever surface last had
focus following the user's interaction with the user
agent and/or operating system. In Chrome’s current
implementation, this means leaving the capturing
application focused. In the future, if Chrome adopts
the macOS picker, it could behave differently on Mac.
This behavior could prove useful for a11y-conscious
applications that prefer to minimize the number of
focus-changes a user experiences, as those can be
challenging for users with screen-readers.

Blink component

Blink>GetDisplayMedia

TAG review

N/A We didn’t file a specific TAG review for this
feature as the addition of this enum doesn’t have any
architectural changes impact to the spec and the web
in general.

TAG review status

Pending

Risks

Interoperability and Compatibility

None

You mentioned a semantics change around "no-focus-change".
I guess it doesn't have any ability to break pages, at
worst users will get a different focus than they
previously did. Is that correct?

"focus-capturing-application" and "no-focus-change" behave the
same in Chrome.
This will not break pages as Chrome is the only browser to
have shipped Conditional Focus.

OK, thanks for clarifying!

Gecko: No signal

Can we file a position, as an FYI?

Here it is:
https://github.com/mozilla/standards-positions/issues/888

WebKit: No signal - Youenn Fablet from Apple requested
this API change in
https://github.com/w3c/mediacapture-screen-share/issues/263
.

Web developers: No signal

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

No DevTools changes are required, treated like any
other attribute/enum.

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

Supported on all platforms that support
getDisplayMedia. Namely, all desktop platforms.

Is this feature fully tested by

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)


LGTM2

/Daniel

On 2023-09-27 12:02, Yoav Weiss wrote:

LGTM1

On Wed, Sep 27, 2023 at 11:50 AM Philipp Hancke 
 wrote:


Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss
:



On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev
 wrote:

Great follow up to

https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ.
Big fan!


heh, great original I2S ;-)

On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via
blink-dev  wrote:


Contact emails

phan...@microsoft.com, h...@chromium.org


Specification

https://datatracker.ietf.org/doc/rfc8446


This is an interesting simple case where I agree that an
explainer for this would be superfluous (as the Summary sums
up what you're planning to ship).



Summary

Randomize the order of DTLS ClientHello extensions, to
reduce potential ecosystem brittleness.


This is a WebRTC specific follow-up to

https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
 which
launched successfully a while back.


WebRTC uses DTLS (datagram TLS over UDP) multiplexed
with STUN and RTP and also uses a SRTP specific
extension (use_srtp defined in RFC 5764) to negotiate
encryption keys.

Middleboxes might expect the use_srtp flag in a
certain position which changes with this feature.



Blink component

Blink>WebRTC




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

It is possible that WebRTC's ClientHello extension
ordering is already ossified. This change may cause
compatibility issues with middleboxes, SBCs or other
network monitoring software. We will do a slow rollout
and monitor breakage.


Presumably, this will be behind a base feature to support the
slow rollout?


It is guarded with WebRTC's internal FieldTrial which is
overridden with a base::FieldTrial in magic build ways.

Also, I assume the TLS side of things went smoothly. Any
reason to believe DTLS would be significantly worse?


It did (see here
).
Our very own dreaded middleboxes (SBC or "Session Border
Controller"; callcenters use them) tend to be conservative in
terms of deployment (see e.g. this comment
)
but most of them use a single vendor for browser interop testing
who can help with reaching out (in addition to discuss-webrtc and
the release notes) which should minimize the potential for breakage.



/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/709)
Applied to TLS and DTLS equally

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/92)

/Web developers/: No signals

/Other signals/:


Ergonomics

n/a, not developer facing



Activation

n/a, not developer facing



Security

Using a fixed extension order can encourage server
implementers to fingerprint Chrome and then assume
specific implementation behavior. This can limit
ecosystem agility when Chrome implements future
modifications to DTLS, if the server implementations
are not prepared for Chrome to change its ClientHello.
Chrome will randomly order extensions, subject to the
pre_shared_key constraint in the RFC. This will reduce
the risk of server and middleboxes fixating on details
of our current ClientHello. This should make the DTLS
ecosystem more robust to changes.



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

n/a, inner function of TLS stack. Possible to inspect
using tools like Wireshark

Re: [blink-dev] Intent to Ship: Unprefix -webkit-background-clip for "text" and make it an alias

It allows to use the unprefixed version for background-clip: text and
makes -webkit-background-clip an alias for background-clip. Also, it
drops support for non-suffixed keywords (content, padding and border)
for better round-trip with alias.

Can you clarify exactly what this means? I'm perfectly fine with
lgtm-ing unprefixing and adding a (temporary?) alias for the old
keyword, but if we start removing support for keywords we need to be
more careful and I want to be sure I understand.

/Daniel

On 2023-09-27 09:53, Daniil Sakhapov wrote:

Also forgot to mention: the highest use counter for unsuffixed keyword
is 0.08 - and among those I've analyzed 80% of websites and all of
them use suffixed *-box version, so it's safe to remove.

On Wednesday, September 27, 2023 at 9:49:35 AM UTC+2 Yoav Weiss wrote:

LGTM1

On Wed, Sep 27, 2023 at 2:38 AM 一丝 wrote:

I think the correct specification address would be
https://drafts.csswg.org/css-backgrounds-4/#typedef-bg-clip

In css-backgrounds-4 also added `border` value, should we
support it when removing the prefix? Maybe this needs to be
discussed further by the CSSWG.

在2023年9月27日星期三 UTC+8 06:04:54 写道：

Is there any interest in doing the same for
-webkit-text-fill-color? The two get typically used in
combination for gradient effects:

https://github.com/tomayac/blogccasion/blob/6ee3722011661db7a0c95c4379d7905bd8e95404/css/main.css#L100-L113

.
(See any of the headings on https://blog.tomayac.com/ for
an example.)

On Tue, Sep 26, 2023, 16:33 Daniil Sakhapov
wrote:

Contact emails

sakh...@chromium.org

Specification

https://drafts.csswg.org/css-backgrounds/#background-clip

Summary

It allows to use the unprefixed version for
background-clip: text and makes
-webkit-background-clip an alias for background-clip.
Also, it drops support for non-suffixed keywords
(content, padding and border) for better round-trip
with alias.

Blink component

Blink>CSS

Risks

Interoperability and Compatibility

None

/Gecko/: Shipped/Shipping Firefox doesn't support
keywords with no suffix for prefixed version

/WebKit/: Shipped/Shipping Safari supports keywords
with no suffix (border, content, padding), but only
for prefixed version

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

wpt.fyi/css/css-backgrounds/background-clip/clip-text-dynamic-2.html

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5125388091260928

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+...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z928OknOBtR09iMg2rc%2B8qst3%2Bk7Pek%2Bh_hmWA-fDxM8yVw%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

Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

2023-09-27 Thread Lukas


I disagree- the default in Windows apps seems to be the hidden mode, and it 
seems counterintuitive to implement windows like scrollbars without 
mirroring the actual Windows experience. I realize it probably won't be the 
default mode, but if it's possible to at least leave it as a setting for 
the users that wish to use it, that would be great.
On Tuesday, March 22, 2022 at 4:28:07 PM UTC-7 Ben Mathwig wrote:

> I agree with both of these things. I'm in support of removing the "hidden" 
> state all together, for all scrollers.
>
> On Tuesday, March 22, 2022 at 3:34:35 PM UTC-7 sko...@chromium.org wrote:
>
>> My own view is that it is user-hostile to fully hide scrollbars, because 
>> then you have no visual indication that a region of the page is 
>> scrollable.  Though it does seem that this ship has sailed on other OS'es.
>>
>> Orthogonal to that concern, I think the web platform should try to avoid 
>> giving different behavior to root and non-root scrollers.  So if we decide 
>> hidden scrollbars are a good idea, then we should hide them for the root 
>> scroller too (when the cursor leaves the content area).
>>
>> But I'd ideally like to have only the minimal and full modes, and not the 
>> hidden mode, for all scrollers.
>>
>> On Tue, Mar 22, 2022 at 6:16 PM 'Ben Mathwig' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> I'm glad you brought this up, it's something we'd like to get your take 
>>> on. Windows designed it that way in their official spec, but I personally 
>>> feel like it creates an accessibility issue. I believe Apple hides the 
>>> panning indicator on macOS, so I suspect their design inspiration came from 
>>> there.
>>>
>>> On Tuesday, March 22, 2022 at 2:31:07 PM UTC-7 sko...@chromium.org 
>>> wrote:
>>>
 Thanks for sharing these docs.

 I am curious about the rationale for "Hidden Mode" as described in the 
 visual 
 spec 
 .
   
 Why is this mode desired only for non-root scrollers?

 On Tue, Mar 22, 2022 at 4:33 PM Rahul Arakeri  
 wrote:

> Just checking in to see if anyone got a chance to review the doc.
>
> Please let us know if you have any questions/concerns (or if it looks 
> good as-is). 
>
>  
>
> Thanks,
>
> Rahul
>
>  
>
> *From:* Rahul Arakeri 
> *Sent:* Thursday, March 10, 2022 5:48 PM
> *To:* Chris Harrelson 
> *Cc:* Steve Kobes ; Ian Kilpatrick <
> ikilp...@chromium.org>; Mike Taylor ; blink-dev 
> ; Robert Flack ; 
> wangxianzhu ; Philip Rogers ; 
> input-dev ; Yaroslav Shalivskyy <
> yshal...@microsoft.com>; Olga Gerchikov ; 
> Sahir Vellani ; Ben Mathwig <
> benjamin...@microsoft.com>
> *Subject:* RE: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent 
> Scrollbars.
>
>  
>
> Hello everyone,
>
>  
>
> Here’s the design doc. Please have a look at it and let us know what 
> you think. 
>
> FluentScrollbarsDesignDoc - Google Docs 
> 
>
>  
>
> Thanks,
>
> Rahul
>
>  
>
> *From:* Rahul Arakeri 
> *Sent:* Tuesday, February 8, 2022 9:24 AM
> *To:* 'Chris Harrelson' 
> *Cc:* Steve Kobes ; Ian Kilpatrick <
> ikilp...@chromium.org>; Mike Taylor ; blink-dev 
> ; Robert Flack ; 
> wangxianzhu ; Philip Rogers ; 
> input-dev ; Yaroslav Shalivskyy <
> yshal...@microsoft.com>; Olga Gerchikov ; 
> Sahir Vellani ; Ben Mathwig <
> benjamin...@microsoft.com>
> *Subject:* RE: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent 
> Scrollbars.
>
>  
>
> Sounds good Chris, we’ll send out a class design doc shortly to get 
> everyone on the same page.
>
>  
>
> Re Manuel: Thanks for your input, we’ll come up with a plan to keep 
> non-overlay scrollbars tests running as well..
>
>  
>
> *From:* Chris Harrelson  
> *Sent:* Thursday, February 3, 2022 10:28 PM
> *To:* Rahul Arakeri 
> *Cc:* Steve Kobes ; Ian Kilpatrick <
> ikilp...@chromium.org>; Mike Taylor ; blink-dev 
> ; Robert Flack ; 
> wangxianzhu ; Philip Rogers ; 
> input-dev ; Yaroslav Shalivskyy <
> yshal...@microsoft.com>; Olga Gerchikov ; 
> Sahir Vellani ; Ben Mathwig <
> benjamin...@microsoft.com>
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent 
> Scrollbars.
>
>  
>
>  
>
> On Thu, Feb 3, 2022, 10:00 PM 'Rahul Arakeri' via blink-dev <
> blin...@chromium.org> wrote:
>
> Just checking in on this.. Please let us know if you need anything 
> from us to move this discussion along.
>
>  
>
> Hi Rahul,
>
>  
>
> Since this is an intent to implement you don't need

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

LGTM1

On Wed, Sep 27, 2023 at 11:50 AM Philipp Hancke <
philipp.han...@googlemail.com> wrote:

> Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss <
> yoavwe...@chromium.org>:
>
>>
>>
>> On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Great follow up to
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ.
>>> Big fan!
>>>
>>
> heh, great original I2S ;-)
>
>
>> On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails
 phan...@microsoft.com, h...@chromium.org

 Specification
 https://datatracker.ietf.org/doc/rfc8446

>>>
>> This is an interesting simple case where I agree that an explainer for
>> this would be superfluous (as the Summary sums up what you're planning to
>> ship).
>>
>>
>>>

 Summary

 Randomize the order of DTLS ClientHello extensions, to reduce potential
 ecosystem brittleness.

 This is a WebRTC specific follow-up to
 https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
  which
 launched successfully a while back.

 WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP
 and also uses a SRTP specific extension (use_srtp defined in RFC 5764) to
 negotiate encryption keys.

 Middleboxes might expect the use_srtp flag in a certain position which
 changes with this feature.

 Blink component
 Blink>WebRTC

 TAG review
 None

 TAG review status
 Not applicable

 Risks

 Interoperability and Compatibility

 It is possible that WebRTC's ClientHello extension ordering is already
 ossified. This change may cause compatibility issues with middleboxes, SBCs
 or other network monitoring software. We will do a slow rollout and monitor
 breakage.

>>>
>> Presumably, this will be behind a base feature to support the slow
>> rollout?
>>
>
> It is guarded with WebRTC's internal FieldTrial which is overridden with a
> base::FieldTrial in magic build ways.
>
> Also, I assume the TLS side of things went smoothly. Any reason to believe
>> DTLS would be significantly worse?
>>
>
> It did (see here
> ). Our very
> own dreaded middleboxes (SBC or "Session Border Controller"; callcenters
> use them) tend to be conservative in terms of deployment (see e.g. this
> comment )
> but most of them use a single vendor for browser interop testing who can
> help with reaching out (in addition to discuss-webrtc and the release
> notes) which should minimize the potential for breakage.
>
>
>>

 *Gecko*: Positive (
 https://github.com/mozilla/standards-positions/issues/709) Applied to
 TLS and DTLS equally

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/92)

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 n/a, not developer facing

 Activation

 n/a, not developer facing

 Security

 Using a fixed extension order can encourage server implementers to
 fingerprint Chrome and then assume specific implementation behavior. This
 can limit ecosystem agility when Chrome implements future modifications to
 DTLS, if the server implementations are not prepared for Chrome to change
 its ClientHello. Chrome will randomly order extensions, subject to the
 pre_shared_key constraint in the RFC. This will reduce the risk of server
 and middleboxes fixating on details of our current ClientHello. This should
 make the DTLS ecosystem more robust to changes.

 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

 n/a, inner function of TLS stack. Possible to inspect using tools like
 Wireshark

 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

 ?
 No

 Flag name on chrome://flags
 None

 Finch feature name
 WebRTC-PermuteTlsClientHello

 Requires code in //chrome?
 False

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

 Estimated milestones
 Shipping on desktop 120

 Anticipated spec changes

 *Open questions about a

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

2023-09-27 Thread 'Philipp Hancke' via blink-dev

Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss <
yoavwe...@chromium.org>:

>
>
> On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Great follow up to
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ.
>> Big fan!
>>
>
heh, great original I2S ;-)


> On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>> phan...@microsoft.com, h...@chromium.org
>>>
>>> Specification
>>> https://datatracker.ietf.org/doc/rfc8446
>>>
>>
> This is an interesting simple case where I agree that an explainer for
> this would be superfluous (as the Summary sums up what you're planning to
> ship).
>
>
>>
>>>
>>> Summary
>>>
>>> Randomize the order of DTLS ClientHello extensions, to reduce potential
>>> ecosystem brittleness.
>>>
>>>
>>> This is a WebRTC specific follow-up to
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
>>>  which
>>> launched successfully a while back.
>>>
>>>
>>> WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP
>>> and also uses a SRTP specific extension (use_srtp defined in RFC 5764) to
>>> negotiate encryption keys.
>>>
>>> Middleboxes might expect the use_srtp flag in a certain position which
>>> changes with this feature.
>>>
>>>
>>> Blink component
>>> Blink>WebRTC
>>> 
>>>
>>> TAG review
>>> None
>>>
>>> TAG review status
>>> Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> It is possible that WebRTC's ClientHello extension ordering is already
>>> ossified. This change may cause compatibility issues with middleboxes, SBCs
>>> or other network monitoring software. We will do a slow rollout and monitor
>>> breakage.
>>>
>>
> Presumably, this will be behind a base feature to support the slow rollout?
>

It is guarded with WebRTC's internal FieldTrial which is overridden with a
base::FieldTrial in magic build ways.

Also, I assume the TLS side of things went smoothly. Any reason to believe
> DTLS would be significantly worse?
>

It did (see here
). Our very
own dreaded middleboxes (SBC or "Session Border Controller"; callcenters
use them) tend to be conservative in terms of deployment (see e.g. this
comment )
but most of them use a single vendor for browser interop testing who can
help with reaching out (in addition to discuss-webrtc and the release
notes) which should minimize the potential for breakage.


>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/709) Applied to
>>> TLS and DTLS equally
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/92)
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> n/a, not developer facing
>>>
>>>
>>> Activation
>>>
>>> n/a, not developer facing
>>>
>>>
>>> Security
>>>
>>> Using a fixed extension order can encourage server implementers to
>>> fingerprint Chrome and then assume specific implementation behavior. This
>>> can limit ecosystem agility when Chrome implements future modifications to
>>> DTLS, if the server implementations are not prepared for Chrome to change
>>> its ClientHello. Chrome will randomly order extensions, subject to the
>>> pre_shared_key constraint in the RFC. This will reduce the risk of server
>>> and middleboxes fixating on details of our current ClientHello. This should
>>> make the DTLS ecosystem more robust to changes.
>>>
>>>
>>> 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
>>>
>>> n/a, inner function of TLS stack. Possible to inspect using tools like
>>> Wireshark
>>>
>>>
>>> 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
>>> 
>>> ?
>>> No
>>>
>>> Flag name on chrome://flags
>>> None
>>>
>>> Finch feature name
>>> WebRTC-PermuteTlsClientHello
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/webrtc/issues/detail?id=15467
>>>
>>> Estimated milestones
>>> Shipping on desktop 120
>>>
>>>
>>> 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

Re: [blink-dev] Intent to Ship: Unprefix -webkit-background-clip for "text" and make it an alias

2023-09-27 Thread Daniil Sakhapov

Also forgot to mention: the highest use counter for unsuffixed keyword is 
0.08 - and among those I've analyzed 80% of websites and all of them use 
suffixed *-box version, so it's safe to remove.

On Wednesday, September 27, 2023 at 9:49:35 AM UTC+2 Yoav Weiss wrote:

> LGTM1
>
> On Wed, Sep 27, 2023 at 2:38 AM 一丝  wrote:
>
>> I think the correct specification address would be 
>> https://drafts.csswg.org/css-backgrounds-4/#typedef-bg-clip
>>
>> In css-backgrounds-4 also added `border` value, should we support it when 
>> removing the prefix? Maybe this needs to be discussed further by the CSSWG.
>>
>> 在2023年9月27日星期三 UTC+8 06:04:54 写道：
>>
>>> Is there any interest in doing the same for -webkit-text-fill-color? The 
>>> two get typically used in combination for gradient effects: 
>>> https://github.com/tomayac/blogccasion/blob/6ee3722011661db7a0c95c4379d7905bd8e95404/css/main.css#L100-L113.
>>>  
>>> (See any of the headings on https://blog.tomayac.com/ for an example.)
>>>
>>> On Tue, Sep 26, 2023, 16:33 Daniil Sakhapov  
>>> wrote:
>>>
 Contact emailssakh...@chromium.org

 Specificationhttps://drafts.csswg.org/css-backgrounds/#background-clip

 Summary

 It allows to use the unprefixed version for background-clip: text and 
 makes -webkit-background-clip an alias for background-clip. Also, it drops 
 support for non-suffixed keywords (content, padding and border) for better 
 round-trip with alias.

 Blink componentBlink>CSS 
 

 Risks

 Interoperability and Compatibility

 None

 *Gecko*: Shipped/Shipping Firefox doesn't support keywords with no 
 suffix for prefixed version

 *WebKit*: Shipped/Shipping Safari supports keywords with no suffix 
 (border, content, padding), but only for prefixed version

 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 
 
 ?wpt.fyi/css/css-backgrounds/background-clip/clip-text-dynamic-2.html

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

 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+...@chromium.org.
 To view this discussion on the web visit 
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z928OknOBtR09iMg2rc%2B8qst3%2Bk7Pek%2Bh_hmWA-fDxM8yVw%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/2328dffa-e2c8-4c68-83f6-c9667b981823n%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/4956583f-6dec-43d6-8d18-394e15c9d72an%40chromium.org.

Re: [blink-dev] Intent to Ship: Unprefix -webkit-background-clip for "text" and make it an alias

LGTM1

On Wed, Sep 27, 2023 at 2:38 AM 一丝  wrote:

> I think the correct specification address would be
> https://drafts.csswg.org/css-backgrounds-4/#typedef-bg-clip
>
> In css-backgrounds-4 also added `border` value, should we support it when
> removing the prefix? Maybe this needs to be discussed further by the CSSWG.
>
> 在2023年9月27日星期三 UTC+8 06:04:54 写道：
>
>> Is there any interest in doing the same for -webkit-text-fill-color? The
>> two get typically used in combination for gradient effects:
>> https://github.com/tomayac/blogccasion/blob/6ee3722011661db7a0c95c4379d7905bd8e95404/css/main.css#L100-L113.
>> (See any of the headings on https://blog.tomayac.com/ for an example.)
>>
>> On Tue, Sep 26, 2023, 16:33 Daniil Sakhapov  wrote:
>>
>>> Contact emailssakh...@chromium.org
>>>
>>> Specificationhttps://drafts.csswg.org/css-backgrounds/#background-clip
>>>
>>> Summary
>>>
>>> It allows to use the unprefixed version for background-clip: text and
>>> makes -webkit-background-clip an alias for background-clip. Also, it drops
>>> support for non-suffixed keywords (content, padding and border) for better
>>> round-trip with alias.
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>> *Gecko*: Shipped/Shipping Firefox doesn't support keywords with no
>>> suffix for prefixed version
>>>
>>> *WebKit*: Shipped/Shipping Safari supports keywords with no suffix
>>> (border, content, padding), but only for prefixed version
>>>
>>> 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
>>> 
>>> ?wpt.fyi/css/css-backgrounds/background-clip/clip-text-dynamic-2.html
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5125388091260928
>>>
>>> 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+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z928OknOBtR09iMg2rc%2B8qst3%2Bk7Pek%2Bh_hmWA-fDxM8yVw%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/2328dffa-e2c8-4c68-83f6-c9667b981823n%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/CAL5BFfWM3unTijykX8SkPcFrLZLOtHa_KaPOLqmngFN5PfVFzA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Aggregation API bundled enhancements

On Mon, Sep 25, 2023 at 11:52 PM Alex Turner  wrote:

> Contact emailsale...@chromium.org
>
> Specification
>
>-
>
>Null report fixes:
>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/91
>-
>
>Debug mode eligibility changes:
>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/90
>-
>
>Padding report payloads:
>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/98,
>https://github.com/WICG/attribution-reporting-api/pull/1030
>-
>
>Reducing delay:
>https://github.com/patcg-individual-drafts/private-aggregation-api/pull/103
>
>
> Summary
>
> We're planning a few bundled changes to Private Aggregation:
>
>-
>
>Null report fixes: Currently reports with no contributions are
>inadvertently dropped. This change ensures that, when a context ID is
>specified, a null report is sent even if budget is denied. Separately, it
>fixes a bug causing budget to always be denied for null reports.
>-
>
>Debug mode eligibility changes: Currently, debug mode is always
>available. This change only allows debug mode for callers that are allowed
>access to third-party cookies, silently dropping the debug mode otherwise.
>Note that this will allow debug mode to automatically sunset when
>third-party cookies are deprecated.
>-
>
>Padding report payloads: To avoid the payload size being dependent on
>the number of contributions, we will pad it with 'null' contributions to a
>fixed length. **Note**: this change will also affect Attribution
>Reporting’s aggregatable reports.
>-
>
>Reducing delay: When a context ID is specified, we remove the
>randomized 10-60 minute delay, which is superfluous as a report is always
>sent in this case. Instead, we just wait until the Shared Storage operation
>timeout.
>
>
> Blink componentBlink>PrivateAggregation
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/846 (We have
> not requested a signal for these changes specifically.)
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>- Null report fixes: Increases the number of reports sent to reporting
>endpoints, reporting endpoints using plaintext debug payloads will need to
>handle the null report case.
>
> Do you know if current reporting endpoints are ready to handle this
change?

>
>- Debug mode eligibility changes: Backwards incompatible for callers
>using enableDebugMode() without third-party cookie eligibility.
>
> Were callers already ready to have the enableDebugMode() call fail? Does
it throw, or silently fails?

>
>- Padding report payloads: Compatible with existing aggregation
>service versions. Reporting endpoints will see larger payloads and null
>contributions added to the plaintext debug payloads (if used).
>- Reducing delay: Should not require any reporting endpoint changes,
>reports will simply arrive earlier.
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/805). We have not
> requested a signal for these changes specifically. The Gecko position on
> Shared Storage (one of the ways Private Aggregation is exposed) is negative.
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/189). We have not
> requested a signal for these changes specifically
>
> *Web developers*: Positive for reducing delay
>
> *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
>
> No new debug capabilities beyond the existing internals page
> (chrome://private-aggregation-internals) and temporary debug mode.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All but Webview
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?WPTs will be added when features are enabled.
>
> Flag name on chrome://flagsNone
>
> Finch feature namePadding: PrivacySandboxAggregationServiceReportPadding
> All other features: PrivateAggregationApiBundledEnhancements
>
> Requires code in //chrome?Only for settings checks
>
> Tracking bughttps://crbug.com/1481761
>
> Launch bughttps://launch.corp.google.com/launch/4272421
>
> Estimated milestones
>
> We intend to ship in M119.
>
> Anticipated spec changes
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5205079858085888
>
> Links to previous Intent discussions
>
> Previous I2S
> 
>
> This intent message was generated by Chrome

Re: [blink-dev] Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <
blink-dev@chromium.org> wrote:

> Great follow up to
> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ.
> Big fan!
>
> On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>> phan...@microsoft.com, h...@chromium.org
>>
>> Specification
>> https://datatracker.ietf.org/doc/rfc8446
>>
>
This is an interesting simple case where I agree that an explainer for this
would be superfluous (as the Summary sums up what you're planning to ship).


>
>>
>> Summary
>>
>> Randomize the order of DTLS ClientHello extensions, to reduce potential
>> ecosystem brittleness.
>>
>>
>> This is a WebRTC specific follow-up to
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ
>>  which
>> launched successfully a while back.
>>
>>
>> WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP
>> and also uses a SRTP specific extension (use_srtp defined in RFC 5764) to
>> negotiate encryption keys.
>>
>> Middleboxes might expect the use_srtp flag in a certain position which
>> changes with this feature.
>>
>>
>> Blink component
>> Blink>WebRTC
>> 
>>
>> TAG review
>> None
>>
>> TAG review status
>> Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> It is possible that WebRTC's ClientHello extension ordering is already
>> ossified. This change may cause compatibility issues with middleboxes, SBCs
>> or other network monitoring software. We will do a slow rollout and monitor
>> breakage.
>>
>
Presumably, this will be behind a base feature to support the slow rollout?

Also, I assume the TLS side of things went smoothly. Any reason to believe
DTLS would be significantly worse?


>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/709) Applied to
>> TLS and DTLS equally
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/92)
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> n/a, not developer facing
>>
>>
>> Activation
>>
>> n/a, not developer facing
>>
>>
>> Security
>>
>> Using a fixed extension order can encourage server implementers to
>> fingerprint Chrome and then assume specific implementation behavior. This
>> can limit ecosystem agility when Chrome implements future modifications to
>> DTLS, if the server implementations are not prepared for Chrome to change
>> its ClientHello. Chrome will randomly order extensions, subject to the
>> pre_shared_key constraint in the RFC. This will reduce the risk of server
>> and middleboxes fixating on details of our current ClientHello. This should
>> make the DTLS ecosystem more robust to changes.
>>
>>
>> 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
>>
>> n/a, inner function of TLS stack. Possible to inspect using tools like
>> Wireshark
>>
>>
>> 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
>> 
>> ?
>> No
>>
>> Flag name on chrome://flags
>> None
>>
>> Finch feature name
>> WebRTC-PermuteTlsClientHello
>>
>> Requires code in //chrome?
>> False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/webrtc/issues/detail?id=15467
>>
>> Estimated milestones
>> Shipping on desktop 120
>>
>>
>> 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).*
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5191245718880256
>>
>> 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/CADxkKi%2BWEyR_PRHcAfNNR0w1SECOZ%2B3PqVN3x%3DGcYjK10tE6sg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)