Re: [blink-dev] Intent to Ship: Fenced Frames - Functionality Updates

['Daniel Vogelheim' via blink-dev]

Hi Liam,

This intent has come up in the OWP security triage, and I'm trying to
figure out whether there's XSS potential in the 3rd sub-feature, "Creative
macros in FFAR". This looks like a string-based pattern replacement where
the result string will then be parsed by the browser. Similar things have
lent themselves to XSS, e.g. when a string value contains meta characters
that code downstream will then parse in unexpected ways. Unfortunately, I
can't seem to find enough information about how exactly the replacement &
subsequent usage works to make up my mind whether there's a concern or not.
Could you help me out with a bit more information?

What I've found is this:
- In "send a beacon": "TODO: Substitute macros from |macro map|
into |destination url|." (source
)
- In "asynchronously finish reporting" I find where macro map
being set, but then it says: "TODO: Pass |macroMap| and
|allowedReportingOrigins| to [=Finalize a reporting destination=] when it
is updated to take the parameters." (source
) I can't find that
usage.

Questions I have:
- Am I reading the right docs? Where else should I look?
- Is this meant as a simple string-based substitution? Is there any
filtering of allowed characters, or so?
- What happens with the result values?
- Is the entity that sets the macro values always the same that has set the
patterns the values are being used for, or could those be different
entities?

Thanks!


On Fri, Aug 25, 2023 at 9:34 PM 'Liam Brady' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> shivani...@chromium.org, d...@chromium.org, jkar...@chromium.org,
> lbr...@google.com
> Explainer(s)
>
> Send Automatic Beacons Once
>
> https://github.com/WICG/turtledove/pull/718
>
> Serializable Fenced Frames Configs - Minor Change, No explainer available.
>
> Note: With this change, FencedFrameConfig objects will be serializable and
> can be sent through "postMessage()" and other similar calls.
>
> Creative Macros in Fenced Frames Ads Reporting (FFAR)
>
> https://github.com/WICG/turtledove/pull/763
>
> Spec(s)
>
> Send Automatic Beacons Once
>
> https://github.com/WICG/fenced-frame/pull/109
>
> Serializable Fenced Frames Configs
>
> https://github.com/WICG/fenced-frame/pull/111
>
> Creative Macros in Fenced Frames Ads Reporting (FFAR)
>
> Protected Audience: https://github.com/WICG/turtledove/pull/762/files
>
> Fenced Frames: https://github.com/WICG/fenced-frame/pull/113
>
>
>
> Summary
>
> We launched Fenced Frames as a part of Chrome 115. We would like to add
> the following three functionalities to Fenced Frames.
>
> 1. Send Automatic Beacons Once
>
> A common feature in ad frames is the "why this ad?" link. Since that link
> is separate from the ad itself, clicking "why this ad?", and its subsequent
> navigation, should be considered different from clicking directly on the
> advertisement itself. With our current automatic beacon design, however,
> once an automatic beacon is set (usually in the click handler for the ad
> link), that beacon will send out for any subsequent top-level navigations,
> including if "why this ad?" is clicked. This can result in erroneous
> impressions being sent out.
>
> As a solution, this feature introduces a new "once" member to the
> FenceEvent 
> dictionary passed into
> "window.fence.setReportEventDataForAutomaticBeacons()". If set to true, the
> saved automatic beacon data will be cleared out after the next beacon is
> sent, ensuring that automatic beacons with that data are only sent once.
> This means that further clicks to non-ad parts of the frame that result in
> top-level navigations will not send out erroneous beacons.
>
> (This feature already shipped in M116. That was our mistake. At the time,
> we thought we would only need a PSA for it, and shipped it without it being
> behind a flag. We apologize for the mistake.)
>
> 2. Serializable FencedFramesConfigs
>
> With this change, FencedFrameConfig objects will be serializable and can
> be sent through "postMessage()" and other similar calls. Serialization
> allows for a case where the frame that runs an ad auction is not the same
> frame that ends up embedding the winning ad in a fenced frame.
> FencedFrameConfigs cannot be serialized to storage, nor can they be sent in
> a message that crosses a fenced frame boundary. A FencedFrameConfig object
> is only valid in the traversable navigable
>  it was
> originally created in, and, if sent outside to a different context, will
> not be able to navigate, since the new traversable navigable
> 's fenced
> frame config mapping
> 
> will not contain the internal config needed to do the navi

[blink-dev] PSA: Disallowing unknown import attributes keys

[Nicolò Ribaudo]

Hello,

we are implementing a breaking change to Chromium's import attributes 
implementation.

The import attributes proposal (https://tc39.es/proposal-import-attributes/, 
previously known as "import assertions") was recently updated to throw on 
unknown attribute keys, rather than ignoring them. Currently the only valid 
attribute is "type", defined by the HTML specification (for JSON and CSS 
imports) and by https://tc39.es/proposal-json-modules/.

The previous version of this proposal has been implemented in Chromium for 
two years, and we are now updating to the new semantics.

