Re: [blink-dev] Intent to Prototype: overflow:overlay aliases overflow:auto

[Yoav Weiss]

On Fri, Mar 31, 2023 at 2:37 AM Chris Harrelson 
wrote:

> Contact emailschris...@chromium.org
>
> Specificationhttps://drafts.csswg.org/css-overflow-3/#valdef-overflow-auto
>
> Summary
>
> Removes the overflow:overlay scrolling mode, and makes overlay a legacy
> alias of auto. overflow:overlay is the same as overflow:auto, except that
> it does not prevent content from extending into the scrollbar gutter, in
> cases where non-overlay OS scrollbars are present. (If overlay scrollbars
> are present, there is no effect.) Example: With overflow:overlay:
> https://output.jsbin.com/yujenuq/quiet With overflow:auto:
> https://output.jsbin.com/ruzogaf/quiet
>

Which platforms would one see a difference between these two? (I'm not
seeing a difference on MacOS)


>
>
> Blink componentBlink>Scroll
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Developers currently relying on content overlapping the scrollbar gutter
> would instead see some additional line wrapping. Users, on the other hand,
> would be able to see more content that is currently invisible underneath a
> scrollbar.
>

I'm assuming that content would avoid overlapping with the gutter before
scrolling ever starts, right? (rather than triggering layout shifts once
the user scrolls)


> On platform configurations with overlay scrollbars in the OS, this change
> has no effect; it only applies to situations where a non-overlay scrollbar
> is configured by the browser. Use counter:
> https://chromestatus.com/metrics/feature/timeline/popularity/2995
> Adoption is more than 2% of page loads.
>
>
> *Gecko*: Shipped/Shipping (
> https://github.com/mozilla/standards-positions/issues/768)
>
> *WebKit*: Shipped/Shipping (
> https://github.com/WebKit/standards-positions/issues/157)
>
> *Web developers*: No signals
>
>
> Debuggability
>
> Sites might not know why their line wrapping changed to exclude the
> scrollbar gutter. However, this is the existing behavior in Firefox and
> Safari, so they would get interop by default.
>
> 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 nameOverflowOverlayAliasesAuto
>
> Requires code in //chrome?No
>
> Estimated milestones
> Shipping on desktop 114
> DevTrial on desktop 114
> Shipping on Android 114
> DevTrial on Android 114
> Shipping on WebView 114
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5194091479957504
>
> 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/CAOMQ%2Bw-F4mOhUMuU3nw423C8CurZKX_wxQvXRPv-XT4Zhsm-XQ%40mail.gmail.com
> 
> .
>

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

Re: [blink-dev] Intent to Ship: Scrollend Event

[Yoav Weiss]

On Fri, Mar 31, 2023 at 3:50 PM David Awogbemila 
wrote:

> Contact emails
> arg...@google.com, awogbem...@google.com
>
> Explainer
> https://github.com/argyleink/scrollend-explainer/blob/main/README.md
>

The explainer says this shipped in 114. I guess it should say y'all are
expecting to ship at that point :)


>
> Specificationhttps://drafts.csswg.org/cssom-view/#scrolling-events
>
> Summary
>
> Scrollend events help developers reliably tell when a scroll has completed
> (including both the scroll itself and any updates to offsets from the
> scroll). Knowing when a scroll has completed is useful for various reasons,
> e.g. synchronizing some logic on the snapped section, fetching stuff in a
> list, triggering new animations, etc. This feature greatly simplifies the
> logic for handling end-of-scroll effects, ensuring that they are consistent
> across many different input modalities. Currently, developers address this
> need by observing scroll events and building ad-hoc timeout algorithms.
>
>
> Blink componentBlink>Scroll
> 
>
> Search tagsscroll 
>
> TAG review
>
> TAG review statusNot applicable
>

Agree this is not needed, as this is following WG agreed-upon behavior,
that has already shipped in one implementation.


>
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1797013)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/150) There hasn't
> been an explicit position attached to the position request yet but there is
> a tracking WebKit issue: https://bugs.webkit.org/show_bug.cgi?id=201556
>
> *Web developers*: Positive (
> https://twitter.com/nghuuphuoc/status/1618806085158051846?s=20) Other
> examples: https://twitter.com/radogado/status/1621479592123826184?s=20
> https://twitter.com/ebidel/status/1621037204297637891?lang=en
>
> *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?
>
> Not potentially high risk.
>
>
> Debuggability
>
> We verified via Protocol Monitor that DevTools supports breaking on
> scrollend listeners, similar to other events. DevTools UI change is needed
> to make this accessible which will be done via crrev.com/c/4376080.
>
>
> 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
>

https://wpt.fyi/results/dom/events/scrolling?label=master&label=experimental&aligned
paints an odd picture, where our current experimental implementation passes
some of the tests, but not others, and Firefox seems to be failing some of
them.
Can you elaborate on the end state you're expecting once this ships?


>
>
> Flag nameN/A base::Feature is autogenerated from
> runtime_enabled_features.json5
> 
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=907601
>
> Estimated milestones
> M114
>
> 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).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5186382643855360
>
> 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/CAA6pwF7nGNT0bwM8VY3Jj0TAEe9jNptKuwrMN1%3DO8tnqH2t8JQ%40mail.gmail.com
> 
> .
>

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

Re: [blink-dev] Intent to Ship: CSS :lang pseudo class level 4

[Yoav Weiss]

LGTM1 once this is WPT tested with good coverage and our shipped behavior
matches both WebKit and the spec. Please get back to this thread if e.g.
the implemented WebKit behavior varies from the specified one.

On Thu, Mar 30, 2023 at 9:09 AM Roger Zanoni  wrote:

