Re: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

['Jiaming Cheng' via blink-dev]

Hi Alex, Chris and Daniel,

Thank you for your valuable feedback!

I've addressed your comments and taken the following updates:

Hey Alex, the ChapterInformation *does* apply to audio as well as video,
since MediaSession is for both audio and video. I've updated the Chrome
status to reflect this.

Additionally, I've taken the following actions:

   - Added WPT test:
   https://chromium-review.googlesource.com/c/chromium/src/+/5516503
   - Filed TAG review: https://github.com/w3ctag/design-reviews/issues/952
   - Filed WebKit review:
   https://github.com/WebKit/standards-positions/issues/344
   - Filed Gecko review:
   https://github.com/mozilla/standards-positions/issues/1019


I will keep you updated on the progress of these reviews and notify you
once they are approved. Let me know if you have any questions :]

Best,
Jiaming

On Wed, May 1, 2024 at 8:57 AM Alex Russell 
wrote:

> Hey folks,
>
> On reviewing this, I'm concerned that this isn't also addressing the same
> needs for Audio. This would have come up in a TAG review, and probably
> would have been fleshed out in an Explainer. Would like to see those before
> this progresses.
>
> Best,
>
> Alex
>
> On Tuesday, April 30, 2024 at 3:35:45 PM UTC-7 dan...@microsoft.com wrote:
>
>> I was curious about WPT coverage for this and found
>> https://wpt.fyi/results/mediasession/mediametadata.html
>>
>>
>>
>> Maybe that could be updated to check for the basics of the new attribute?
>>
>>
>>
>> -- Dan
>>
>>
>>
>> *From:* 'Jiaming Cheng' via blink-dev 
>> *Sent:* Tuesday, April 30, 2024 1:50 PM
>> *To:* blink-dev@chromium.org
>> *Cc:* Alex Newcomer ; Megan Fu ;
>> Tommy Steimel ; Andrew Xu 
>> *Subject:* [blink-dev] Intent to Ship: Support Video Chapter in
>> MediaMetadata
>>
>>
>> Contact emails
>>
>> jiami...@google.com
>>
>>
>> Explainer
>>
>> https://github.com/w3c/mediasession/pull/308
>>
>>
>> Specification
>>
>> https://www.w3.org/TR/mediasession/#the-chapterinformation-interface
>>
>>
>> Summary
>>
>> The corresponding implementation on the blink layer based on the w3c api
>> change, which is to add the `ChapterInformation` attribute in the existing
>> `MediaMetadata` See the propose:
>> https://github.com/w3c/mediasession/issues/273
>>
>>
>>
>>
>> Blink component
>>
>> Blink>Media>Session
>> 
>>
>>
>> TAG review
>>
>> None
>>
>>
>> TAG review status
>>
>> Not applicable
>>
>>
>> Risks
>>
>>
>>
>>
>> Interoperability and Compatibility
>>
>> It’s low risk as it's a small addition to an existing API that both Gecko
>> and WebKit approve of
>>
>>
>>
>> *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
>>
>>
>>
>>
>> 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
>>
>>
>> Flag name on chrome://flags
>>
>> MediaSessionChapterInformation
>>
>>
>> Finch feature name
>>
>> None
>>
>>
>> Non-finch justification
>>
>> None
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Sample links
>>
>>
>> https://googlechrome.github.io/samples/media-session/video.html
>>
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 126
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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/6682585059295232?gate=5003115407605760
>>
>> 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/CABE8buQTGirUaRRsr9ooud9S%3Dg0OquQy6rGy%2BvnrDtT7T%2BqK%2BQ%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

['Rick Byers' via blink-dev]

LGTM3

On Friday, May 3, 2024 at 1:34:21 PM UTC-4 Chris Harrelson wrote:

> Thanks for these mini-explainers, they clarified what is changing for me!
>
> LGTM2
>
> On Fri, May 3, 2024 at 9:31 AM 'Akash Nadan' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hi Alex,
>>
>> Thanks for the feedback and sorry for the initial lack of detail! We hope 
>> the following explanations (below) make each of these proposed changes more 
>> clear.
>>
>> We will keep the feedback in mind and make sure to include the level of 
>> detail similar to the Explainer format going forward.
>>
>> 1. Spec verbose debug report for max channel capacity and max trigger 
>> states cardinality 
>> 
>>
>> Currently the API supports a feature called Flexible Event-Level 
>> reporting, which gives API callers additional customization capabilities by 
>> allowing them to change the number of conversion reports, number and length 
>> of reporting windows, and trigger data cardinality per source that they 
>> register.
>>
>> As part of Flexible Event-Level, the API only allows configurations that 
>> do not exceed our current privacy bar (i.e. max channel capacity) of 11.5 
>> bits of information gain for clicks and 6.5 bits of information gain for 
>> views. So currently if an ad-tech using Flexible Event-Level chooses a 
>> configuration that exceeds the current privacy bar their registration will 
>> fail silently. With the addition of the “max channel capacity limit” 
>> verbose signal, ad-techs will now be able to receive a verbose debug report 
>> telling them that they have exceeded the “max channel capacity” and will 
>> allow them to know that they need to use a different configuration and 
>> allow them to identify why their source registrations may be failing. This 
>> new verbose debug report will also help with future features that may be 
>> taken into account when calculating the information gain for a given 
>> configuration.
>>
>> Similarly, as part of ARA source registrations and Flexible Event-Level, 
>> an ad-tech can customize their trigger data cardinality up to a maximum of 
>> 32 trigger states. The “max trigger states cardinality limit” verbose 
>> signal, will allow ad-techs to know if they have set a source registration 
>> that exceeds this maximum threshold on the trigger data cardinality, making 
>> the API easier to debug for ad-techs.
>>
>>
>> 2. Report source reporting origins per site limit explicitly 
>> 
>>
>> Currently the API has a rate limit that only allows a maximum of 1 
>> reporting origin per {source site, reporting site, 1 day} per source 
>> registration. This limit is in place to help prevent ad-techs from cycling 
>> through multiple different reporting origins as a way to measure additional 
>> information on a user.
>>
>> Currently if an ad-tech exceeds this limit, their source registration 
>> will fail silently. In order to make the debugging process easier and help 
>> ad-techs identify a potential cause of data loss, the API will now provide 
>> a verbose signal for this error any time an ad-tech’s registration exceeds 
>> the limit.
>>
>>
>> 3. Gate all source verbose debug reports behind cookie access 
>> 
>>
>> Currently the API provides 9 different source verbose debug signals. All 
>> of these signals require that the ad-tech has set the ar_debug cookie on 
>> the source in order to receive the verbose debug signal, except for two 
>> errors: “source-destination-limit” and “source-destination-rate-limit”. 
>>
>> In order to reduce complexity for ad-techs so that there is no difference 
>> in when an ar_debug cookie needs to be set in order to receive a debug 
>> report across the different error signals, this change will now require the 
>> ar_debug cookie to be set for all source verbose debug signals.
>>
>> This change also has the added benefit of improving privacy by adding an 
>> additional check for the two rate limits listed above.
>>
>>
>> 4. Split attribution rate-limit into separate event & aggregate 
>> rate-limits 
>>
>> Currently the API has a single attribution rate limit of 100 attributions 
>> per {source site, destination site, reporting} per 30 days, and this limit 
>> is across both report types supported in the API (i.e. event-level reports 
>> and aggregate reports). For example, currently if 1 trigger registration 
>> generates both an event-level report and aggregate report this will count 
>> as 1 towards the attribution limit. And if the attribution limit is hit, 
>> neither event-level report nor aggregatable report is created.
>>
>> Now that the API supports a subset of Flexible event-level, there may be 
>> scenarios where 1 trigger registration can generate multiple event-level 
>> reports, but still only 1 

Re: [blink-dev] Intent to Ship: CSS Anchor Positioning

[Mason Freed]

I'd just like to reiterate that we are open to making well-justified
changes to the API shape over the next few months, as concerns arise. I
think that the fact that we're shipping this API makes us *more* (not less)
likely to *a)* surface the need for these changes, and *b)* prioritize them
appropriately.

Thanks,
Mason

On Thu, May 2, 2024 at 7:03 PM Florian Rivoal  wrote:

>
> On 2024/05/03 5:43, Mason Freed wrote:
> > I stand by what I said - we will definitely be open to well-justified
> > changes after we ship! More inline below.
>
> Despite the best intents, the "well-justified" part of this is going to
> be a very quickly raising bar.
>
> The same intent was declared [1] about 'text-wrap: balance' not long
> ago, and shortly after it shipped we wanted to tweak it, and Chrome
> pushed back [2] because of compat concerns.
>
> The people who said then that shipping prior to spec stability was OK
> because making compat breaking changes would be fine if needed were
> sincere. But those who insisted that breaking compat was not worth it
> when we did find things we wanted to change were being reasonable.
>
> 'text-wrap: balance' was a very simple feature, with low complexity, and
> limited impact in terms of potential for breakage. And yet we ended up
> being more constrained than we wished. Anchor positioning is way more
> complex of a feature, so the likelihood we'll discover something we want
> to change is higher, and the impact of potential breakage is higher too,
> since this is a layout feature.
>
> At the point where a number of sites will have started relying on this
> highly anticipated feature, making breaking changes will be pushed back
> against, with good reasons.
>
> [1]
> https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1649927288
> [2]
> https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1658998792
>
> On 2024/05/03 5:43, Mason Freed wrote:
> > Again, we’ve been working through the nuances of this feature for more
> > than 2 years, and this is hardly the first (or second or third) draft.
> > I think the core feature is quite stable.
>
> For a layout spec, 2 years is not especially long.
>
> Moreover, for about half of those 2 years, few people in the working
> group were fully engaged. That's unfortunate, but people's priorities
> cannot always shift quickly, even if they're interested. Fortunately,
> there's now been significant engagement, but that's still recent. Here's
> some imperfect but but illustrative evidence: out of 67 closed issues in
> GitHub, 8 were closed prior to May last year [3], while 59 were closed
> since then [4]. 47 of them were even closed in the last 3 months [5].
> That's absolutely evidence of good progress and engagement, but I
> wouldn't call that stability just yet.
>
> [3]
>
> https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3C2023-05-01+
> [4]
>
> https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3E2023-05-01+
> [5]
>
> https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3E2024-02-03
>
>
> Now, the core concepts of the spec do seem stable at this point. But
> changes don't need to be to core concepts to be breaking.
>
> All in all, I support fantasai's position: an updated implementation in
> experimental features / beta builds, as well as giving the revised spec
> enough time to gather feedback from accessibility reviews and other
> horizontal groups like the TAG, from web developers after Tab presents
> at CSS-day and from beta builds, and from the WG itself now that the
> spec has been updated, seems appropriate.
>
> If the request was to wait for as many years as it took to ship Grid or
> Writing Modes, I would understand (and agree with) the desire to ship
> faster than that. But here I think we're only talking about a few more
> months, and for a feature of this magnitude, that seems worth it to
> ensure we don't lock ourselves into a few unfortunate shortcomings that
> could permanently limit its potential.
>
> —Florian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/bad5411e-814f-478a-9071-971cce1d3232%40rivoal.net
> .
>

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

[blink-dev] Ready for Developer Testing: Call stacks in crash reports from unresponsive web pages