While this is technically a breaking change, the compatibility risk is very 
low:
- The upper bound of import attributes usage is 
https://chromestatus.com/metrics/feature/timeline/popularity/4528.
- None of the top websites listed in the link above uses unknown attributes.
- No tool implemented attributes other than "type" (other than TypeScript's 
"resolution-mode", which is only valid when using the TS-specific import 
type syntax), so it's unlikely that somebody is shipping unknown attributes 
thinking that they are being compiled away by some tool.
- A typo in type would already result in an error, since type is only used 
for CSS&JSON imports and it's mandatory.
- Of the 9.6k results on GitHub for import assertions usage (
/import.*assert\s*\{/ 
),
 
only 4 Node.js projects use an unknown "integrity" one (found by manually 
analyzing the results for /import.*assert\s*\{.*[^\s"'type].*:.*\}/ 
).
 
Most of the results with unknown attributes are tests for various parsers 
or implementations.

As such, this change is safe to ship.

You can find the ChromeStatus entry at 
https://chromestatus.com/feature/5123137502445568.

Thanks,
Nicolò Ribaudo

-- 
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/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org.

[blink-dev] RE: Removing FocuslessSpatialNavigation runtime-enabled-feature

[서준호]

Hi David,Thanks for noticing about incoming change.We dicussed about your question internally, and it seems like we(LG) are neither using the flag nor affected by removing the feature(at least in our major product).So we don't have any objection for your work in upstream.Again, we could catch the incoming upstream change by your kindly message. Thank you :)P.S:By the way, I cannot access to https://bugs.chromium.org/p/chromium/issues/detail?id=919158 (permission denied)Would you grant me for the link?Best Regards,JunHo --  Original Message  --

>From : "David Bokan" 
To : "blink-dev" , 송효진 책임연구원(hyojin22.song), 서준호 책임연구원(junho0924.seo)
Date : 2023/08/24 01:21:52 [GMT+09:00]
Subject : Removing FocuslessSpatialNavigation runtime-enabled-feature



Hi all,We added the FocuslessSpatialNavigation feature to modify how spatial-navigation works back in 2019, however, it was never used for our use-case so I'd like to remove it.However, since it was mostly working I just want to double check that there aren't any other embedders currently relying on this flag?If I don't hear back in the affirmative by next week I'll remove this code path in M118.Thanks,David




-- 
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/OF2D1A280D.8CF7BA56-ON49258A19.002CA6EE-49258A19.002CA6F1%40lge.com.

[blink-dev] Intent to Experiment: X25519Kyber768 key encapsulation for TLS

['David Adrian' via blink-dev]

Contact emailsdadr...@google.com

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

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

Summary

Protect current Chrome TLS traffic against future quantum cryptanalysis by
deploying the Kyber768 quantum-resistant key agreement algorithm. This is a
hybrid X25519 + Kyber768 key agreement based on an IETF standard. This
specification and launch is outside the scope of W3C. This key agreement
will be launched as a TLS cipher, and should be transparent to users.
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html


Blink componentInternals>Network>SSL


Search tagstls , kem
, kyber
, postquantum


TAG review

TAG review statusPending

Risks


Interoperability and Compatibility

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


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/874) Firefox is also
in the process of rolling this out.

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

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



Goals for experimentation

This is a Finch experiment, not site opt-in.

We are aiming to shake out bugs and incompatibilities with buggy TLS stacks
that do not correctly handle large TLS ClientHellos. Announcing a public
timeline for experimenting on stable provides the necessary justification
for teams at companies who have buggy TLS stacks to prioritize fixing the
bugs.

Ongoing technical constraints



Debuggability



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://flagsenable-tls13-kyber

Finch feature namePostQuantumKyber

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442377

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

Estimated milestones
Shipping on desktop 119
OriginTrial desktop last 118
OriginTrial desktop first 117
DevTrial on desktop 115
Shipping on Android 119
OriginTrial Android last 118
OriginTrial Android first 117
DevTrial on Android 115
Shipping on WebView 119

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com

This intent message was generated by Chrome Platform Status
.

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

Re: [blink-dev] PSA: Disallowing unknown import attributes keys

[Mike Taylor]

On 8/28/23 5:33 AM, Nicolò Ribaudo wrote:


Hello,

we are implementing a breaking change to Chromium's import attributes 
implementation.


The import attributes proposal 
(https://tc39.es/proposal-import-attributes/, previously known as 
"import assertions") was recently updated to throw on unknown 
attribute keys, rather than ignoring them. Currently the only valid 
attribute is "type", defined by the HTML specification (for JSON and 
CSS imports) and by https://tc39.es/proposal-json-modules/.


The previous version of this proposal has been implemented in Chromium 
for two years, and we are now updating to the new semantics.


While this is technically a breaking change, the compatibility risk is 
very low:
- The upper bound of import attributes usage is 
https://chromestatus.com/metrics/feature/timeline/popularity/4528.
- None of the top websites listed in the link above uses unknown 
attributes.
- No tool implemented attributes other than "type" (other than 
TypeScript's "resolution-mode", which is only valid when using the 
TS-specific import type syntax), so it's unlikely that somebody is 
shipping unknown attributes thinking that they are being compiled away 
by some tool.
- A typo in type would already result in an error, since type is only 
used for CSS&JSON imports and it's mandatory.
- Of the 9.6k results on GitHub for import assertions usage 
(/import.*assert\s*\{/ 
), 
only 4 Node.js projects use an unknown "integrity" one (found by 
manually analyzing the results for 
/import.*assert\s*\{.*[^\s"'type].*:.*\}/ 
). 
Most of the results with unknown attributes are tests for various 
parsers or implementations.


I searched for "sha384-abc123" instead 
, and found 10 
Node projects using this integrity key with seemingly copypasta 
sha384-abc123. It seems like your search regexp doesn't account for keys 
on new lines (probably possible w/ github search?). Maybe worth double 
checking to see if nothing new pops up.


(Also, might be nice to file issues and let folks know their projects 
are going to break, especially if the number is this small.)




As such, this change is safe to ship.
Are you implementing behind a feature flag, in case it turns out to not 
be safe?


You can find the ChromeStatus entry at 
https://chromestatus.com/feature/5123137502445568.


Thanks,
Nicolò Ribaudo

--
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/192d117b-b2b9-4835-a6bd-bf5e49b64757n%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/a2130ab4-28ef-4b94-b7cb-f78ef9c16b15%40chromium.org.

Re: [blink-dev] Intent to Ship: Fenced Frames - Functionality Updates

['Liam Brady' via blink-dev]

Note that these features are targeted at M117. Will defer to gtanzer@ to 
answer the FFAR questions.

On Monday, August 28, 2023 at 9:35:34 AM UTC-4 Daniel Vogelheim wrote:

> Hi Liam,
>
> This intent has come up in the OWP security triage, and I'm trying to 
> figure out whether there's XSS potential in the 3rd sub-feature, "Creative 
> macros in FFAR". This looks like a string-based pattern replacement where 
> the result string will then be parsed by the browser. Similar things have 
> lent themselves to XSS, e.g. when a string value contains meta characters 
> that code downstream will then parse in unexpected ways. Unfortunately, I 
> can't seem to find enough information about how exactly the replacement & 
> subsequent usage works to make up my mind whether there's a concern or not. 
> Could you help me out with a bit more information?
>
> What I've found is this:
> - In "send a beacon": "TODO: Substitute macros from |macro map| 
> into |destination url|." (source 
> )
> - In "asynchronously finish reporting" I find where macro map 
> being set, but then it says: "TODO: Pass |macroMap| and 
> |allowedReportingOrigins| to [=Finalize a reporting destination=] when it 
> is updated to take the parameters." (source 
> ) I can't find that 
> usage.
>
> Questions I have:
> - Am I reading the right docs? Where else should I look?
> - Is this meant as a simple string-based substitution? Is there any 
> filtering of allowed characters, or so?
> - What happens with the result values?
> - Is the entity that sets the macro values always the same that has set 
> the patterns the values are being used for, or could those be different 
> entities?
>
> Thanks!
>
>
> On Fri, Aug 25, 2023 at 9:34 PM 'Liam Brady' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Contact emails
>>
>> shiva...@chromium.org, d...@chromium.org, jka...@chromium.org, 
>> lbr...@google.com 
>> Explainer(s)
>>
>> Send Automatic Beacons Once
>>
>> https://github.com/WICG/turtledove/pull/718 
>>
>> Serializable Fenced Frames Configs - Minor Change, No explainer available.
>>
>> Note: With this change, FencedFrameConfig objects will be serializable 
>> and can be sent through "postMessage()" and other similar calls. 
>>
>> Creative Macros in Fenced Frames Ads Reporting (FFAR)
>>
>> https://github.com/WICG/turtledove/pull/763
>>
>> Spec(s)
>>
>> Send Automatic Beacons Once
>>
>> https://github.com/WICG/fenced-frame/pull/109 
>>
>> Serializable Fenced Frames Configs
>>
>> https://github.com/WICG/fenced-frame/pull/111 
>>
>> Creative Macros in Fenced Frames Ads Reporting (FFAR)
>>
>> Protected Audience: https://github.com/WICG/turtledove/pull/762/files 
>>
>> Fenced Frames: https://github.com/WICG/fenced-frame/pull/113
>>
>>  
>>
>> Summary
>>
>> We launched Fenced Frames as a part of Chrome 115. We would like to add 
>> the following three functionalities to Fenced Frames.
>>
>> 1. Send Automatic Beacons Once
>>
>> A common feature in ad frames is the "why this ad?" link. Since that link 
>> is separate from the ad itself, clicking "why this ad?", and its subsequent 
>> navigation, should be considered different from clicking directly on the 
>> advertisement itself. With our current automatic beacon design, however, 
>> once an automatic beacon is set (usually in the click handler for the ad 
>> link), that beacon will send out for any subsequent top-level navigations, 
>> including if "why this ad?" is clicked. This can result in erroneous 
>> impressions being sent out.
>>
>> As a solution, this feature introduces a new "once" member to the 
>> FenceEvent  
>> dictionary passed into 
>> "window.fence.setReportEventDataForAutomaticBeacons()". If set to true, the 
>> saved automatic beacon data will be cleared out after the next beacon is 
>> sent, ensuring that automatic beacons with that data are only sent once. 
>> This means that further clicks to non-ad parts of the frame that result in 
>> top-level navigations will not send out erroneous beacons.
>>
>> (This feature already shipped in M116. That was our mistake. At the time, 
>> we thought we would only need a PSA for it, and shipped it without it being 
>> behind a flag. We apologize for the mistake.)
>>
>> 2. Serializable FencedFramesConfigs
>>
>> With this change, FencedFrameConfig objects will be serializable and can 
>> be sent through "postMessage()" and other similar calls. Serialization 
>> allows for a case where the frame that runs an ad auction is not the same 
>> frame that ends up embedding the winning ad in a fenced frame. 
>> FencedFrameConfigs cannot be serialized to storage, nor can they be sent in 
>> a message that crosses a fenced frame boundary. A FencedFrameConfig object 
>> is only valid in the traversable navigable 
>>  it was 
>> originally crea

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Joey Arhar]

I filed a bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1476503

On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:

> Yeah, it was just a thought, maybe any new pseudo-class should
> automatically be added.
>
> ☆*PhistucK*
>
>
> On Sat, Aug 26, 2023 at 10:26 PM Mason Freed  wrote:
>
>>
>>
>> On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:
>>
>> I guess all of them would be good. Not really why only a few
>> pseudo-classes are listed there...
>>
>>
>> This sounds like a great feature request for devtools in general. I
>> wonder if we could separate it out from shipping this one set of 2 pseudo
>> classes though?
>>
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>>
>> Sure I can try setting up the force element state feature for it.
>>
>> > along with other form-related ones
>>
>> Any ones you have in mind? I could try to do them all at once
>>
>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>
>> Sounds good!
>>
>> > Debuggability
>>
>> > These new pseudo-classes will be supported by the DevTools styles
>> sidebar automatically, just like every other pseudo-class.
>>
>>
>> Can it (along with other form-related ones, I guess) be added to the list
>> of toggle-able pseudo classes (shown when you click on the ":hov" button)?
>> [image: image.png]
>>
>>
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>>
>> Contact emailsjar...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>>
>> Summary
>>
>> The :user-invalid and the :user-valid pseudo-classes represent an element
>> with incorrect or correct input, respectively, but only after the user has
>> significantly interacted with it. This is similar to :valid and :invalid,
>> but with the added constraint that these pseudo-classes only match after
>> the user has interacted with the element.
>>
>>
>> Blink componentBlink>CSS
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is no interop/compat risks because this is a new feature that has
>> already been implemented by safari and firefox and has WPTs.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This feature will not be used in tandem with other platform APIs. The
>> default usage of this API will not make it hard for chrome to maintain good
>> performance.
>>
>>
>> Activation
>>
>> It will not be challenging for developers to use this feature
>> immediately. There is already an MDN article for this feature, so I don't
>> think that we need additional outreach.
>>
>>
>> Security
>>
>> There are no security risks for this feature.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> These new pseudo-classes will be supported by the DevTools styles sidebar
>> automatically, just like every other pseudo-class.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsUserValidUserInvalid
>>
>> Finch feature nameUserValidUserInvalid
>>
>> Requires code in //chrome?False
>>
>> Availability expectationThis feature is already being shipped by safari
>> and firefox, so it will be available on the web platform mainline as soon
>> as we launch it.
>>
>> Adoption expectationThis feature will be considered the best practice
>> for its use case as soon as we launch it.
>>
>> Adoption planThis is already implemented in safari and firefox, so we
>> don't need to do anything in order to gain adoption of this feature.
>>
>> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>>
>> Estimated milestonesShipping on desktop118DevTrial on desktop118Shipping
>> on Android118DevTrial on Android118Shipping on WebView118
>>
>> 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).
>> There are no anticipated spec changes.
>>
>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>> feature/5132477781245952
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message b

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[PhistucK]

Thank you!

☆*PhistucK*


On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:

> I filed a bug here:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1476503
>
> On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:
>
>> Yeah, it was just a thought, maybe any new pseudo-class should
>> automatically be added.
>>
>> ☆*PhistucK*
>>
>>
>> On Sat, Aug 26, 2023 at 10:26 PM Mason Freed  wrote:
>>
>>>
>>>
>>> On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:
>>>
>>> I guess all of them would be good. Not really why only a few
>>> pseudo-classes are listed there...
>>>
>>>
>>> This sounds like a great feature request for devtools in general. I
>>> wonder if we could separate it out from shipping this one set of 2 pseudo
>>> classes though?
>>>
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:
>>>
>>> Sure I can try setting up the force element state feature for it.
>>>
>>> > along with other form-related ones
>>>
>>> Any ones you have in mind? I could try to do them all at once
>>>
>>> On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:
>>>
>>> Sounds good!
>>>
>>> > Debuggability
>>>
>>> > These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> Can it (along with other form-related ones, I guess) be added to the
>>> list of toggle-able pseudo classes (shown when you click on the ":hov"
>>> button)?
>>> [image: image.png]
>>>
>>>
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:
>>>
>>> Contact emailsjar...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos
>>>
>>> Summary
>>>
>>> The :user-invalid and the :user-valid pseudo-classes represent an
>>> element with incorrect or correct input, respectively, but only after the
>>> user has significantly interacted with it. This is similar to :valid and
>>> :invalid, but with the added constraint that these pseudo-classes only
>>> match after the user has interacted with the element.
>>>
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There is no interop/compat risks because this is a new feature that has
>>> already been implemented by safari and firefox and has WPTs.
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>>
>>> *WebKit*: Shipped/Shipping
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This feature will not be used in tandem with other platform APIs. The
>>> default usage of this API will not make it hard for chrome to maintain good
>>> performance.
>>>
>>>
>>> Activation
>>>
>>> It will not be challenging for developers to use this feature
>>> immediately. There is already an MDN article for this feature, so I don't
>>> think that we need additional outreach.
>>>
>>>
>>> Security
>>>
>>> There are no security risks for this feature.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> These new pseudo-classes will be supported by the DevTools styles
>>> sidebar automatically, just like every other pseudo-class.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flagsUserValidUserInvalid
>>>
>>> Finch feature nameUserValidUserInvalid
>>>
>>> Requires code in //chrome?False
>>>
>>> Availability expectationThis feature is already being shipped by safari
>>> and firefox, so it will be available on the web platform mainline as soon
>>> as we launch it.
>>>
>>> Adoption expectationThis feature will be considered the best practice
>>> for its use case as soon as we launch it.
>>>
>>> Adoption planThis is already implemented in safari and firefox, so we
>>> don't need to do anything in order to gain adoption of this feature.
>>>
>>> Sample linkshttps://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid
>>>
>>> Estimated milestonesShipping on desktop118DevTrial on desktop118Shipping
>>> on Android118DevTrial on Android118Shipping on WebView118
>>>
>>> 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).
>>> There are no anticipated s