> Hi Philip,  thanks for looking for the tests, they are relevant but they
> don't cover some cases, like implicit wildcard matching with more than one
> language subtags, private singleton matching
>
> I think we should add more cases to wpt tests targeting specific level4
> matching logic, like the cases that are tested on
> https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering.html
> and
> https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering-with-string-arguments.html
>
> About the standards-positions issue, I filed it on
> https://github.com/mozilla/standards-positions/issues/735
>
> On Wednesday, March 29, 2023 at 6:00:19 PM UTC+2 Philip Jägenstedt wrote:
>
> Hi Roger,
>
> I took a look for the tests, and am wondering if the tests added here are
> for Level 4?
> https://github.com/web-platform-tests/wpt/pull/37950
>
> At least some of them are already passing in Chrome Dev (with experimental
> features enabled), but not Chrome stable, so some of these tests seem
> relevant. Overall, is the test coverage for this feature in WPT
> satisfactory?
>
> As Yoav said, a standards-positions issue for Gecko would be great, mostly
> as a heads up that we're shipping this and it's already shipping in Safari.
>
> Best regards,
> Philip
>
> On Fri, Mar 17, 2023 at 10:59 AM Yoav Weiss  wrote:
>
>
>
> On Thu, Mar 16, 2023 at 11:09 AM Roger Zanoni  wrote:
>
> Contact emails rza...@igalia.com
>
> Explainer https://github.com/rogerzanoni/docs/tree/main/lang-level-4
>
> Specification https://www.w3.org/TR/selectors-4/#the-lang-pseudo
>
> Summary
>
> The :lang CSS pseudo-class currently matches elements based on level 3
> specs logic, which describes a prefix-matching rule to match language
> values. The level 4 spec changes this matching logic, supporting
> argument-list and language range matching (according to the specs of the
> extended filtering operation from RFC4647 - Matching of language tags -
> section 3.3.2, and the simple priority list matching described on section
> 2.3)
>
>
> Blink component Blink>CSS
> 
>
> Search tags css , lang
> , pseudo
> 
>
> TAG review Just extends functionality of the existing :lang selector.
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This change mostly extends :lang functionality and don't change existing
> behavior, except for adding implicit wildcard matching, which breaks one of
> the existing level 3 tests:
> https://wpt.fyi/results/css/selectors/i18n/css3-selectors-lang-005.html
>
>
> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1121792)
>
>
> Can you file for a Mozilla position? https://bit.ly/blink-signals
>
>
>
> *WebKit*: Shipped/Shipping (
> https://webkit.org/status/#feature-css-selector-:lang)
>
> *Web developers*: No signals
>
> *Other signals*: CSSWG consensus to ship documented in
> https://www.w3.org/TR/css-2017/#experimental (CSSWG includes reps from
> all major browser vendors)
>
> 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.
>
>
> Debuggability
>
> Automatically supported, same as other pseudo-elements.
>
>
> 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
>
>
> Why not? How do we know that WebKit actually supports this if it's not
> tested?
>
>
>
>
> Flag name
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1281157
>
> Estimated milestones
>
> No milestones specified
>
>
> 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).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5071058079055872
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dd1cdecb-3bd5-cf6c-bf5c-120735d36ee6%40igalia.com
>
>
> This intent mes

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Yoav Weiss]

Thanks for working on this!!
Aligning with Safari and Firefox on this means that this is important not
just for user privacy, but also from an interop perspective. It also gives
us some confidence that this deprecation can be successful.

This is effectively a deprecation, but one where I can't think of a
reasonable way to measure usage, so it seems to me that a careful rollout +
deprecation trial (as you're suggesting) is the way to go here.

Is the deprecation trial enabled as a 3P OT? That may ease the deployment
for platform providers that have a hard time shipping header changes to a
large set of origins.
Also, have we reached out to the usual suspects to make sure they test this
change ahead of time?



On Wed, Apr 5, 2023 at 12:44 AM Mike Taylor  wrote:

> *Contact emails*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * wanderv...@chromium.org , m...@chromium.org
> , mikety...@chromium.org 
> Explainer
> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
> 
> Specification Partitioned Storage is roughly specified at
> https://privacycg.github.io/storage-partitioning/
> . As part of this work,
> we have started to codify the necessary concepts in HTML, DOM, and Storage
> in the following PRs: https://github.com/whatwg/storage/pull/144
> 
> https://github.com/whatwg/dom/pull/1142
> 
> https://github.com/whatwg/html/pull/8447
>   We have also updated other APIs
> to use StorageKey (ServiceWorker [1
> ],
> BroadcastChannel [1 ],
> SharedWorker[1 ]), and landed
> necessary additions to Storage itself ([1
> ][2
> ]).
> What we thought to be a straightforward set of changes has evolved to be a
> more complex refactoring, per the request of HTML editors. We propose to
> ship with a WIP spec spread out across the PRs above (noting that Firefox
> and Safari have already shipped partitioned storage). That said, we intend
> to finish this work. Summary We intend to partition a number of APIs in
> third-party contexts. This effort is focused on partitioning APIs above the
> network stack. This includes quota-managed storage, service workers, and
> communication APIs (like BroadcastChannel). See the explainer for more
> details:
> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
> 
> Blink component Blink>Storage TAG review
> https://github.com/w3ctag/design-reviews/issues/629
>   TAG review status
> Resolution: Satisfied Risks Interoperability and Compatibility Given that
> Firefox and Safari have already shipped this feature, we expect our
> implementation to be interoperable. We are aware of breakage
> 
> for sites that use Firebase for authentication (because it relies on being
> able to access unpartitioned sessionStorage). Firebase has blogged on how
> sites can mitigate this issue
> . We
> built a deprecation trial specifically for the sessionStorage redirect use
> case, which should work for Firebase users. In addition, we have a general
> deprecation trial available and enterprise policies in place. See below for
> more info on the deprecation trials. We’ve made storage partitioning
> available for local testing in Chrome for the past 6 months
> .
> Apart from Firebase, we’re not aware of any existing compatibility issues
> that can’t be solved by the deprecation trials
> .
> There may be unforeseen contexts and use cases that rely on unpartitioned
> storage and as such, we propose to roll this feature out carefully via
> Finch, according to the following proposed schedule: May 9th: 1% of Stable
> population (approximately 1 week after M113 is released) May 23rd: 10% June
> 6th: 50% June 20th: 100% As usual, if we identify concerning metrics,
> regressions, or site breakage reports, we may pause or roll back to
> investigate or address issues. Deprecation trial instructions:
> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/
> 

Re: [blink-dev] PSA: Risky changes should be guarded by a Runtime Enabled Feature

[Charles Harrison]

For me, I really just needed the link to this guidance which you posted:
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#what-type-of-flag-rollout-to-use

This positions the "default" rollout to be enabled-by-default with a
killswitch, rather than a finch-enabled rollout. This matches what you have
above, where we want deprecations to go through that flow of in-development
-> under test -> experimental -> stable (with killswitch) -> mature (no
flags). I also think this is the right guidance, as asking risky features
to go through a finch-enabled rollout is a large overhead (and requires
Chrome internal changes).

For removals, I agree that this implies that we should remove their Runtime
Enabled Feature and replace it with a Runtime Enabled Feature that removes
the feature, which we can then killswitch with status=stable.

On Tue, Apr 4, 2023 at 3:52 PM Rick Byers  wrote:

> Oh that's interesting. It's possible there are cases where
> disabled-by-default is the better choice. What do you see as the main trade
> offs? Obviously it's important that we're testing the default configuration
> - so either way, we shouldn't be relying on finch to change behavior except
> in the emergency situation (or intentional A/B tests of course).
>
> I was mainly thinking that for Runtime Enabled Features, we have the
> status mechanism that biases towards status=stable. I suppose breaking
> changes are more ambiguous. Eg. if we're removing an API that still has a
> Runtime Enabled Feature, then setting it back to no status to unship it
> could be a reasonable option. But I'd worry about the risk of confusion
> there. Eg. if someone sets it to status=test or status=experimental after
> it's gone to Chrome Stable with status=stable, there's risk of breaking
> changes showing up in official builds but not in a lot of chromium
> developer configurations that have
> --enable-experimental-web-platform-features set. I don't think that usage
> is a good fit for how Runtime Enabled Features are designed and
> communicated.
>
> To me behavior changes of any type go through a flow of in-development ->
> under test -> experimental -> stable (with killswitch) -> mature (no
> flags). Once we hit the 'stable' feature in stable release for some period
> of time, I don't think there's really any going back - only the possibility
> of a new breaking change following this path. I guess this mirrors our
> launch process as well. You don't need an I2D&R to flip the killswitch on a
> new API in the first week of being on stable. But before long (maybe a
> couple weeks?) you cross some threshold where any change or disabling is to
> a launched feature and needs an I2D&R, and so logically a new Runtime
> Enabled Feature working up to being on-by-default. Perhaps we should be
> more thoughtful and explicit about this flow?
>
> Rick
>
> On Tue, Apr 4, 2023 at 2:24 PM Charles Harrison 
> wrote:
>
>> Thanks Rick this is really helpful. I have been involved in a few changes
>> where API OWNERS said "flag-gated" and the implementer chose to use a
>> disabled-by-default flag which I didn't push back on. I think just I needed
>> this recalibration :)
>>
>> On Tue, Apr 4, 2023 at 1:16 PM Rick Byers  wrote:
>>
>>> Thanks Charlie. Yes I should have been specific, I'm really talking
>>> about enabled-by-default flags here (eg. Runtime Enabled Feature with
>>> status=stable).
>>>
>>> Note that our process for flipping a kill switch via finch includes
>>> first landing a CL that disables the flag (confirming it doesn't break any
>>> tests etc.). We're still learning how best to communicate these rare
>>> situations, but that'll be an ongoing process. In general I've certainly
>>> found it helpful when folks update their I2S threads with rollout status
>>> whenever it deviates from the original plan.
>>>
>>> Rick
>>>
>>> On Wed, Mar 29, 2023 at 3:49 PM Charles Harrison <
>>> csharri...@chromium.org> wrote:
>>>
 Thanks for posting this Rick. One call-out that I think is worth
 mentioning is the distinction between enabled-by-default flags and
 disabled-by-default flags. The general guidelines for choosing between
 these is in the links you posted, but given that it can be sometimes a
 subjective call it might be worth clarifying in e.g. API owners feedback on
 a particular I2S. I often see requests to flag guard a feature but
 sometimes it's ambiguous in which direction.

 On Wed, Mar 29, 2023 at 1:53 PM Rick Byers  wrote:

> Hey blink-dev,
>
> Within Google we’ve had a lot of discussion over the past year about
> how we should make increasing use of flags and kill switches
> 
> to reduce the risk of breaking changes, but I realized there hasn’t been
> discussion here on blink-dev.
>
> Once a change hits stable it’s quite expensive and time-consuming to
> do a

[blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

**

*Contact emails*

*

wanderv...@chromium.org, m...@chromium.org, mikety...@chromium.org


Explainer

https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md 




Specification

Partitioned Storage is roughly specified at 
https://privacycg.github.io/storage-partitioning/ 
. As part of this 
work, we have started to codify the necessary concepts in HTML, DOM, and 
Storage in the following PRs:



https://github.com/whatwg/storage/pull/144 



https://github.com/whatwg/dom/pull/1142 



https://github.com/whatwg/html/pull/8447 




We have also updated other APIs to use StorageKey (ServiceWorker [1 
], 
BroadcastChannel [1 ], 
SharedWorker[1 ]), and landed 
necessary additions to Storage itself ([1 
][2 
]).



What we thought to be a straightforward set of changes has evolved to be 
a more complex refactoring, per the request of HTML editors. We propose 
to ship with a WIP spec spread out across the PRs above (noting that 
Firefox and Safari have already shipped partitioned storage). That said, 
we intend to finish this work.



Summary

We intend to partition a number of APIs in third-party contexts. This 
effort is focused on partitioning APIs above the network stack. This 
includes quota-managed storage, service workers, and communication APIs 
(like BroadcastChannel). See the explainer for more details:



https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md 





Blink component

Blink>Storage


TAG review

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




TAG review status

Resolution: Satisfied


Risks


Interoperability and Compatibility


Given that Firefox and Safari have already shipped this feature, we 
expect our implementation to be interoperable. We are aware of breakage 
for 
sites that use Firebase for authentication (because it relies on being 
able to access unpartitioned sessionStorage). Firebase has blogged on 
how sites can mitigate this issue 
. We 
built a deprecation trial specifically for the sessionStorage redirect 
use case, which should work for Firebase users. In addition, we have a 
general deprecation trial available and enterprise policies in place. 
See below for more info on the deprecation trials.



We’ve made storage partitioning available for local testing in Chrome 
for the past 6 months 
. 
Apart from Firebase, we’re not aware of any existing compatibility 
issues that can’t be solved by the deprecation trials 
. 
There may be unforeseen contexts and use cases that rely on 
unpartitioned storage and as such, we propose to roll this feature out 
carefully via Finch, according to the following proposed schedule:



May 9th: 1% of Stable population (approximately 1 week after M113 is 
released)


May 23rd: 10%

June 6th: 50%

June 20th: 100%


As usual, if we identify concerning metrics, regressions, or site 
breakage reports, we may pause or roll back to investigate or address 
issues.



Deprecation trial instructions: 
https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/ 




Gecko: Shipped/Shipping


WebKit: Shipped/Shipping


Web developers: Mixed signals. Some developers have expressed 
compatibility concerns, others have been supportive.



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?



No, we don’t intend to turn this on for WebView yet.


Debuggability

DevTools has support for partitioned storage.


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


No (not WebView)


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

Yes. We’ve written WPTs to verify our 3rd party storage partitioning.


Flag name

ThirdPartyStoragePartitioning


Requires code in //chrome?

Nope


Tracking bug

https:/

Re: [blink-dev] Intent to Prototype: Document Subtitle (Fix PWA app titles)

['Diego Gonzalez' via blink-dev]

Hola,

My main goal here is to have a bucket of information that is separate from 
the  to specify contextual app info in the title bar... and a way of 
(efficiently and) dynamically changing this with JS. 

@Daniel, I will add the missing topics that you mention to the explainer, 
as ALL of them are relevant to the solution. We do not want to lessen 
security by removing " -" by any means. And it is true that the UX 
for a title bar is different from that of a tab. 

The name can change, I don't think that'd be an issue, it's an opportunity 
to better represent what this does. "application-title-custom" sounds good 
imho.

There's some discussion on the Webkit side about the potential use of 
schema.org or OpenGraph instead, I am not entirely sure what the pros/cons 
of these can be, if you have any insight into these I'd appreciate it. From 
taking an initial look into these options, it seems to me they are designed 
more to be static descriptors for displaying on social constructs and I'm 
concerned they there will be more overhead trying to query/parse overly 
complex schemas just to update the name of an open document name the user 
is openong in the title bar text? 

Ironically, as I understand it OpenGraph piggybacks on meta tags? so I 
don't see the benefit over just using a meta tag. The debacle here started 
with it being an piece of information that will be processed by the UA 
which the HTML spec notes that should be 'standard'.  

I'll add these in the considered alternatives, and will sync up with the 
Webkittens again to discuss. As far as things are, it seems that a meta tag 
with a *better* name value does the trick just fine. I'd look into having a 
way to efficiently reflect them to make them easy to update.

@Domenic The manifest doesn't seem to be a good place for this, as it is 
not something relevant to the description of the app. It is more of  a way 
of showing the name of an open file, or a section of the app for example. 
It's not necessarily an installed app problem only either, a developer 
might chose to use this bucket of information to update their app 
accordingly. I want to fix how a PWA's title bar reads, but this doesn't 
mean that info can't be used by an app developer when their app is running 
on a tab in the browser.

--Diego 

On Friday, 31 March 2023 at 03:50:02 UTC+1 dom...@chromium.org wrote:

> If this is an installed-app specific problem, could it be done through the 
> manifest instead? Using  as a side-channel for this, and then 
> furthermore going to add a document.subtitle property, seems pretty 
> intrusive for those goals.
>
> On Fri, Mar 31, 2023 at 2:15 AM Daniel Murphy  wrote:
>
>> I've had some questions about this, so I'll try to elaborate the problems 
>> that are being solved here (and they should probably be incorporated into 
>> the explainer):
>>
>>- For security reasons, we require the app name to be the first thing 
>>in the title of the app window. If the page title doesn't have this at 
>> the 
>>front, we prepend " - " to the title. This has resulted in 
>> things 
>>like "Gmail -  - Google.com Mail" as an app title, which is weird.
>>- The UX for the title of an 'app' window is different from a tab 
>>title - there can be slightly different goals here for what the website 
>>wants, so it's not uncommon for folks to want these to be different 
>> things.
>>- If the website tries to dynamically change these titles based on 
>>the display-mode media query, this involves needing to store things in 
>>places like local storage to cache the title to swap, etc. This is 
>>cumbersome and requires local storage now, which is good to avoid.
>>
>> Because of all of these, it seemed to make sense to allow the app title 
>> setting to just be a different thing. I wonder if maybe this name is 
>> misleading - maybe we should make this called *app-title-suffix* or 
>> *app-title-custom*... maybe others have better ideas here.
>>
>> This feature makes sense to me & seems pretty reasonable.
>>
>>
>> On Thu, Mar 30, 2023 at 12:34 AM Yoav Weiss  wrote:
>>
>>> +Daniel Murphy +Mason Freed 
>>>
>>> On Wed, Mar 29, 2023 at 1:54 AM 'Haben Foto' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emails 

 luig...@microsoft.com, habe...@microsoft.com


 Explainer 


 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DocumentSubtitle/explainer.md#html-document-subtitle-fix-installed-web-app-title-bar-text


 Specification 

 https://github.com/whatwg/html/compare/main...diekus:html:main


 Summary 

 Installed web apps can change the text on the title bar based on the 
 page's content. The current behavior is that the installed web application 
 will put the app's name from the manifest and append the page’s inner text 
 from the `` HTML tag in the head of the page. This often can create 
 awkward titles for s

Re: [blink-dev] Intent to Ship: Cookies Having Independent Partitioned State (CHIPS)

['Kaustubha Govind' via blink-dev]

CHIPS is now enabled for 100% of Chrome 110+ users. The feature is also now 
enabled 
by default 
 on the 
Chromium tip-of-tree, which corresponds to the Chrome 114 release.

On Thursday, March 30, 2023 at 9:10:50 AM UTC-4 Kaustubha Govind wrote:

> On Thu, Mar 30, 2023 at 1:24 AM Alexandru Mihai  wrote:
>
>> Awesome, thanks for letting me know 🙂
>>
>> The rollout will cover all versions from 110 to current, not just the 
>> latest version right?
>>
>
> Correct, all versions from Chrome 110 onwards are covered.
>  
>
>>
>> On Mar 30, 2023, at 03:49, Kaustubha Govind  wrote:
>>
>> Hi Alex,
>>
>> Apologies for the late response. The rollout is currently still at 10%; 
>> but we've been able to make progress on resolving metrics regressions; and 
>> intend to go to 100% either later this week, or early next week. We'll send 
>> an update here when that happens.
>>
>> K
>>
>> On Tuesday, March 21, 2023 at 12:47:46 PM UTC-4 Alexandru Mihai wrote:
>>
>>> Hi @Dylan,
>>>
>>> What's the current status of the rollout? Have you moved to 50%?
>>>
>>> Best,
>>> Alex M
>>>
>>> On Thursday, March 9, 2023 at 8:48:09 PM UTC+2 Dylan Cutler wrote:
>>>
>>> Hey all,
>>>
>>> Another update. We decided to roll out CHIPS to 10% of stable instead of 
>>> 50% to get a better picture on whether CHIPS is having impacts on any of 
>>> our guiding metrics before rolling out to 50%. Our plan is to let the 
>>> experiment gather data for 7 days at 10% before checking metrics again and 
>>> rolling out to 50%.
>>>
>>> Thanks,
>>> Dylan
>>>
>>> On Thu, Mar 2, 2023 at 4:15 PM Dylan Cutler  wrote:
>>>
>>> Hey all,
>>>
>>> We were planning to ramp up CHIPS to 50% of stable this week, but upon 
>>> doing metrics analysis we see some guardrail metrics have variations 
>>> between our control/experiment groups. We are delaying the ramp-up a couple 
>>> days to do additional analysis to make sure the variations are legitimate 
>>> and/or are actually caused by partitioned cookies.
>>>
>>> Thanks,
>>> Dylan
>>>
>>> On Wed, Feb 22, 2023 at 6:40 PM Dylan Cutler  
>>> wrote:
>>>
>>> Hey all,
>>>
>>> Another update for CHIPS, we will be rolling out to 5% stable starting 
>>> tomorrow. Canary/beta/dev will remain enabled at 50%.
>>>
>>> Thanks,
>>> Dylan
>>>
>>> On Thu, Feb 9, 2023 at 11:36 AM Dylan Cutler  
>>> wrote:
>>>
>>> Hey all,
>>>
>>> We have enabled the PartitionedCookies feature on 1% of stable. We will 
>>> continue to keep the feature enabled on 50% of canary/dev/beta.
>>>
>>> Thanks,
>>> Dylan
>>>
>>> On Wednesday, February 1, 2023 at 1:46:10 PM UTC-5 Dylan Cutler wrote:
>>>
>>> Hey all,
>>>
>>> Another quick update. Due to a partitioned cookies privacy bug 
>>>  that 
>>> was discovered, we have to delay the launch of CHIPS to M110, which is the 
>>> most recent release with the patch.
>>>
>>> Since M110 has been released to beta, we have enabled the 
>>> PartitionedCookies feature on 50% of dev/beta/canary. We will begin rolling 
>>> out to 1% stable next week.
>>>
>>> Thanks,
>>> Dylan
>>>
>>> On Fri, Jan 6, 2023 at 1:07 PM Dylan Cutler  wrote:
>>>
>>> Hey all, quick update.
>>>
>>> We intend to roll out the feature in gradual increments starting January 
>>> 10, 2023; and expect to reach 5% of Chrome instances on January 24, 2023 
>>> and stay there for a couple of weeks. Once we are satisfied that there is 
>>> no regression in metrics/behavior, we will proceed with the rollout.
>>>
>>> On Thu, Nov 24, 2022 at 10:55 AM Rick Byers  wrote:
>>>
>>> LGTM3
>>>
>>> On Thu, Nov 24, 2022 at 5:24 AM Yoav Weiss  wrote:
>>>
>>> LGTM2
>>>
>>> On Thu, Nov 24, 2022 at 10:43 AM Johann Hofmann  
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Nov 23, 2022 at 5:37 PM Chris Harrelson  
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Nov 23, 2022 at 10:34 AM 'Johann Hofmann' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>> Hi Yoav,
>>>
>>> On Wed, Nov 23, 2022 at 5:28 AM Yoav Weiss  wrote:
>>>
>>>
>>>
>>> On Thu, Oct 20, 2022 at 10:57 PM 'Dylan Cutler' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>> Contact emails:
>>>
>>> dylan...@google.com, kaust...@google.com 
>>>
>>> Proposal repository:
>>>
>>> https://github.com/privacycg/CHIPS
>>>
>>> Design doc:
>>>
>>>
>>> https://docs.google.com/document/d/1wL2lCXpaVOi0cWOn_ehfLFIZQxT3t0SH-ANnZYPEB0I/edit?usp=sharing
>>>
>>> Specification:
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/
>>>
>>>
>>> Can you expand on the plans for this I-D? Have y'all talked to the 
>>> HTTPWG? 
>>>
>>>
>>> Yes, this is being discussed in HTTPWG. Dylan presented CHIPS at IETF 
>>> 115, minutes are here: 
>>> https://httpwg.org/wg-materials/ietf115/minutes.html#cookies 
>>>
>>>
>>> Great. Were there any concerns raised there that might create a risk for 
>>> CHIPS?
>>>
>>>
>>> Not as far as I'm aware of. I couldn't attend the meeting in person, but 
>>> revisited it wi

Re: [blink-dev] PSA: Risky changes should be guarded by a Runtime Enabled Feature

[Rick Byers]

Oh that's interesting. It's possible there are cases where
disabled-by-default is the better choice. What do you see as the main trade
offs? Obviously it's important that we're testing the default configuration
- so either way, we shouldn't be relying on finch to change behavior except
in the emergency situation (or intentional A/B tests of course).

I was mainly thinking that for Runtime Enabled Features, we have the status
mechanism that biases towards status=stable. I suppose breaking changes are
more ambiguous. Eg. if we're removing an API that still has a Runtime
Enabled Feature, then setting it back to no status to unship it could be a
reasonable option. But I'd worry about the risk of confusion there. Eg. if
someone sets it to status=test or status=experimental after it's gone
to Chrome Stable with status=stable, there's risk of breaking changes
showing up in official builds but not in a lot of chromium developer
configurations that have --enable-experimental-web-platform-features set. I
don't think that usage is a good fit for how Runtime Enabled Features are
designed and communicated.

To me behavior changes of any type go through a flow of in-development ->
under test -> experimental -> stable (with killswitch) -> mature (no
flags). Once we hit the 'stable' feature in stable release for some period
of time, I don't think there's really any going back - only the possibility
of a new breaking change following this path. I guess this mirrors our
launch process as well. You don't need an I2D&R to flip the killswitch on a
new API in the first week of being on stable. But before long (maybe a
couple weeks?) you cross some threshold where any change or disabling is to
a launched feature and needs an I2D&R, and so logically a new Runtime
Enabled Feature working up to being on-by-default. Perhaps we should be
more thoughtful and explicit about this flow?

Rick

On Tue, Apr 4, 2023 at 2:24 PM Charles Harrison 
wrote:

> Thanks Rick this is really helpful. I have been involved in a few changes
> where API OWNERS said "flag-gated" and the implementer chose to use a
> disabled-by-default flag which I didn't push back on. I think just I needed
> this recalibration :)
>
> On Tue, Apr 4, 2023 at 1:16 PM Rick Byers  wrote:
>
>> Thanks Charlie. Yes I should have been specific, I'm really talking about
>> enabled-by-default flags here (eg. Runtime Enabled Feature with
>> status=stable).
>>
>> Note that our process for flipping a kill switch via finch includes first
>> landing a CL that disables the flag (confirming it doesn't break any tests
>> etc.). We're still learning how best to communicate these rare situations,
>> but that'll be an ongoing process. In general I've certainly found it
>> helpful when folks update their I2S threads with rollout status whenever it
>> deviates from the original plan.
>>
>> Rick
>>
>> On Wed, Mar 29, 2023 at 3:49 PM Charles Harrison 
>> wrote:
>>
>>> Thanks for posting this Rick. One call-out that I think is worth
>>> mentioning is the distinction between enabled-by-default flags and
>>> disabled-by-default flags. The general guidelines for choosing between
>>> these is in the links you posted, but given that it can be sometimes a
>>> subjective call it might be worth clarifying in e.g. API owners feedback on
>>> a particular I2S. I often see requests to flag guard a feature but
>>> sometimes it's ambiguous in which direction.
>>>
>>> On Wed, Mar 29, 2023 at 1:53 PM Rick Byers  wrote:
>>>
 Hey blink-dev,

 Within Google we’ve had a lot of discussion over the past year about
 how we should make increasing use of flags and kill switches
 
 to reduce the risk of breaking changes, but I realized there hasn’t been
 discussion here on blink-dev.

 Once a change hits stable it’s quite expensive and time-consuming to do
 an emergency patch, but much faster and cheaper to update a server config.
 For Google Chrome this means “Finch”, but other big chromium embedders like
 Edge also have their own system for setting flags dynamically. So
 increasingly we want to ensure that changes which might reasonably cause a
 regression are guarded by a flag wherever practical.

 For Blink this simply means using a Runtime Enabled Feature
 
 (or other base::Feature). I think we’re all largely in the habit of using
 this for new APIs, but we should also be using one for all intentional
 breaking changes and this is something the API owners will be asking about.

 See Flag Guarding Guidelines
 
 for more details and feel free to reach out to 