['Issack John' via blink-dev]

Contact emails
issackj...@microsoft.com, 
seth.bren...@microsoft.com

Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
https://github.com/WICG/crash-reporting/issues/12

Specification
None

Design docs

https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing

Summary
This feature captures the JS call stack when a web page becomes unresponsive 
due to JavaScript code running an infinite loop or other very long computation. 
This helps developers to identify the cause of the unresponsiveness and fix it 
more easily. The JS call stack is included in the crash reporting API when the 
reason is unresponsive.


Blink component
Blink>ReportingObserver

TAG review
None

TAG review status
Pending

Risks


Interoperability and Compatibility
None


Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Security
Stack frames from cross-domain scripts that were not loaded with CORS must be 
omitted.


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
Looking for expressions of support for the API from people who have actually 
used it on their local machines. If they can explain what they were able to do 
with the feature that they couldn't do before, that's even better.

Ongoing technical constraints
None


Debuggability
Developers can launch DevTools, go to the "Application" Tab, then in the 
"Background services" section click on "Reporting API" where they can inspect 
reports that are queued to be sent. Application --> Reporting API


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

DevTrial instructions
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md

Flag name on chrome://flags


Finch feature name
DocumentPolicyIncludeJSCallStacksInCrashReports

Requires code in //chrome?
False

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

Estimated milestones
DevTrial on desktop
125


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

Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com

This intent message was generated by Chrome Platform 
Status.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL0PR00MB0740E67CEB87105E07A96D21C21F2%40BL0PR00MB0740.namprd00.prod.outlook.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

[Chris Harrelson]

Thanks for these mini-explainers, they clarified what is changing for me!

LGTM2

On Fri, May 3, 2024 at 9:31 AM 'Akash Nadan' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi Alex,
>
> Thanks for the feedback and sorry for the initial lack of detail! We hope
> the following explanations (below) make each of these proposed changes more
> clear.
>
> We will keep the feedback in mind and make sure to include the level of
> detail similar to the Explainer format going forward.
>
> 1. Spec verbose debug report for max channel capacity and max trigger
> states cardinality
> 
>
> Currently the API supports a feature called Flexible Event-Level
> reporting, which gives API callers additional customization capabilities by
> allowing them to change the number of conversion reports, number and length
> of reporting windows, and trigger data cardinality per source that they
> register.
>
> As part of Flexible Event-Level, the API only allows configurations that
> do not exceed our current privacy bar (i.e. max channel capacity) of 11.5
> bits of information gain for clicks and 6.5 bits of information gain for
> views. So currently if an ad-tech using Flexible Event-Level chooses a
> configuration that exceeds the current privacy bar their registration will
> fail silently. With the addition of the “max channel capacity limit”
> verbose signal, ad-techs will now be able to receive a verbose debug report
> telling them that they have exceeded the “max channel capacity” and will
> allow them to know that they need to use a different configuration and
> allow them to identify why their source registrations may be failing. This
> new verbose debug report will also help with future features that may be
> taken into account when calculating the information gain for a given
> configuration.
>
> Similarly, as part of ARA source registrations and Flexible Event-Level,
> an ad-tech can customize their trigger data cardinality up to a maximum of
> 32 trigger states. The “max trigger states cardinality limit” verbose
> signal, will allow ad-techs to know if they have set a source registration
> that exceeds this maximum threshold on the trigger data cardinality, making
> the API easier to debug for ad-techs.
>
>
> 2. Report source reporting origins per site limit explicitly
> 
>
> Currently the API has a rate limit that only allows a maximum of 1
> reporting origin per {source site, reporting site, 1 day} per source
> registration. This limit is in place to help prevent ad-techs from cycling
> through multiple different reporting origins as a way to measure additional
> information on a user.
>
> Currently if an ad-tech exceeds this limit, their source registration will
> fail silently. In order to make the debugging process easier and help
> ad-techs identify a potential cause of data loss, the API will now provide
> a verbose signal for this error any time an ad-tech’s registration exceeds
> the limit.
>
>
> 3. Gate all source verbose debug reports behind cookie access
> 
>
> Currently the API provides 9 different source verbose debug signals. All
> of these signals require that the ad-tech has set the ar_debug cookie on
> the source in order to receive the verbose debug signal, except for two
> errors: “source-destination-limit” and “source-destination-rate-limit”.
>
> In order to reduce complexity for ad-techs so that there is no difference
> in when an ar_debug cookie needs to be set in order to receive a debug
> report across the different error signals, this change will now require the
> ar_debug cookie to be set for all source verbose debug signals.
>
> This change also has the added benefit of improving privacy by adding an
> additional check for the two rate limits listed above.
>
>
> 4. Split attribution rate-limit into separate event & aggregate
> rate-limits 
>
> Currently the API has a single attribution rate limit of 100 attributions
> per {source site, destination site, reporting} per 30 days, and this limit
> is across both report types supported in the API (i.e. event-level reports
> and aggregate reports). For example, currently if 1 trigger registration
> generates both an event-level report and aggregate report this will count
> as 1 towards the attribution limit. And if the attribution limit is hit,
> neither event-level report nor aggregatable report is created.
>
> Now that the API supports a subset of Flexible event-level, there may be
> scenarios where 1 trigger registration can generate multiple event-level
> reports, but still only 1 aggregate report. Because of this new behavior it
> would not be accurate to count and may negatively impact ad-techs if the
> API tracks the rate limit across both report types.
>
> With this change, the API will now track the 

[blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

Contact emailsbre...@chromium.org, alancut...@chromium.org,
mgi...@chromium.org, loubr...@google.com

Explainer
https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed

Summary

Allow web app windows to have a tab strip. This adds a new display mode
"tabbed" and a new manifest field to allow customizations to the tab strip.


Blink componentBlink>AppManifest


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841

TAG review statusIssues addressed

Chromium Trial NameWebAppTabStrip

Link to origin trial feedback summary
https://github.com/WICG/manifest-incubations/issues

Origin Trial documentation link
https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

Risks


Interoperability and Compatibility



*Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811)

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

*Web developers*: Positive (https://github.com/w3c/manifest/issues/737)

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

N/A


Debuggability

chrome://web-app-internals can be used for debugging, and the new manifest
field could also be added to the DevTools Application pane.


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

The origin trial is available on ChromeOS only. Support for other desktop
platforms is planned.


Is this feature fully tested by web-platform-tests

?Yes

https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member


Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip

Finch feature nameDesktopPWAsTabStrip

Requires code in //chrome?True

Tracking bughttps://issuetracker.google.com/issues/40598974

Launch bughttps://launch.corp.google.com/launch/4253814

MeasurementLaunch.WebAppDisplayMode: Tabbed

Availability expectationFeature is available only on Chrome-on-ChromeOS for
the foreseeable future.

Adoption expectationFeature is used by specific partner(s) to provide
functionality within 12 months of launch in Chrome. May be of interest to a
handful of PWA authors primarily in the productivity space.

Adoption planWorking with a small number of partners directly.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
N/A

Sample links
https://paint-rightful-patch.glitch.me

Estimated milestones
Shipping on desktop 126
Origin trial desktop first 118
Origin trial desktop last 126
Origin trial extension 1 end milestone 126

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).
Chromium implementation currently does not parse string-form URL patterns
as required by the spec. Marked "at risk". (
https://github.com/WICG/manifest-incubations/issues/97)

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5128143454076928?gate=6176288199409664

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ
Intent
to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/m16m2TEq-NM/m/0Bc10numCgAJ
Intent to Extend Experiment 1:
https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ


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

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

['Aaron Selya' via blink-dev]

Thank you for suggesting a deeper dive into this Yoav as I might not have
discovered the significant impact that the "receive-cookie-deprication"
cookies were having on my metrics without your prompting.

I've reached out to some engineers at Paypal and hopefully they'll get back
to me sometime next week.

On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) 
wrote:

> Thanks for diving into this!!
>
> I guess the scariest bit here would be paypal losing a cookie in the
> redirect. Even if you didn't find a visible impact in your testing, they
> may not be exhaustive, and breakage there feels riskier than in other
> mentioned domains.
>
> Have you tried to reach out to Paypal folks and see what they say?
>
> On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:
>
>> My apologies for the delay in following up on this.
>>
>> When I finished my initial implementation and got to the point where I
>> could begin testing, I found that my metrics were being flooded with a
>> cookie named, "receive-cookie-deprication". After doing some research and
>> testing I learned that this cookie is used by sites for testing the
>> potential impact of third party cookie depreciation but doesn't have any
>> impact on website functionality. To get a better sense of potential
>> breakage, I landed updated metrics that filtered out that cookie. I then
>> conducted a manual audit on 10 (of the 104) sites that indicated a possible
>> impact with a build of chromium that had the finch flag turned on.
>>
>> I've summarized my findings in this slide deck
>> 
>> but I was unable to find a breakage that caused a site to not perform as
>> expected from the user's perspective. To be clear, this doesn't mean that
>> there won't be breakage that occurs if/when this feature goes live, only
>> that I was unable to find an example where the website was unable to
>> perform as expected.
>>
>> Additionally, with the filtering out of the "receive-cookie-deprication"
>> cookie from the metrics, the occurrences of an A1->B-A2 cookie which this
>> change would impact drops from 0.032% of overall page loads to 0.0012% of
>> overall page loads.
>>
>
> That's extremely reassuring!
>
>
>>
>> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:
>>
>>> Yoav, your understanding is correct.
>>>
>>> I'm still in the process of finalizing the implementation. Once that is
>>> done, I'll audit some sites that metrics have indicated will
>>> experience breakage and report back my findings.
>>>
>>> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor 
>>> wrote:
>>>
 It would also be helpful to discuss what breakage looks like in this
 case. Would it be a one-time loss of state (i.e., have to log in again), or
 something different?
 On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:

 OK, so just to summarize my understanding:

- We expect this to have some impact on 0.032% of page views
- We have a Finch flag that can be used as a kill switch in case we
see lots of breakage in the wild
- Developers can get around this deprecation by changing their
cookies to be "same-site: none" *and* requesting SAA from users

 Is the above correct?

 If so, 0.032% sounds like a lot. Would it be possible for y'all to same
 pages that trigger that use counter and see how many of them break and what
 does breakage look like?

 On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:

> The flag is a base::features flag named
> kAncestorChainBitEnabledInPartitionedCookies.
>
> Updated the review gates on chromestatus.com
>
> On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Also, can you flip on the relevant review gates in chromestatus.com?
>>
>> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 The first mitigation listed here is to migrate existing
> partitioned cookies to include the new bit, and the second mitigation 
> is to
> have a flag that can disable this feature. Would disabling the 
> feature also
> include migrating the existing cookies back to exclude the new bit?
>

 Disabling the flag would not migrate the existing cookies back to
 exclude the new bit. It would make it so that the new bit value is not
 considered when checking equivalence. Not considering the value of the 
 bit
 when is the current behavior so we anticipate no issues ignoring the 
 bit if
 the flag needs to disable the feature.

>>>
>>> Can you clarify what kind of flag are we talking about? Is this a
>>> 

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

['Akash Nadan' via blink-dev]

Hi Alex,

Thanks for the feedback and sorry for the initial lack of detail! We hope 
the following explanations (below) make each of these proposed changes more 
clear.