Re: [blink-dev] Intent to Ship: Fenced Frames - Functionality Updates

['Garrett Tanzer' via blink-dev]

Hi Daniel,

   - There are a few relevant call sites in the overall reporting flow:
  - Declare allowlist of reporting destination origins
 - This happens in navigator.joinAdInterestGroup(), by an ad 
 auction buyer
  - Declare macros (key:value correspondences)
 - This happens in the buyer reporting worklet, by the same ad 
 auction buyer that declared the reporting destination origins
  - Perform report to custom url
 - This happens under the auction's winning ad creative's origin, 
 which isn't necessarily the same as the ad auction buyer, but it is 
chosen 
 by the ad auction buyer
  - Here is the sequence of events:


   1. 
  1. The browser ingests and validates the allowlist when the interest 
  group is declared.
  2. The browser ingests the macro key:value mapping when the auction 
  happens. The key/value strings have no structure that is validated. The 
  browser adds "${" and "}" around the user-provided keys in the macro 
  mapping. 
  3. In the ad that results from the auction:
 1. The ad sends a URL to the browser, including macros like 
 ${KEY}. The URL has to be a valid HTTPS url even with the macros 
 unsubstituted. (See 
 impl: 
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=8644?q=content%2Fbrowser%2Frenderer_host%2Frender_frame_host_impl.cc%20-f:out)
 2. The browser performs a simple string substitution to replace 
 the keys with the values. The implementation is reused from 
 navigator.deprecatedReplaceInURN, another part of Protected Audience. 