Re: [blink-dev] PSA: Risky changes should be guarded by a Runtime Enabled Feature

[Charles Harrison]

Thanks Rick this is really helpful. I have been involved in a few changes
where API OWNERS said "flag-gated" and the implementer chose to use a
disabled-by-default flag which I didn't push back on. I think just I needed
this recalibration :)

On Tue, Apr 4, 2023 at 1:16 PM Rick Byers  wrote:

> Thanks Charlie. Yes I should have been specific, I'm really talking about
> enabled-by-default flags here (eg. Runtime Enabled Feature with
> status=stable).
>
> Note that our process for flipping a kill switch via finch includes first
> landing a CL that disables the flag (confirming it doesn't break any tests
> etc.). We're still learning how best to communicate these rare situations,
> but that'll be an ongoing process. In general I've certainly found it
> helpful when folks update their I2S threads with rollout status whenever it
> deviates from the original plan.
>
> Rick
>
> On Wed, Mar 29, 2023 at 3:49 PM Charles Harrison 
> wrote:
>
>> Thanks for posting this Rick. One call-out that I think is worth
>> mentioning is the distinction between enabled-by-default flags and
>> disabled-by-default flags. The general guidelines for choosing between
>> these is in the links you posted, but given that it can be sometimes a
>> subjective call it might be worth clarifying in e.g. API owners feedback on
>> a particular I2S. I often see requests to flag guard a feature but
>> sometimes it's ambiguous in which direction.
>>
>> On Wed, Mar 29, 2023 at 1:53 PM Rick Byers  wrote:
>>
>>> Hey blink-dev,
>>>
>>> Within Google we’ve had a lot of discussion over the past year about how
>>> we should make increasing use of flags and kill switches
>>> 
>>> to reduce the risk of breaking changes, but I realized there hasn’t been
>>> discussion here on blink-dev.
>>>
>>> Once a change hits stable it’s quite expensive and time-consuming to do
>>> an emergency patch, but much faster and cheaper to update a server config.
>>> For Google Chrome this means “Finch”, but other big chromium embedders like
>>> Edge also have their own system for setting flags dynamically. So
>>> increasingly we want to ensure that changes which might reasonably cause a
>>> regression are guarded by a flag wherever practical.
>>>
>>> For Blink this simply means using a Runtime Enabled Feature
>>> 
>>> (or other base::Feature). I think we’re all largely in the habit of using
>>> this for new APIs, but we should also be using one for all intentional
>>> breaking changes and this is something the API owners will be asking about.
>>>
>>> See Flag Guarding Guidelines
>>> 
>>> for more details and feel free to reach out to me and/or
>>> chrome-atls-disc...@google.com with questions or concerns.
>>>
>>> Thanks,
>>>
>>>Rick
>>>
>>> --
>>> 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/CAFUtAY9iR-n102RPZWfqpUGjYm9W2LpFFb5%2BodimGFUC8Dv8ZA%40mail.gmail.com
>>> 
>>> .
>>>
>>

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