We will keep the feedback in mind and make sure to include the level of 
detail similar to the Explainer format going forward.

1. Spec verbose debug report for max channel capacity and max trigger 
states cardinality 


Currently the API supports a feature called Flexible Event-Level reporting, 
which gives API callers additional customization capabilities by allowing 
them to change the number of conversion reports, number and length of 
reporting windows, and trigger data cardinality per source that they 
register.

As part of Flexible Event-Level, the API only allows configurations that do 
not exceed our current privacy bar (i.e. max channel capacity) of 11.5 bits 
of information gain for clicks and 6.5 bits of information gain for views. 
So currently if an ad-tech using Flexible Event-Level chooses a 
configuration that exceeds the current privacy bar their registration will 
fail silently. With the addition of the “max channel capacity limit” 
verbose signal, ad-techs will now be able to receive a verbose debug report 
telling them that they have exceeded the “max channel capacity” and will 
allow them to know that they need to use a different configuration and 
allow them to identify why their source registrations may be failing. This 
new verbose debug report will also help with future features that may be 
taken into account when calculating the information gain for a given 
configuration.

Similarly, as part of ARA source registrations and Flexible Event-Level, an 
ad-tech can customize their trigger data cardinality up to a maximum of 32 
trigger states. The “max trigger states cardinality limit” verbose signal, 
will allow ad-techs to know if they have set a source registration that 
exceeds this maximum threshold on the trigger data cardinality, making the 
API easier to debug for ad-techs.


2. Report source reporting origins per site limit explicitly 


Currently the API has a rate limit that only allows a maximum of 1 
reporting origin per {source site, reporting site, 1 day} per source 
registration. This limit is in place to help prevent ad-techs from cycling 
through multiple different reporting origins as a way to measure additional 
information on a user.

Currently if an ad-tech exceeds this limit, their source registration will 
fail silently. In order to make the debugging process easier and help 
ad-techs identify a potential cause of data loss, the API will now provide 
a verbose signal for this error any time an ad-tech’s registration exceeds 
the limit.


3. Gate all source verbose debug reports behind cookie access 


Currently the API provides 9 different source verbose debug signals. All of 
these signals require that the ad-tech has set the ar_debug cookie on the 
source in order to receive the verbose debug signal, except for two errors: 
“source-destination-limit” and “source-destination-rate-limit”. 

In order to reduce complexity for ad-techs so that there is no difference 
in when an ar_debug cookie needs to be set in order to receive a debug 
report across the different error signals, this change will now require the 
ar_debug cookie to be set for all source verbose debug signals.

This change also has the added benefit of improving privacy by adding an 
additional check for the two rate limits listed above.


4. Split attribution rate-limit into separate event & aggregate rate-limits 


Currently the API has a single attribution rate limit of 100 attributions 
per {source site, destination site, reporting} per 30 days, and this limit 
is across both report types supported in the API (i.e. event-level reports 
and aggregate reports). For example, currently if 1 trigger registration 
generates both an event-level report and aggregate report this will count 
as 1 towards the attribution limit. And if the attribution limit is hit, 
neither event-level report nor aggregatable report is created.

Now that the API supports a subset of Flexible event-level, there may be 
scenarios where 1 trigger registration can generate multiple event-level 
reports, but still only 1 aggregate report. Because of this new behavior it 
would not be accurate to count and may negatively impact ad-techs if the 
API tracks the rate limit across both report types.

With this change, the API will now track the attribution rate limit 
separately for each report type. So in the example above, where a trigger 
registration generates multiple event-level attribution reports, these will 
only count for the event-level report limit, and not impact the aggregate 
attribution rate limit, which 

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions (setMetadata method)

[Yoav Weiss (@Shopify)]

LGTM to extend experimentation until M129 inclusive

On Fri, May 3, 2024 at 5:05 PM Guido Urdaneta  wrote:

> Yes, but since the main motivation is to let developers migrate to the
> final version of the API (which changed in the last milestone of the
> original OT), it would be acceptable to have a shorter extension. This is,
> of course, assuming the I2S for the final version of the API is approved.
>

That's fine! :)