It 
 doesn't substitute macros recursively, so you can't get an infinite 
loop. 
 deprecatedReplaceInURN has apparently not been spec'd, which is was 
unable 
 to quickly reuse that spec and left it as a TODO for now.
 3. The origin of the resulting URL is checked against the 
 allowlist. If it doesn't match any of them, no action is performed. If 
the 
 URL is invalid, this will create an opaque origin and therefore always 
fail 
 the check. (See 
 impl: 
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/fenced_frame/fenced_frame_reporter.cc;l=454?q=fenced_frame_reporter.cc%20-f:out)
 
 We may add an explicit URL valid/HTTPS check after substitution for 
 neatness/to be robust to any future changes to the allowlist checking.
 4. If the URL does pass the check, a GET fetch will be performed 
 on it (the result is unused). There's no other parsing/usage of the 
URL 
 other than performing a fetch.
  
So in summary, we were not very concerned about XSS because the entity 
choosing the macro pairings is the one we want to protect, and the entity 
providing the base URLs is semi-trusted. The less trusted entity is the 
site of the destination URL, which just receives a GET and doesn't get to 
control anything. Since the URL has to be valid both before and after the 
macro substitution, this limits how wacky the substitutions can get even if 
you don't trust one of those entities. The weirdest stuff you could do 
would be like "FOO}&key=value1&${BAR" -> "key=value2", so that it becomes 
"${FOO}&key=value1&${BAR}" -> "key=value2". We can add a check to exclude 
$,{,} characters in the macro key so even this isn't possible.