Re: [blink-dev] PSA: Risky changes should be guarded by a Runtime Enabled Feature

[Rick Byers]

Thanks Charlie. Yes I should have been specific, I'm really talking about
enabled-by-default flags here (eg. Runtime Enabled Feature with
status=stable).

Note that our process for flipping a kill switch via finch includes first
landing a CL that disables the flag (confirming it doesn't break any tests
etc.). We're still learning how best to communicate these rare situations,
but that'll be an ongoing process. In general I've certainly found it
helpful when folks update their I2S threads with rollout status whenever it
deviates from the original plan.

Rick

On Wed, Mar 29, 2023 at 3:49 PM Charles Harrison 
wrote:

> Thanks for posting this Rick. One call-out that I think is worth
> mentioning is the distinction between enabled-by-default flags and
> disabled-by-default flags. The general guidelines for choosing between
> these is in the links you posted, but given that it can be sometimes a
> subjective call it might be worth clarifying in e.g. API owners feedback on
> a particular I2S. I often see requests to flag guard a feature but
> sometimes it's ambiguous in which direction.
>
> On Wed, Mar 29, 2023 at 1:53 PM Rick Byers  wrote:
>
>> Hey blink-dev,
>>
>> Within Google we’ve had a lot of discussion over the past year about how
>> we should make increasing use of flags and kill switches
>> 
>> to reduce the risk of breaking changes, but I realized there hasn’t been
>> discussion here on blink-dev.
>>
>> Once a change hits stable it’s quite expensive and time-consuming to do
>> an emergency patch, but much faster and cheaper to update a server config.
>> For Google Chrome this means “Finch”, but other big chromium embedders like
>> Edge also have their own system for setting flags dynamically. So
>> increasingly we want to ensure that changes which might reasonably cause a
>> regression are guarded by a flag wherever practical.
>>
>> For Blink this simply means using a Runtime Enabled Feature
>> 
>> (or other base::Feature). I think we’re all largely in the habit of using
>> this for new APIs, but we should also be using one for all intentional
>> breaking changes and this is something the API owners will be asking about.
>>
>> See Flag Guarding Guidelines
>> 
>> for more details and feel free to reach out to me and/or
>> chrome-atls-disc...@google.com with questions or concerns.
>>
>> Thanks,
>>
>>Rick
>>
>> --
>> 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/CAFUtAY9iR-n102RPZWfqpUGjYm9W2LpFFb5%2BodimGFUC8Dv8ZA%40mail.gmail.com
>> 
>> .
>>
>

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