>
> On Fri, May 3, 2024 at 2:39 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Do I understand correctly that you want to extend the OT for 3 more
>> milestones, up to 129 (inclusive)?
>>
>>
>>
>> On Thu, May 2, 2024 at 2:45 PM Guido Urdaneta 
>> wrote:
>>
>>> Contact emails...@chromium.org, gui...@chromium.org,
>>> agpa...@chromium.org
>>>
>>> Explainer
>>> https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md
>>>
>>> Specification
>>> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
>>>
>>> Summary
>>>
>>> Allow WebRTC Encoded Transform API to manipulate audio and video frame
>>> metadata. Some WebRTC Encoded Transform use cases involve manipulation of
>>> not only the payload of encoded video / audio frames but also its metadata.
>>> For example, if a peer connection negotiates a custom codec and an encoded
>>> transform is used to implement part or all of the the custom codec and
>>> needs to set the output codec type as part of the metadata of the output
>>> frame. See https://www.w3.org/2024/04/23-webrtc-minutes.html#t01
>>>
>>>
>>>
>>> Blink componentBlink>WebRTC
>>> 
>>>
>>> TAG reviewThe original full spec was reviewed by TAG here:
>>> https://github.com/w3ctag/design-reviews/issues/531
>>> No TAG review requested yet for the setMetadata method (during the
>>> Working Group discussion it was decided to use a constructor, but interest
>>> in the method version was recently revived).
>>>
>>>
>>> Other use cases:
>>>
>>> https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
>>>
>>> https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
>>>
>>> https://w3c.github.io/webrtc-nv-use-cases/#auction
>>>
>>> TAG review statusPending
>>>
>>> Chromium Trial NameRTCEncodedFrameSetMetadata
>>>
>>> Origin Trial documentation link
>>> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>>>
>>> WebFeature UseCounter nameRTCEncodedFrameSetMetadata
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk: There is always the risk that other browsers will
>>> not implement this feature. This risk is mitigated by alignment across
>>> browser vendors in the W3C WebRTC Working Group around the spec.
>>> Compatibility risk: This is a new feature intended to support new use
>>> cases. It introduces no breaking changes, so we do not expect any
>>> compatibility issues.
>>>
>>> *Gecko*: No signal
>>> However, they have shown interest in reviving the discussion for the
>>> setMetadata() method after achieving consensus on the Custom Codec
>>> negotiation API for WebRTC Encoded Transform.
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Positive
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This feature is an extension to WebRTC Encoded Transform, which itself
>>> is an extension to WebRTC/RTCPeerConnection.
>>>
>>>
>>> Activation
>>>
>>> No significant risks identified.
>>>
>>>
>>> Security
>>>
>>> No new security risks identified.
>>>
>>>
>>> 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?
>>>
>>> No
>>>
>>>
>>> Goals for experimentation
>>>
>>> Determine if the proposed API properly supports the intended use case.
>>>
>>>
>>> Reason this experiment is being extended
>>>
>>> There are two reasons to request this extension: 1. This proposal
>>> initially started as a setMetadata() method on encoded frames, but the
>>> result of discussions in the W3C WebRTC Working Group was that introducing
>>> a constructor (instead of a method) was a better fit for the use cases for
>>> which there was consensus in the WG. After a few iterations over the
>>> constructor API shape, the WG achieved consensus recently and we have sent
>>> an Intent to Ship for that. However, the final version of the constructor
>>> only became available in M126 (the last milestone of the Origin Trial) and
>>> we would like to give developers a little more time to migrate to the
>>> shipped version of the API. 2. After achieving consensus on the constructor
>>> with custom metadata, a new use case has been discussed in the WG that has
>>> revived interest in the original setMetadata() proposal. The WG has
>>> achieved consensus on a new API for custom codec negotiation for which
>>> setMetadata() looks like a better fit than the 

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions (setMetadata method)

[Guido Urdaneta]

Yes, but since the main motivation is to let developers migrate to the
final version of the API (which changed in the last milestone of the
original OT), it would be acceptable to have a shorter extension. This is,
of course, assuming the I2S for the final version of the API is approved.

On Fri, May 3, 2024 at 2:39 PM Yoav Weiss (@Shopify) 
wrote:

> Do I understand correctly that you want to extend the OT for 3 more
> milestones, up to 129 (inclusive)?
>
>
>
> On Thu, May 2, 2024 at 2:45 PM Guido Urdaneta  wrote:
>
>> Contact emails...@chromium.org, gui...@chromium.org, agpa...@chromium.org
>>
>> Explainer
>> https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md
>>
>> Specification
>> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
>>
>> Summary
>>
>> Allow WebRTC Encoded Transform API to manipulate audio and video frame
>> metadata. Some WebRTC Encoded Transform use cases involve manipulation of
>> not only the payload of encoded video / audio frames but also its metadata.
>> For example, if a peer connection negotiates a custom codec and an encoded
>> transform is used to implement part or all of the the custom codec and
>> needs to set the output codec type as part of the metadata of the output
>> frame. See https://www.w3.org/2024/04/23-webrtc-minutes.html#t01
>>
>>
>>
>> Blink componentBlink>WebRTC
>> 
>>
>> TAG reviewThe original full spec was reviewed by TAG here:
>> https://github.com/w3ctag/design-reviews/issues/531
>> No TAG review requested yet for the setMetadata method (during the
>> Working Group discussion it was decided to use a constructor, but interest
>> in the method version was recently revived).
>>
>>
>> Other use cases:
>>
>> https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
>>
>> https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
>>
>> https://w3c.github.io/webrtc-nv-use-cases/#auction
>>
>> TAG review statusPending
>>
>> Chromium Trial NameRTCEncodedFrameSetMetadata
>>
>> Origin Trial documentation link
>> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>>
>> WebFeature UseCounter nameRTCEncodedFrameSetMetadata
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Interoperability risk: There is always the risk that other browsers will
>> not implement this feature. This risk is mitigated by alignment across
>> browser vendors in the W3C WebRTC Working Group around the spec.
>> Compatibility risk: This is a new feature intended to support new use
>> cases. It introduces no breaking changes, so we do not expect any
>> compatibility issues.
>>
>> *Gecko*: No signal
>> However, they have shown interest in reviving the discussion for the
>> setMetadata() method after achieving consensus on the Custom Codec
>> negotiation API for WebRTC Encoded Transform.
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Positive
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This feature is an extension to WebRTC Encoded Transform, which itself is
>> an extension to WebRTC/RTCPeerConnection.
>>
>>
>> Activation
>>
>> No significant risks identified.
>>
>>
>> Security
>>
>> No new security risks identified.
>>
>>
>> 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?
>>
>> No
>>
>>
>> Goals for experimentation
>>
>> Determine if the proposed API properly supports the intended use case.
>>
>>
>> Reason this experiment is being extended
>>
>> There are two reasons to request this extension: 1. This proposal
>> initially started as a setMetadata() method on encoded frames, but the
>> result of discussions in the W3C WebRTC Working Group was that introducing
>> a constructor (instead of a method) was a better fit for the use cases for
>> which there was consensus in the WG. After a few iterations over the
>> constructor API shape, the WG achieved consensus recently and we have sent
>> an Intent to Ship for that. However, the final version of the constructor
>> only became available in M126 (the last milestone of the Origin Trial) and
>> we would like to give developers a little more time to migrate to the
>> shipped version of the API. 2. After achieving consensus on the constructor
>> with custom metadata, a new use case has been discussed in the WG that has
>> revived interest in the original setMetadata() proposal. The WG has
>> achieved consensus on a new API for custom codec negotiation for which
>> setMetadata() looks like a better fit than the constructor since it doesn't
>> require copying the payload of the encoded frame. So the WG might achieve
>> consensus on adding setMetadata() after all. See the resolution of
>> https://www.w3.org/2024/04/23-webrtc-minutes.html#t01 Since
>> setMetadata() might be added to the spec in addition to the 