Hope this answers your questions,
Garrett

On Monday, August 28, 2023 at 9:35:34 AM UTC-4 Daniel Vogelheim wrote:

> Hi Liam,
>
> This intent has come up in the OWP security triage, and I'm trying to 
> figure out whether there's XSS potential in the 3rd sub-feature, "Creative 
> macros in FFAR". This looks like a string-based pattern replacement where 
> the result string will then be parsed by the browser. Similar things have 
> lent themselves to XSS, e.g. when a string value contains meta characters 
> that code downstream will then parse in unexpected ways. Unfortunately, I 
> can't seem to find enough information about how exactly the replacement & 
> subsequent usage works to make up my mind whether there's a concern or not. 
> Could you help me out with a bit more information?
>
> What I've found is this:
> - In "send a beacon": "TODO: Substitute macros from |macro map| 
> into |destination url|." (source 
> )
> - In "asynchronously finish reporting" I find where macro map 
> being set, but then it says: "TODO: Pass |macroMap| and 
> |allowedReportingOrigins| to [=Finalize a reporting destination=] when it 
> is updated to take the parameters." (source 
> ) I can't find that 
> usage.
>
> Questions I have:
> - Am I reading the right docs? Where else should I look?
> - Is this meant as a simple string-based substitution? Is there any 
> filtering of allowed characters, or 

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Mike Taylor]

I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states 
that this and the :invalid/:valid flavors should apply to forms and 
fieldset elements. It doesn't look like the WPTs test for that - what do 
we do for those elements, and do you know if it's interoperable?


On 8/28/23 11:54 AM, PhistucK wrote:

Thank you!

☆*PhistucK*


On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:

I filed a bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1476503

On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:

Yeah, it was just a thought, maybe any new pseudo-class should
automatically be added.

☆*PhistucK*


On Sat, Aug 26, 2023 at 10:26 PM Mason Freed
 wrote:



On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK
wrote:

I guess all of them would be good. Not really why only
a few pseudo-classes are listed there...


This sounds like a great feature request for devtools in
general. I wonder if we could separate it out from
shipping this one set of 2 pseudo classes though?


☆*PhistucK*


On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar
 wrote:

Sure I can try setting up the force element state
feature for it.

> along with other form-related ones

Any ones you have in mind? I could try to do them
all at once

On Sat, Aug 26, 2023 at 10:00 AM PhistucK
 wrote:

Sounds good!

> Debuggability

> These new pseudo-classes will be supported by
the DevTools styles sidebar automatically,
just like every other pseudo-class.


Can it (along with other form-related ones, I
guess) be added to the list of toggle-able
pseudo classes (shown when you click on the
":hov" button)?

image.png



☆*PhistucK*


On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar
 wrote:

Contact emailsjar...@chromium.org

ExplainerNone


Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos


Summary

The :user-invalid and the :user-valid
pseudo-classes represent an element with
incorrect or correct input, respectively,
but only after the user has significantly
interacted with it. This is similar to
:valid and :invalid, but with the added
constraint that these pseudo-classes only
match after the user has interacted with
the element.



Blink componentBlink>CSS



TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is no interop/compat risks because
this is a new feature that has already
been implemented by safari and firefox and
has WPTs.



/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: No signals

/Other signals/:

Ergonomics

This feature will not be used in tandem
with other platform APIs. The default
usage of this API will not make it hard
for chrome to maintain good performance.



Activation

It will not be challenging for developers
to use this feature immediately. There is
already an MDN article for this feature,
so I don't think that we need additional
outreach.



Security

There are no security risks for this feature.



WebView application risks

Does this intent deprecate or change
  