Re: [blink-dev] Re: Intent to Implement & Ship: User-Agent Reduction Phase 6 (deviceModel and androidVersion reduction in Android)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 6  is currently ramping up to 10% of the stable release 
population. 

Thanks.
Victor

On Tuesday, March 21, 2023 at 6:41:47 PM UTC-4 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 6  is currently ramping up to 5% of the stable release 
> population. We will keep monitor the change during the 2 week experiment. 
>
> Thanks.
> Victor
>
> On Monday, March 20, 2023 at 12:09:41 PM UTC-4 Mike Taylor wrote:
>
>> Hi all,
>>
>> Correcting my message on 3/3 to be consistent with the rollout timeline I 
>> posted on Feb 16 
>> .
>>  
>> We intend to begin the ramp up to 5% of stable traffic tomorrow.
>> [done] Stable 1%: Feb 21, 2023
>> [tomorrow] Stable 5%: Mar 21, 2023 (~4 weeks after previous)
>> Stable 10%: Apr 4, 2023 (~2 weeks after previous)
>> Stable 50%: Apr 18, 2023 (~2 weeks after previous)
>> ToT Default: May 2, 2023 (~2 weeks after previous)
>> Stable 100%: May 2, 2023
>>
>> thanks,
>> Mike
>>
>> On 3/3/23 1:28 PM, Mike Taylor wrote:
>>
>>
>>- 
>>
>>[done] February 21: Phase 6 roll-out starts one week after the launch 
>>of Chrome 110 Stable with 1% traffic. 
>>- 
>>
>>March 21: Roll-out increases to 10% traffic. 
>>- 
>>
>>April 4: Roll-out increases to 50% traffic.
>>- 
>>
>>April 18: Roll-out reaches full Stable population with 100% traffic.
>>
>>

-- 
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/fbd7f70c-06c4-4036-a6c3-65693f1d31f1n%40chromium.org.

Re: [blink-dev] Intent to Experiment: Background Blur API.

[eero.h...@intel.com]

Hi,