[blink-dev] Intent to Prototype: Find-in-page highlight pseudos

[Delan Azabani]

Contact emails
schen...@chromium.org, dazab...@igalia.com Explainer
https://github.com/Igalia/explainers/blob/66623464ba1f2410a130d687116302b4a30b1148/css/find-in-page/README.md
[1] Specification
None yet; to be specified in
https://drafts.csswg.org/css-pseudo/#highlight-pseudos [2]  Summary
Exposes find-in-page search results to authors as a highlight
pseudo-element, like selections and spelling errors. This allows authors
to change the foreground and background colors or add text decorations,
which can be especially useful if the UA defaults have insufficient
contrast with the page colors or are otherwise unsuitable. Blink
component
Blink>CSS [3] Motivation
Authors would like to customize the highlighted text from find-in-page
to have a style consistent with that of the rest of the page. In
particular, the existing find-in-page highlights may offer poor
contrast, harming accessibility. The find-in-page highlights may also
conflict with other highlights on the page, such as syntax highlighting.
Initial public proposal
https://github.com/w3c/csswg-drafts/issues/3812 [4] Search tags
search [5] TAG review
None TAG review status
Pending 

RISKS

 Interoperability and Compatibility
None 

_Gecko_: Not yet requested 

_WebKit_: Not formally requested, but feedback on the CSS WG issue and
in meetings. Unlikely to implement due to Safari's unique UI behavior,
but not opposed to the spec as long as UAs are allowed to parse but
ignore the pseudo. CSS Working Group discussed and is OK with moving
forward with prototyping under these conditions. 

_Web developers_: Resolve problems with choosing code syntax
highlighting colors
https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181
[6]; Explicit request for the feature How to style/detect highlighted
boxes generated from browser native search in page - Stack Overflow [7];
Another use case Confuse browsers in-built "find in page" feature -
Stack Overflow [8] 

_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 [9]?
Not yet; tests will be written during the spec and impl process Flag
name on chrome://flags
#enable-experimental-web-platform-features
SearchTextHighlightPseudo 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/5195073796177920 [10] 

This intent message was generated by Chrome Platform Status [11]. 

Links:
--
[1]
https://github.com/Igalia/explainers/blob/66623464ba1f2410a130d687116302b4a30b1148/css/find-in-page/README.md
[2] https://drafts.csswg.org/css-pseudo/#highlight-pseudos
[3]
https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS
[4] https://github.com/w3c/csswg-drafts/issues/3812
[5] https://chromestatus.com/features#tags:search
[6]
https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181
[7]
https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa
[8]
https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature
[9]
https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md
[10] https://chromestatus.com/feature/5195073796177920
[11] https://chromestatus.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/c447ed4dfd05b588e2afc650277371fd%40igalia.com.

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

[Yoav Weiss (@Shopify)]

Thanks for diving into this!!

I guess the scariest bit here would be paypal losing a cookie in the
redirect. Even if you didn't find a visible impact in your testing, they
may not be exhaustive, and breakage there feels riskier than in other
mentioned domains.

Have you tried to reach out to Paypal folks and see what they say?

On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:

> My apologies for the delay in following up on this.
>
> When I finished my initial implementation and got to the point where I
> could begin testing, I found that my metrics were being flooded with a
> cookie named, "receive-cookie-deprication". After doing some research and
> testing I learned that this cookie is used by sites for testing the
> potential impact of third party cookie depreciation but doesn't have any
> impact on website functionality. To get a better sense of potential
> breakage, I landed updated metrics that filtered out that cookie. I then
> conducted a manual audit on 10 (of the 104) sites that indicated a possible
> impact with a build of chromium that had the finch flag turned on.
>
> I've summarized my findings in this slide deck
> 
> but I was unable to find a breakage that caused a site to not perform as
> expected from the user's perspective. To be clear, this doesn't mean that
> there won't be breakage that occurs if/when this feature goes live, only
> that I was unable to find an example where the website was unable to
> perform as expected.
>
> Additionally, with the filtering out of the "receive-cookie-deprication"
> cookie from the metrics, the occurrences of an A1->B-A2 cookie which this
> change would impact drops from 0.032% of overall page loads to 0.0012% of
> overall page loads.
>

That's extremely reassuring!


>
> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:
>
>> Yoav, your understanding is correct.
>>
>> I'm still in the process of finalizing the implementation. Once that is
>> done, I'll audit some sites that metrics have indicated will
>> experience breakage and report back my findings.
>>
>> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor 
>> wrote:
>>
>>> It would also be helpful to discuss what breakage looks like in this
>>> case. Would it be a one-time loss of state (i.e., have to log in again), or
>>> something different?
>>> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>>>
>>> OK, so just to summarize my understanding:
>>>
>>>- We expect this to have some impact on 0.032% of page views
>>>- We have a Finch flag that can be used as a kill switch in case we
>>>see lots of breakage in the wild
>>>- Developers can get around this deprecation by changing their
>>>cookies to be "same-site: none" *and* requesting SAA from users
>>>
>>> Is the above correct?
>>>
>>> If so, 0.032% sounds like a lot. Would it be possible for y'all to same
>>> pages that trigger that use counter and see how many of them break and what
>>> does breakage look like?
>>>
>>> On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:
>>>
 The flag is a base::features flag named
 kAncestorChainBitEnabledInPartitionedCookies.

 Updated the review gates on chromestatus.com

 On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
 yoavwe...@chromium.org> wrote:

> Also, can you flip on the relevant review gates in chromestatus.com?
>
> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> The first mitigation listed here is to migrate existing
 partitioned cookies to include the new bit, and the second mitigation 
 is to
 have a flag that can disable this feature. Would disabling the feature 
 also
 include migrating the existing cookies back to exclude the new bit?

>>>
>>> Disabling the flag would not migrate the existing cookies back to
>>> exclude the new bit. It would make it so that the new bit value is not
>>> considered when checking equivalence. Not considering the value of the 
>>> bit
>>> when is the current behavior so we anticipate no issues ignoring the 
>>> bit if
>>> the flag needs to disable the feature.
>>>
>>
>> Can you clarify what kind of flag are we talking about? Is this a
>> Finch flag we expect to turn off if we encounter lots of breakage? An
>> enterprise policy flag? A flag we expect users to use? (I doubt it's the
>> latter, but clarifications would help :D)
>>
>>
>>>
>>>
 And somewhat related, but does the format of the cookie request
 developers make have to change too, or is this bit determination purely
 done within the browser?

>>>
>>> In almost all cases this is set within the 

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions (setMetadata method)

[Yoav Weiss (@Shopify)]

Do I understand correctly that you want to extend the OT for 3 more
milestones, up to 129 (inclusive)?



On Thu, May 2, 2024 at 2:45 PM Guido Urdaneta  wrote:

> Contact emails...@chromium.org, gui...@chromium.org, agpa...@chromium.org
>
> Explainer
> https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md
>
> Specification
> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
>
> Summary
>
> Allow WebRTC Encoded Transform API to manipulate audio and video frame
> metadata. Some WebRTC Encoded Transform use cases involve manipulation of
> not only the payload of encoded video / audio frames but also its metadata.
> For example, if a peer connection negotiates a custom codec and an encoded
> transform is used to implement part or all of the the custom codec and
> needs to set the output codec type as part of the metadata of the output
> frame. See https://www.w3.org/2024/04/23-webrtc-minutes.html#t01
>
>
>
> Blink componentBlink>WebRTC
> 
>
> TAG reviewThe original full spec was reviewed by TAG here:
> https://github.com/w3ctag/design-reviews/issues/531
> No TAG review requested yet for the setMetadata method (during the Working
> Group discussion it was decided to use a constructor, but interest in the
> method version was recently revived).
>
>
> Other use cases:
>
> https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
>
> https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
>
> https://w3c.github.io/webrtc-nv-use-cases/#auction
>
> TAG review statusPending
>
> Chromium Trial NameRTCEncodedFrameSetMetadata
>
> Origin Trial documentation link
> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>
> WebFeature UseCounter nameRTCEncodedFrameSetMetadata
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: There is always the risk that other browsers will
> not implement this feature. This risk is mitigated by alignment across
> browser vendors in the W3C WebRTC Working Group around the spec.
> Compatibility risk: This is a new feature intended to support new use
> cases. It introduces no breaking changes, so we do not expect any
> compatibility issues.
>
> *Gecko*: No signal
> However, they have shown interest in reviving the discussion for the
> setMetadata() method after achieving consensus on the Custom Codec
> negotiation API for WebRTC Encoded Transform.
>
> *WebKit*: No signal
>
> *Web developers*: Positive
>
> *Other signals*:
>
> Ergonomics
>
> This feature is an extension to WebRTC Encoded Transform, which itself is
> an extension to WebRTC/RTCPeerConnection.
>
>
> Activation
>
> No significant risks identified.
>
>
> Security
>
> No new security risks identified.
>
>
> 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?
>
> No
>
>
> Goals for experimentation
>
> Determine if the proposed API properly supports the intended use case.
>
>
> Reason this experiment is being extended
>
> There are two reasons to request this extension: 1. This proposal
> initially started as a setMetadata() method on encoded frames, but the
> result of discussions in the W3C WebRTC Working Group was that introducing
> a constructor (instead of a method) was a better fit for the use cases for
> which there was consensus in the WG. After a few iterations over the
> constructor API shape, the WG achieved consensus recently and we have sent
> an Intent to Ship for that. However, the final version of the constructor
> only became available in M126 (the last milestone of the Origin Trial) and
> we would like to give developers a little more time to migrate to the
> shipped version of the API. 2. After achieving consensus on the constructor
> with custom metadata, a new use case has been discussed in the WG that has
> revived interest in the original setMetadata() proposal. The WG has
> achieved consensus on a new API for custom codec negotiation for which
> setMetadata() looks like a better fit than the constructor since it doesn't
> require copying the payload of the encoded frame. So the WG might achieve
> consensus on adding setMetadata() after all. See the resolution of
> https://www.w3.org/2024/04/23-webrtc-minutes.html#t01 Since setMetadata()
> might be added to the spec in addition to the constructor, we would like to
> extend the trial to allow developers to continue experimenting with it.
>
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> N/A
>
>
> 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
>
>
> 

[blink-dev] PSA: ComputePressure API: Rename of attribute supportedSources to knownSources.

[Mandy, Arnaud]

Based on feedback from MDN, (issue 
#266) and corresponding 
specification change, 
supportedSources attribute is renamed to 
knowSources.

The change is already taking effect in M125 when Compute Pressure API is 
released as stable API.

Arnaud

-- 
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/DS0PR11MB7902F2ADB3A3EC798A0A74E9931F2%40DS0PR11MB7902.namprd11.prod.outlook.com.