Re: [blink-dev] Intent to Implement and Ship: SVGImageElement.crossOrigin attribute.

[Dale Curtis]

On Mon, Aug 21, 2023 at 9:41 AM Dale Curtis  wrote:

> On Sun, Aug 20, 2023 at 7:36 PM Yoav Weiss  wrote:
>
>> Thanks for working on this!! Eliminating resources which can't be loaded
>> as CORS enabled resources is super useful!
>>
>> On Fri, Aug 18, 2023 at 11:28 PM Dale Curtis 
>> wrote:
>>
>>> Contact emailsdalecur...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://www.w3.org/TR/SVG
>>>
>>> Summary
>>>
>>> Implements the crossOrigin attribute for SVG images: The crossOrigin
>>> attribute, valid on the  and  elements, provides support
>>> for configuration of the Cross-Origin Resource Sharing (CORS) requests for
>>> the element's fetched data. The supported values are the same as elsewhere:
>>> "anonymous", "use-credentials", and "" (which means anonymous).
>>> https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/crossorigin
>>> https://www.w3.org/TR/SVG/embedded.html#ImageElementCrossoriginAttribute
>>>
>>>
>>> Blink componentBlink>SVG
>>> 
>>>
>>> Search tagssvg , crossorigin
>>> , image
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>
>> I believe content that already has a crossorigin attribute, but where the
>> servers didn't send ACAO would now be blocked.
>> Can we add a usecounter for that case, and monitor it as part of the
>> rollout?
>>
>
>>
>>>
>>> *Gecko*: Shipped/Shipping (
>>> https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/crossorigin#browser_compatibility
>>> )
>>>
>>
>> According to MDN, that's a fairly recent change. Do you know if it ran
>> into any compat issues?
>>
>
> I don't. Nothing is called out on the implementation issue:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240357
>
> +longs...@gmail.com who authored the Firefox change in case they want to
> weigh in.
>

Robert indicated privately that Firefox hasn't seen any issues with roll
out thus far.


>
>
>>
>>
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/241)
>>>
>>
WebKit indicates they're likely to mark this as supported shortly:
https://github.com/WebKit/standards-positions/issues/241#issuecomment-1693613454


>
>>> *Web developers*: Positive
>>>
>>> *Other signals*:
>>>
>>> Security
>>>
>>> The default value of the crossOrigin attribute is "anonymous", both
>>> Safari and Chrome currently treat the missing attribute as "no cors". Due
>>> to the default value change, content that was previously inaccessible
>>> and/or tainted will become accessible without site/developer involvement if
>>> the server was already supplying the correct Access-Control-Allow-Origin
>>> header.
>>>
>>
> fs pointed out that this is confusingly worded. I've rephrased it as:
> "Content that was previously inaccessible and/or tainted will become
> accessible without site/developer involvement if the client side element
> has a crossOrigin attribute and the server was already supplying the
> correct Access-Control-Allow-Origin header."
>
>
>>
>>>
>>> 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, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>
>> Link to wpt.fyi that shows Firefox passing the tests currently?
>>
>
> Hmm, I linked to them on the chromestatus entry, I guess it doesn't
> include them here:
>
> https://wpt.fyi/results/svg/embedded/image-crossorigin.sub.html?label=master&label=experimental&aligned
> https://wpt.fyi/results/webcodecs/videoFrame-construction.crossOriginSource.sub.html?label=master&label=experimental&aligned
>
>
>>
>>
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameSvgCrossOriginAttribute
>>>
>>> Non-finch justification
>>>
>>> Minor attribute addition.
>>>
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=842321
>>>
>>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=842321
>>>
>>> Estimated milestones
>>> Shipping on desktop 118
>>> Shipping on Android 118
>>>
>>> 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
>>>

Re: [blink-dev] Intent to Ship: :user-valid and :user-invalid CSS pseudo-classes

[Joey Arhar]

> I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states
that this and the :invalid/:valid flavors should apply to forms and
fieldset elements. It doesn't look like the WPTs test for that - what do we
do for those elements, and do you know if it's interoperable?

We don't have WPTs at the moment. Based on my testing, it looks like
firefox chrome and safari all don't apply :user-valid or :user-invalid to
form elements. I opened a spec issue to discuss:
https://github.com/w3c/csswg-drafts/issues/9257

On Mon, Aug 28, 2023 at 9:01 AM Mike Taylor  wrote:

> I see that https://drafts.csswg.org/selectors-4/#issue-df919919 states
> that this and the :invalid/:valid flavors should apply to forms and
> fieldset elements. It doesn't look like the WPTs test for that - what do we
> do for those elements, and do you know if it's interoperable?
> On 8/28/23 11:54 AM, PhistucK wrote:
>
> Thank you!
>
> ☆*PhistucK*
>
>
> On Mon, Aug 28, 2023 at 4:46 PM Joey Arhar  wrote:
>
>> I filed a bug here:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1476503
>>
>> On Sat, Aug 26, 2023 at 4:04 PM PhistucK  wrote:
>>
>>> Yeah, it was just a thought, maybe any new pseudo-class should
>>> automatically be added.
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Sat, Aug 26, 2023 at 10:26 PM Mason Freed 
>>> wrote:
>>>


 On Saturday, August 26, 2023 at 10:31:30 AM UTC-7 PhistucK wrote:

 I guess all of them would be good. Not really why only a few
 pseudo-classes are listed there...


 This sounds like a great feature request for devtools in general. I
 wonder if we could separate it out from shipping this one set of 2 pseudo
 classes though?




 ☆*PhistucK*


 On Sat, Aug 26, 2023 at 6:18 PM Joey Arhar  wrote:

 Sure I can try setting up the force element state feature for it.

 > along with other form-related ones

 Any ones you have in mind? I could try to do them all at once

 On Sat, Aug 26, 2023 at 10:00 AM PhistucK  wrote:

 Sounds good!

 > Debuggability

 > These new pseudo-classes will be supported by the DevTools styles
 sidebar automatically, just like every other pseudo-class.


 Can it (along with other form-related ones, I guess) be added to the
 list of toggle-able pseudo classes (shown when you click on the ":hov"
 button)?
 [image: image.png]



 ☆*PhistucK*


 On Sat, Aug 26, 2023 at 9:14 AM Joey Arhar  wrote:

 Contact emailsjar...@chromium.org

 ExplainerNone

 Specificationhttps://drafts.csswg.org/selectors-4/#user-pseudos

 Summary

 The :user-invalid and the :user-valid pseudo-classes represent an
 element with incorrect or correct input, respectively, but only after the
 user has significantly interacted with it. This is similar to :valid and
 :invalid, but with the added constraint that these pseudo-classes only
 match after the user has interacted with the element.


 Blink componentBlink>CSS
 

 TAG reviewNone

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 There is no interop/compat risks because this is a new feature that has
 already been implemented by safari and firefox and has WPTs.


 *Gecko*: Shipped/Shipping

 *WebKit*: Shipped/Shipping

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 This feature will not be used in tandem with other platform APIs. The
 default usage of this API will not make it hard for chrome to maintain good
 performance.


 Activation

 It will not be challenging for developers to use this feature
 immediately. There is already an MDN article for this feature, so I don't
 think that we need additional outreach.


 Security

 There are no security risks for this feature.


 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such
 that it has potentially high risk for Android WebView-based applications?

 None


 Debuggability

 These new pseudo-classes will be supported by the DevTools styles
 sidebar automatically, just like every other pseudo-class.


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

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

 Flag name on chrome://flagsUserValidUserInvalid

 Finch feature nameUserValidUserInvalid

 Requires code in //chrome?False

 Availability expectationThis

Re: [blink-dev] Re: Intent to Ship: Bounce Tracking Mitigations

[Mike Taylor]

LGTM1 to ship, as long as we fast follow with doing the work to define 
and ship webdriver extensions in order to make this testable in WPT.