On Thurday, March 30, 2023 at 3:43:06 PM UTC+3Kaustubha Govind wrote:

Would you be able to expand your Privacy Considerations section to address 
whether the API is likely to expose any new fingerprinting surfaces?


I have added Fingerprinting 
 
subsection to our  Privacy Considerations section.

Particularly; I am interested in understanding:

   1. Whether there is additional information about the platform (e.g. OS 
   version) that can be gleaned by querying whether the platform supports 
   background blurring. Note that with the User Agent Reduction 
    work, 
   we are attempting to limit default access to some of this platform 
   identifying information.

In short, there isn't but see the linked Fingerprinting subsection for 
detailed analysis. 


   1. How stable do we expect the blur to be across hardware 
   configurations? It would be unfortunate if this turned into a problem 
   similar to Canvas Fingerprinting.

In Canvas Fingerprinting, sites can draw to a canvas (the source) as they 
like and fingerprint the result which may be a bit different on different 
platforms and platform versions. I assume that you refer to this (lack of) 
stable result here.
This is really not an issue with background blur. In the case of the 
getUserMedia tracks, the sites has access to tracks which may have 
background blur in effect and may allow background blur to be 
disabled/enabled and to the resulting frames. However, sites have no 
control on the source (what's in the field-of-view of a camera) so it is 
not possible to reprocess the same frames on different platforms and 
platform versions and to compare the results.
 

Perhaps one mitigation here is that the capability is gated behind the 
getUserMedia() permission; which limits drive-by fingerprinting?


That is the main gate but see the linked Fingerprinting subsection for 
detailed analysis. 

BR,
 Eero

-- 
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/30abe916-ec06-4983-b994-d66a6dc59459n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Private State Tokens API

[Mike Taylor]

Thanks for filing issues!

On 4/3/23 8:59 PM, Martin Thomson wrote:

Hi Mike,

Unfortunately, I think that the specification needs considerable work 
before it would be considered to be acceptable.  I've started filing 
issues, but I am finding it rough going.  It is very hard to follow, 
it lacks basic explanations of key features and their operation (this 
information is encoded in a labyrinth of algorithms), and I don't 
think that the design is appropriate.


I still don't understand the proposed consistency mechanism completely 
(see above), but it looks like the current design is one where issuer 
commitments are delivered by a user agent vendor to each user agent, 
using an update or remote configuration system.  This is not a bad way 
to achieve consistency (and maybe correctness), but it sacrifices 
other properties that are important, such as avoiding having browser 
vendors as gatekeepers in the system.  Also, this expectation is not 
documented.


Perhaps greater familiarity with this will come with time, but as of 
this moment, I would have to say that this is not ready to be 
interoperable.  I've opened a few issues with larger concerns, though 
there are lots of minor things I've found that follow on from each of 
these.


On Fri, Mar 31, 2023 at 11:04 PM Mike Taylor  
wrote:


Hey Martin,

On 3/31/23 3:38 AM, Martin Thomson wrote:


I will note that the current state of the specification does not
seem to match IETF Privacy Pass documents.  I think that shipping
is premature on that basis.

Mozilla deferred our position on this because the specifications
were not in a particularly healthy state at the time.  That
situation doesn't seem to have changed much.

I think the spec has improved significantly from where it was just
a few months ago, that said...

More concerning is the lack of a widely acceptable key
consistency and correctness mechanism.  A more rigorous analysis
of the information transfer properties of the proposed system
will be needed before we can be confident that this is OK to ship.


It would be great if you could file issues with these concerns:
https://github.com/WICG/trust-token-api/issues/new


(I'm sorry Steven that I didn't notice this before I had a chance
to discuss this in person this week, but I've been overwhelmed
and blink-dev isn't something I watch closely.)

On Sat, Mar 18, 2023 at 4:29 AM 'Steven Valdez' via blink-dev
 wrote:

Folks from Mozilla have done some recent analysis on the
privacypass protocol and some supportive of the general
protocol, however we haven't gotten any newer signals on
whether the PST system where some sites are issuers and other
sites redeem tokens is of interest to them. Apple has been
pursuing Private Access Tokens, which is a version of
privacypass with the device vendor acting as the issuing party.

On Fri, Mar 17, 2023 at 12:46 PM 'Mike West' via blink-dev
 wrote:

I'm quite excited to see this ready to ship, thanks for
the work you've put into it over the years.

Both Mozilla and Apple's positions seem dependent upon
analysis of the underlying Privacy Pass protocol. Have
you had additional communication with them about how
things are going, since it's been a while since the
initial request in both cases?

-mike

On Friday, March 17, 2023 at 5:35:06 PM UTC+1 Steven
Valdez wrote:


Contact emails

ayk...@google.com, sva...@chromium.org,
kaust...@chromium.org


Explainer

https://github.com/WICG/trust-token-api



NB: We'll rename the repository to
private-state-token-api when it's adopted by the
antifraud CG.


Specification

https://wicg.github.io/trust-token-api



Design docs



https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit




Summary

The Private State Token API is a new API for
propagating user signals across sites, without using
cross-site persistent identifiers like third party
cookies for anti-fraud purposes. Anti-fraud methods
that rely on third party cookies will not work once
third party cookies are deprecated. The motivation of
this API is to provide a means to fight fraud in a
world with no third party cookies. The API prevents
 

Re: [blink-dev] Intent to Implement and Ship: Use RegExp v flag instead of u for HTML pattern attribute

['Mathias Bynens' via blink-dev]

Thanks to the UseCounter + UKM + M112 hitting Stable, more results are
starting to come in. I’ll be collecting public examples of potential
incompatibilities here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1412729#c11 So far 0
out of the 2 examples cause any actual breakage — fingers crossed that
trend continues.

On Mon, Apr 3, 2023 at 10:26 AM Philip Jägenstedt 
wrote:

> I took a look at https://github.com/whatwg/html/pull/7908 and it looks
> like there's agreement to merge it, but it's waiting on this intent to be
> approved. Normally we block in the other direction, but that's fine, as
> long as the spec change is merged.
>
> Looks like there's broad support for this change, and it's just a question
> of the site compat risk. ~0.04% as an upper bound is quite high. Can we
> wait until the use counter is in stable and look at a random set of sites
> hitting the use counter to determine what the real-world breakage looks
> like?
>
> On Fri, Mar 31, 2023 at 5:07 PM 'Mathias Bynens' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Fri, Mar 31, 2023 at 4:35 PM Mike Taylor 
>> wrote:
>>
>>> Hey Mathias,
>>> On 3/31/23 5:56 AM, Mathias Bynens wrote:
>>>
>>> Contact emails
>>>
>>> math...@chromium.org
>>>
>>> Specification
>>>
>>> https://github.com/whatwg/html/pull/7908
>>>
>>> Summary
>>>
>>> The  attribute allows developers to specify a regular
>>> expression pattern against which the input’s values are checked for
>>> validity.
>>>
>>> 
>>>
>>>   Part number:
>>>
>>>   >>
>>>  title="A part number is a digit followed by three uppercase
>>> letters.">
>>>
>>> 
>>>
>>> When the pattern attribute was first implemented, these regular
>>> expressions were compiled without any RegExp flags. In 2014, the HTML
>>> Standard changed this by implicitly enabling the u flag for the pattern
>>> attribute, enabling better Unicode support (including support for Unicode
>>> character properties like \p{Letter}). This change shipped in Chrome 53.
>>> 
>>>
>>> Now, we’re taking this to the next level by enabling the new RegExp v
>>> flag  instead of u, enabling the
>>> use of set notation, string literal syntax, and Unicode properties of
>>> strings.
>>>
>>> (Context: The RegExp v flag is a JavaScript language feature which
>>> previously went through the Blink Intents process and shipped in Chrome
>>> 112 . This new
>>> ChromeStatus entry is specifically about integrating it with the HTML
>>> pattern attribute.)
>>>
>>> Blink component
>>>
>>> Blink>Forms
>>> 
>>>
>>> Search tags
>>>
>>> unicode , regexp
>>> , pattern
>>> , validation
>>> 
>>>
>>> TAG review
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> The spec patch at https://github.com/whatwg/html/pull/7908 lists the
>>> potentially breaking changes. Some patterns that previously would compile,
>>> now throw an early error with the v flag — specifically those with a
>>> character class including either an unescaped special character or a double
>>> punctuator.
>>>
>>> We expect such patterns to be rare. To validate this assumption we’ve
>>> added a UseCounter called
>>> HTMLPatternRegExpUnicodeSetIncompatibilitiesWithUnicodeMode
>>> 
>>> in M112, which tracks patterns in any JavaScript u RegExps generated
>>> via the HTML pattern attribute that would throw if they were used with
>>> the v flag.
>>>
>>> Importantly, note that any throwing pattern gracefully degrades — it
>>> simply behaves as if the pattern attribute wasn’t present, resulting in 
>>> inputElement.validity.valid
>>> === true for any input value. Consequently, the only compatibility risk
>>> is that some value/pattern combinations that would previously result in
>>> inputElement.validity.valid being false now result in it being true. Thus,
>>> for every UseCounter hit, it could still be that there is no actual
>>> breakage — the UseCounter just gives us the upper bound. The currently
>>> available data from Beta suggests the UseCounter hits for 0.0393% of
>>> Chrome page loads.
>>>
>>> I'm somewhat curious to see how much that UseCounter will grow (if at
>>> all) when 112 goes to stable next week...
>>>
>> Me too, and FWIW I'd understand if you and the other API owners prefer to
>> wait until there’s some data for Stable before responding to this Intent.
>>
>>> Do you have any concerns about certain inputs being sent to a server
>>> that might not have any backend validation, that would previously b

Re: [blink-dev] Intent to Prototype: CSS font-size-adjust: two-value syntax

['Dominik Röttsches' via blink-dev]

Hi ChangSeok,

Thanks for confirming the expected behavior and testing in FF.

I plan to implement the same behavior of Firefox, following the spec
> document.
>

Can you share a few more details how you plan to achieve that? Have you
been able to verify that you can achieve this behavior in a local
development branch? If so, what changes are needed to the interaction
between the two features in Blink?

Thanks,

Dominik


On Fri, Mar 31, 2023 at 12:56 AM ChangSeok Oh  wrote:

> Hi Dominik,
>
> Thanks for informing me about the history and conflict between @font-face:
> size-adjust and font-size-adjust.
>
> Per your comment, I investigated the latest spec document and how Gecko
> handles the conflict.
> In a nutshell, the draft spec prioritizes the font-size-adjust over the
> size-adjust (i.e., overriding) [1], and Gecko follows the rule.
>
> The following is the related part of the document.
>
> > The font-size-adjust property is applied after the size-adjust
> descriptor.
> > NOTE: The consequence of applying font-size-adjust after size-adjust is
> that size-adjust appears to have no effect.
>
> In addition, I wrote a simple test on jsfiddle.net [2]. Please feel free
> to test it with your Firefox.
>
> I plan to implement the same behavior of Firefox, following the spec
> document.
>
> Best,
>
> [1]
> https://w3c.github.io/csswg-drafts/css-fonts-5/#valdef-ascent-overridedescriptor-percentage
> [2] https://jsfiddle.net/wfsdagc7/
>
> --
> ChangSeok
>
> > On Mar 30, 2023, at 12:13 AM, Dominik Röttsches 
> wrote:
> >
> > Hi ChangSeok,
> >
> > Thanks for working on this. During the development and shipping of the
> @font-face size-adjust descriptor we found that at least in our code the
> font-size-adjust implementation was not compatible with this change. As
> size-adjust was a higher priority then, the font-size-adjust
> RuntimeEnabledFeature was downgraded from experimental to test, discussion
> during review in this change.
> >
> > We have a related TODO in the code that when the size-adjust descriptor
> is present in a @font-face, the font-size-adjust property is ignored. Could
> you describe how you plan to address this? Could you also investigate how
> FireFox handles cases where the size-adjust descriptor and font-size-adjust
> interact. Are there any problems arising from the use of both at the same
> time?
> >
> > Dominik
> >
> > On Tue, Mar 28, 2023 at 9:35 PM ChangSeok Oh 
> wrote:
> >
> >
> > > On Mar 28, 2023, at 6:29 AM, David Baron  wrote:
> > >
> > > On Mon, Mar 27, 2023 at 6:33 PM ChangSeok Oh 
> wrote:
> > >Interoperability and Compatibility
> > >
> > >Gecko: Publicly support
> > >
> > >WebKit: Positive and in development
> > >https://bugs.webkit.org/show_bug.cgi?id=254191
> > >https://github.com/WebKit/WebKit/pull/11744 (I am the author)
> > >
> > >Web developers: No signals
> > >
> > >Other signals:
> > >
> > >WebView application risks
> > >No known risks
> > >
> > > It might be useful to separately describe (for some or all of these
> sources) support for the 1-value syntax (CSS 2.1, css-fonts-3, css-fonts-4)
> and support for the 2-value syntax (css-fonts-5).  For example, according
> to MDN, Gecko has been shipping the 1-value syntax since Firefox 3 (June
> 2008) and the 2-value syntax since Firefox 92 (September 2021).
> >
> > We already have a separate feature flag and ChromeStatus page [1].
> Unfortunately, it has been pending for years. I plan to ship it with this
> two-value syntax once this new feature is done. But I don’t have a strong
> opinion on the shipping plan. We can consider shipping separately.
> >
> > [1] https://chromestatus.com/feature/5720910061371392
> >
> > >
> > > I'll also add that I'm a big fan of this feature and am happy to see
> it implemented.
> >
> > 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/0E07FF35-2FC4-43BA-A55E-F269997FDD0D%40gmail.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/CAN6muBu_VMCaPtUc9xsmx6P630fqEEL8zE_Wt5Z_t4DmgsjW-g%40mail.gmail.com.