(I don't think your team should be blocked on shipping because other 
browsers who already shipped the feature didn't do that work.)


On 8/21/23 3:44 PM, Christian Biesinger wrote:

On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly  wrote:



On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor  wrote:

On 8/21/23 11:09 AM, Ben Kelly wrote:

On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss  wrote:

Thanks for working on this important problem!

On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly  wrote:

Sorry, it seems I left off the signals section of the template:

Firefox: No signal (https://github.com/mozilla/standards-positions/issues/835)


Firefox folks seem tentatively supportive, but have WPT questions. Can you 
address them?


I'm checking without our WPT folks to try to understand what mozilla is 
suggesting.  I'm not familiar with web-driver functions at all, so not quite 
sure yet how feasible this is.

My read on bvandersloot's comment is that he's asking for a less generic 
version https://github.com/web-platform-tests/wpt/issues/17489 to make this 
testable (which you've already linked below). Exposing endpoints for advancing 
time seems to have more use cases than bounce tracking-specific webdriver 
endpoints, IMHO - but that's a discussion that should probably happen in the 
relevant WG.

See https://github.com/web-platform-tests/rfcs for the process to propose 
extending the testdriver.js API to expose... but I think you'll want to get the 
relevant concepts added to the webdriver spec first (seems possible, if Mozilla 
if supportive). The other option would be to something similar to FedCM by 
adding webdriver extension commands (see spec PR here: 
https://github.com/fedidcg/FedCM/pull/465/files).

I personally wouldn't recommend blocking on this work, but it seems useful for 
someone to pursue as good first bugs for folks interested in standards and WPT 
internals. Note that additions to WebDriver now require going through the 
Intent process (great news for folks interested in learning this process, 
presumably they exist!).


Andrew Williams also helpfully pointed out a bunch of code source references to 
me for this.  I filed crbug.com/1474656 to do this work.

I think this is definitely something we will do, but it may take a milestone or 
two to get it done.  In particular, I'm unsure if there will be pushback to 
modifying the web-driver functions for a bounce tracking mitigations-specific 
feature.

Lots of specs define webdriver extensions, that should not be a problem. E.g.:
https://fedidcg.github.io/FedCM/#automation
https://w3c.github.io/secure-payment-confirmation/#sctn-automation
https://w3c.github.io/webauthn/#sctn-automation-virtual-authenticators

Note that you have to implement the commands twice, once for Chrome's
bots and once for upstream wpt.fyi and general UA automation uses.
Chrome's impl does not really use webdriver, it usually just calls a
function on internals (e.g.
https://chromium-review.googlesource.com/c/chromium/src/+/4740672/6/third_party/blink/web_tests/resources/testdriver-vendor.js)

The second impl is in Chromedriver, likely using CDP, e.g.:
https://chromium-review.googlesource.com/c/chromium/src/+/4281897
plus
https://chromium-review.googlesource.com/c/chromium/src/+/4402971

Christian


I don't think we want to take on the general purpose clock modification change 
to web-driver, though.  That seems like a much larger scope.






Webkit: No signal (https://github.com/WebKit/standards-positions/issues/214)
Web developers: No signals

On Thu, Aug 17, 2023 at 10:22 AM Ben Kelly  wrote:

Contact emails

wanderv...@chromium.org, b...@chromium.org, rtarp...@chromium.org, 
j...@chromium.org


Explainer

https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md


Specification

https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations


Summary

This feature mitigates bounce tracking on the web.  It works by deleting state 
from sites that access storage during a redirect that the user has never 
directly interacted with.  See the specification for more details.


Blink component

Privacy>NavTracking


TAG review

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


TAG review status

Issues addressed


Risks


Interoperability and Compatibility

The main risk is that we will incorrectly delete state for a site that the user 
needs to continue functioning.  Our approach attempts to address this with a 
number of signals:


If a user has interacted with the site within the last 45 days, we will not 
delete its state.

We are adding successful webauthn key assertions as another "interaction" 
source in M117 to address SSO use cases that only require security taps to stay logged in.

We only delete state if the potential tracking site is not permitted as a 3P 
cookie.  This allows users

[blink-dev] Re: Question about owner set of WorkerGlobalScope

[Wei4 Wang]

Does any one can help this? Thanks.

On Wednesday, August 23, 2023 at 11:01:33 PM UTC+8 Wei4 Wang wrote:

> Hi, All.
>
>  
>
> The HTML spec said: A WorkerGlobalScope object has an associated owner set 
> (a set of Document and WorkerGlobalScope Objects), but I don’t find this in 
> chromium codes. Is there any way to find the owner of the WorkerGlobalScope 
> in chromium?
>
>  
>
>  
>
> Cheers,
>
> Wei.
>

-- 
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/600fa725-68b0-404f-8df4-be2965d6fb46n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Bounce Tracking Mitigations

[Yoav Weiss]

I agree that WPT infrastructure shouldn't be a blocker when we're following
other browsers.

Have y'all tested the mitigation with commonly used authentication/payment
flows, to make sure it doesn't break them?

On Mon, Aug 28, 2023 at 11:08 PM Mike Taylor  wrote:

> LGTM1 to ship, as long as we fast follow with doing the work to define
> and ship webdriver extensions in order to make this testable in WPT.
>
> (I don't think your team should be blocked on shipping because other
> browsers who already shipped the feature didn't do that work.)
>
> On 8/21/23 3:44 PM, Christian Biesinger wrote:
> > On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly 
> wrote:
> >>
> >>
> >> On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor 
> wrote:
> >>> On 8/21/23 11:09 AM, Ben Kelly wrote:
> >>>
> >>> On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss 
> wrote:
>  Thanks for working on this important problem!
> 
>  On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly 
> wrote:
> > Sorry, it seems I left off the signals section of the template:
> >
> > Firefox: No signal (
> https://github.com/mozilla/standards-positions/issues/835)
> 
>  Firefox folks seem tentatively supportive, but have WPT questions.
> Can you address them?
> >>>
> >>> I'm checking without our WPT folks to try to understand what mozilla
> is suggesting.  I'm not familiar with web-driver functions at all, so not
> quite sure yet how feasible this is.
> >>>
> >>> My read on bvandersloot's comment is that he's asking for a less
> generic version https://github.com/web-platform-tests/wpt/issues/17489 to
> make this testable (which you've already linked below). Exposing endpoints
> for advancing time seems to have more use cases than bounce
> tracking-specific webdriver endpoints, IMHO - but that's a discussion that
> should probably happen in the relevant WG.
> >>>
> >>> See https://github.com/web-platform-tests/rfcs for the process to
> propose extending the testdriver.js API to expose... but I think you'll
> want to get the relevant concepts added to the webdriver spec first (seems
> possible, if Mozilla if supportive). The other option would be to something
> similar to FedCM by adding webdriver extension commands (see spec PR here:
> https://github.com/fedidcg/FedCM/pull/465/files).
> >>>
> >>> I personally wouldn't recommend blocking on this work, but it seems
> useful for someone to pursue as good first bugs for folks interested in
> standards and WPT internals. Note that additions to WebDriver now require
> going through the Intent process (great news for folks interested in
> learning this process, presumably they exist!).
> >>
> >> Andrew Williams also helpfully pointed out a bunch of code source
> references to me for this.  I filed crbug.com/1474656 to do this work.
> >>
> >> I think this is definitely something we will do, but it may take a
> milestone or two to get it done.  In particular, I'm unsure if there will
> be pushback to modifying the web-driver functions for a bounce tracking
> mitigations-specific feature.
> > Lots of specs define webdriver extensions, that should not be a problem.
> E.g.:
> > https://fedidcg.github.io/FedCM/#automation
> > https://w3c.github.io/secure-payment-confirmation/#sctn-automation
> > https://w3c.github.io/webauthn/#sctn-automation-virtual-authenticators
> >
> > Note that you have to implement the commands twice, once for Chrome's
> > bots and once for upstream wpt.fyi and general UA automation uses.
> > Chrome's impl does not really use webdriver, it usually just calls a
> > function on internals (e.g.
> >
> https://chromium-review.googlesource.com/c/chromium/src/+/4740672/6/third_party/blink/web_tests/resources/testdriver-vendor.js
> )
> >
> > The second impl is in Chromedriver, likely using CDP, e.g.:
> > https://chromium-review.googlesource.com/c/chromium/src/+/4281897
> > plus
> > https://chromium-review.googlesource.com/c/chromium/src/+/4402971
> >
> > Christian
> >
> >> I don't think we want to take on the general purpose clock modification
> change to web-driver, though.  That seems like a much larger scope.
> >>
> >>>
> 
> > Webkit: No signal (
> https://github.com/WebKit/standards-positions/issues/214)
> > Web developers: No signals
> >
> > On Thu, Aug 17, 2023 at 10:22 AM Ben Kelly 
> wrote:
> >> Contact emails
> >>
> >> wanderv...@chromium.org, b...@chromium.org, rtarp...@chromium.org,
> j...@chromium.org
> >>
> >>
> >> Explainer
> >>
> >>
> https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md
> >>
> >>
> >> Specification
> >>
> >>
> https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations
> >>
> >>
> >> Summary
> >>
> >> This feature mitigates bounce tracking on the web.  It works by
> deleting state from sites that access storage during a redirect that the
> user has never directly interacted with.  See the specification for more
> details.