Re: [blink-dev] Intent to Ship: CSS headline balancing

[fantasai]

On 3/17/23 02:02, Koji Ishii wrote:
On Fri, Mar 17, 2023 at 4:40 AM fantasai > wrote:


That test doesn't cover the interaction of other values of `white-space` 
with
the `nowrap` value of `text-wrap`. It would be incorrect for e.g.
`white-space: pre` to return `text-wrap: wrap`.

I think it would be better to just implement both longhands of `white-space`
properly.

Implementing `nowrap` and other values is easy but it creates other new compat 
risks that are more difficult for authors to handle.


Can you outline these new compat risks that only apply to `nowrap`? Also, are 
they filed as an issue against the CSS spec? If there is a real compat risk to 
implementing the spec, then the spec needs to be changed.


Note that if the spec changes to not have a shorthanding relationship due to 
compat risks, then that means your implementation would need to change to stop 
faking a shorthand relationship also.


Going back to that first quoted point: you are currently not testing the value 
of `text-wrap` when `white-space: pre` has been declared. If you are returning 
`text-wrap: wrap` rather than `text-wrap: nowrap`, then we have a problem, 
because that is not compatible with what the spec requires.


Since you think this is the correct thing to do, can you explain why you think 
it is better for Blink to ship a behavior change in the future (to match the 
spec) vs. shipping the correct behavior initially?


Btw, I notice you are only testing the shorthanding side-effects you have 
carefully faked in your code, rather than all of them. I know it's natural to 
only write (passing) tests for things you've specifically implemented, but it 
is misleading...  because if Blink intends to ever follow the spec, there are 
property interactions here that will noticeably change. And your reviewers 
should be made aware of that.



With the current impl, authors can detect the situation by 
`supports(‘text-wrap: nowrap’)`.


I don't understand what this suggestion is solving.


I'm not concerned about the quality of the balancing, as I'm sure it's fine,
and it will improve over time... my concerns are mainly with
a) interaction of the properties
b) any layout interactions with e.g. floats, initial-letter, positioning,
text justification, box sizing, etc.
c) whether the CSSWG considers this stable enough to ship, or if there are
unresolved concerns about the design of the feature

I understand that the spec is still in early draft, it’s WD, not CR, PR, nor 
REC. If the spec changes, we can change our implementation accordingly.


As far as I understand, once Blink ships something, whether it is willing to 
change its implementation generally depends on the usage rates of the new 
feature. So if Blink ships the feature, and it is widely used, then Blink 
would be unwilling to change or drop the feature. Does that not apply here?


Also, why not ask the CSSWG about (c)?


I'll note that there was an issue filed in the CSSWG repo recently in
response
to the Blink implementation:
https://github.com/w3c/csswg-drafts/issues/8516

and it raises questions about sizing and floats, among other things.

Thank you for citing this, yes, that was great feedback. I fixed bugs reported 
there, Tab and I responded, and the reporter responded “agree that this is the 
best approach 
”.


The reporter was agreeing specifically with adjusting the limit to 4 lines 
rather than 10, not with anything else. Some of the other points brought up by 
the reporter include:


* Interaction with `text-align` (which you seem to have fixed)
* Interaction with floats (no tests in WPT)
* Interaction with `initial-letter` (no tests in WPT)
* Interaction with intrinsic sizing (not seriously discussed, but imho one of 
the most important questions that would have been worth investigating with the 
prototype)



See also questions in the 2nd paragraph of
https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz6PIXaI/m/a9OGhvaNAAAJ 

which seem to have been mostly ignored...

The #8516 you cited above  
has some initial feedback.
I also asked some specific questions inline, so let me quote them in list form 
since they seem to be repeatedly overlooked:


* Will this be sufficiently useful without any integration into intrinsic 
sizing?
* Does it actually solve the problems authors want it to solve, or is there 
something still unsatisfied here?


> Also I will share any feedback we get with the WG and I look forward to 
discussing them.


I think it would be useful to know if you have positive feedback from web 
developers who have tried to incorporate it into actual designs, or if 

[blink-dev] Intent to Ship: requestStorageAccessFor (for First-Party Sets)

[Johann Hofmann]

Contact emails

johann...@chromium.org, mreichh...@chromium.org, kaustub...@chromium.org

Explainer

https://github.com/privacycg/requestStorageAccessForOrigin

(note that we recently updated the name to remove “origin”, but not yet the
repository name)

Specification

https://privacycg.github.io/requestStorageAccessForOrigin

Summary

An extension to the Storage Access API that allows a top-level site to
request access to unpartitioned ("first-party") cookies on behalf of
embedded sites. Browsers will have discretion to grant or deny access, with
mechanisms like First-Party Set membership as a potential signal. This
allows for use of the Storage Access API by top-level sites.

For now, we intend to ship requestStorageAccessFor without user-facing
prompts, instead relying on information from First-Party Sets to determine
which sites should be granted storage access.

Blink component

Blink>StorageAccessAPI


TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/736)

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

This has been discussed with other browser vendors outside of the
standards-positions repositories. These browsers ship this functionality as
a version that is only accessible to internal code (as an
anti-cross-site-cookie-breakage measure), but haven’t exposed it to
developers, primarily out of prompt relevance concerns. There have been
mixed reactions to our proposal, with the primary feedback being on reputation
concerns with potential prompts
, and
a desire to maintain the security benefits from cross-site cookie blocking
to an even larger extent
. We
intend to work on these concerns in collaboration with other browsers (if
possible).

Edge: No public signal. However, we’ve discussed this with Edge and they
are supportive of this additional API surface and will work on enabling it
(i.e. providing the prompts or FPS mechanisms to gate it) on Edge as well.

Web developers:

Positive. There has been developer

feedback  on SAA
asking for this or similar functionality, as well as communication with
partners that are trying out the API to utilize FPS.

Ergonomics

Like requestStorageAccess, this API requires additional work from the
developer compared to the old state of "passive" cross-site cookie access.
This is an inherent, intentional property of the design.

For security reasons, this feature requires developers to use either CORS
headers (for non-iframe subresources) or requestStorageAccess in iframes to
be able to access cross-site cookies after a requestStorageAccessFor call.


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

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

No. This will be supported on Windows, Mac, Linux, Chrome OS, and Android,
but will not initially be supported on Android WebView.

Is this feature fully tested by web-platform-tests

?

Yes, https://wpt.fyi/results/top-level-storage-access-api. Note that while
tests are passing locally in Chrome, they’re not yet showing up on wpt.fyi
because the feature wasn’t included in the experimental web platform
features flag.

Flag name

StorageAccessAPIForOriginExtension

Requires code in //chrome?

True, as we’re adding a new permission and integrating with FPS. As
mentioned in the FPS I2S, Chromium-based browsers should be able to consume
the list through component updater.

Estimated milestones

Shipping in M113.


Anticipated spec changes

Some details of this API are still being discussed in the Privacy CG
 and
there may be backwards-incompatible changes in the future. As mentioned
above, the primary feedback has been on reputation concerns with potential
prompts
, and
a desire to maintain the security benefits from cross-site cookie blocking
to an even larger extent
.

We are confident in shipping the API in its current state to better
understand and iterate on real-world developer needs, and accept the
responsibility of supporting potential future breaking API changes. Since
use of 

[blink-dev] Intent to Ship: Storage Access API (within First-Party Sets)

['Johann Hofmann' via blink-dev]

Contact emails

bra...@microsoft.com, johann...@chromium.org, cfred...@chromium.org

Explainer

https://github.com/privacycg/storage-access

Specification

https://privacycg.github.io/storage-access

(Merging to HTML is tracked in https://github.com/whatwg/html/issues/9000)

Design docs

Original Design


Updates to enable per-frame grants



Summary

Browsers may block third-party resources from accessing cookies and other
storage for privacy and security reasons. The most popular reason is
cross-site tracking prevention. Such blocking breaks authenticated
cross-site embeds such as commenting widgets, embedded payment providers,
and subscribed video services.

The Storage Access API provides a means for authenticated cross-site embeds
(iframes) to check their blocking status and request access to cross-site
cookies if they are blocked.

As a Chromium default, we intend to ship the Storage Access API without
user-facing permission prompts, instead relying on information from
First-Party Sets to determine which sites should be granted storage access.
The request is auto-denied outside of First-Party Sets
. However, there is a flag that
allows other Chromium-based browsers to show user permission prompts. This
is utilized e.g. in Microsoft Edge, but the Edge team also intends to
support integration with First-Party Sets after Chrome ships (see separate
I2S on FPS).

Blink component

Blink>StorageAccessAPI


TAG review

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

TAG review status

Positive


Risks

Interoperability and Compatibility

The API surface itself is simple (examples here
). The API does not
impact the web platform unless pages explicitly invoke it. Different
browser implementations may react differently to storage access requests
(e.g. the user flow for Safari
 or Firefox
using heuristics
)
and likely will choose to use different heuristics and/or user-signals.
These heuristics already vary among browsers shipping this API, so sites
cannot rely on the storage access request succeeding in any specific
situation. A goal of the API is to allow browser vendors to apply rules
that they think best serve their users while allowing sites to navigate
those implementation differences. We are still working on reaching
alignment across browsers where possible.

Gecko: Shipped (
https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API)

WebKit: Shipped

 (https://webkit.org/blog/8124/introducing-storage-access-api)

Web developers: Positive

There has been great developer interest in the Storage Access API, given
that it provides the only predictable way of working with cross-site
cookies in many browsers. Various developers have chimed in on
https://github.com/whatwg/html/issues/3338 and filed issues on
https://github.com/privacycg/storage-access.

To summarize, there seems to be general support for the idea of providing
an API like this, but opinions have greatly differed on what the provided
capabilities should be. We recognize that the current iteration of the SAA
is limited in some capabilities, e.g. no access to DOM Storage (recently
also removed in Firefox
),
and are considering potential future improvements.

An example of this kind of mixed-but-positive feedback is a recent
presentation by the Google Workspace team:
https://github.com/privacycg/meetings/issues/25

Other signals:

Ergonomics

The Storage Access API doesn't provide the same developer ergonomics as
"plain" cookies, for privacy and anti-abuse reasons. Notably, it is built
for specific use cases that involve an iframe that a user interacts with to
perform some kind of login/authentication, such as embedded comment
widgets. Cross-site cookie access in non-interacted/non-authenticated user
flows, such as for online ads, is generally out of scope for this API.

To provide better developer ergonomics in non-iframe use cases for access
to cross-site cookies within a first-party set, we intend to ship an
extension to the Storage Access API called "requestStorageAccessFor
" (see related
I2S). However, that API should be considered an enhancement and not
directly covered by this intent


Activation

For this initial release, Chrome is shipping the Storage Access API without
a user prompt. 

[blink-dev] Intent to Ship: First-party sets

[Johann Hofmann]

Contact emails

cfred...@chromium.org, shuu...@chromium.org, kaustub...@chromium.org,
johann...@chromium.org

Explainer

https://github.com/WICG/first-party-sets

Specification

https://wicg.github.io/first-party-sets

Design docs

First-Party Sets: Initial prototype description


First-Party Sets Prototype Design Doc


Summary

First-Party Sets (“FPS”) provides a framework for developers to declare
relationships among sites, to enable limited cross-site cookie access for
specific, user-facing purposes. This is facilitated through the use of
the Storage
Access API  and
requestStorageAccessFor
 API.

The First-Party Sets proposal that we intend to ship significantly differs
from its originally proposed design, as we have incorporated feedback from
various stakeholders. An overview of what changed and why can be found here

.

It’s important to note that because of its integration with the Storage
Access API and requestStorageAccessFor, FPS is not a feature that is
directly web-exposed. We still consider its overall impact on the web
platform to be big enough to follow the blink launch process.

We have submitted adjacent Intents to Ship both requestStorageAccess and
requestStorageAccessFor.


Blink component

Privacy


TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

This is not a breaking change. To use it, sites will need to opt in to
using First-Party Sets. There is no change to existing behavior for sites
not opting in to First-Party Sets.


Gecko: Negative (https://github.com/mozilla/standards-positions/issues/350)

WebKit: Negative (https://github.com/WebKit/standards-positions/issues/93)

Web developers: Positive. FPS has been extensively discussed during its
incubation in the Privacy CG and the WICG. Throughout this discussion we've
consistently seen great interest and participation by web developers.

   -


   
https://developer.chrome.com/docs/privacy-sandbox/first-party-sets-evolution/#working-with-the-ecosystem
   -

   https://lists.w3.org/Archives/Public/public-privacycg/2022Jun/0031.html



Other signals: Edge: Positive. Microsoft has been “generally supportive of
the effort”

since 2020 and had a co-editor on the spec for a while. Edge, in
conversations, has confirmed their intent to support FPS after it ships in
Chrome. Through the component updater the FPS list should be available to
Edge. We will work with the Edge team to make sure that they can
potentially host their own version of the (same) list and to ensure
cooperation on managing the list.

Ergonomics

Use of the Storage Access API requires sites to run JavaScript before they
can access their cookies. No performance concerns.


Activation

Site owners will need to register their first-party sets in a public
process, categorizing their usage in subsets and passing a number of
technical checks, such as verifying ownership with a /.well-known/ file.
The submission guidelines and checks are described in full detail on
https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md

This feature is meant to allow developers to preserve critical use cases
(e.g., shared infrastructure across ccTLDs, service domains)  when Chrome
deprecates third-party cookies. As such, it will provide only limited
utility right now, but give developers an important head start in testing
and preparing their sites for the upcoming deprecation.

FPS will require usage of the Storage Access API and/or requestStorageAccessFor
API to have a web-observable effect. This improves cross-browser
compatibility (for Storage Access API) but might come with some migration
cost for developers that were previously relying on passive cookie access
without JavaScript calls.


Security

None


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

We show a DevTools warning when third-party cookies are blocked and the
top-level site is in the same First-Party Set as the embedded site. Further
developer tooling will likely be needed to support the eventual deprecation
of third-party cookies.


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

No. This will be supported on Windows, Mac, Linux, Chrome OS, and Android,
but will not 

Re: [blink-dev] Re: Intent to Ship: Display and content-visibility animations

[Joey Arhar]

> How do we expect developers to use the feature before it is ubiquitously
available?
> Do we expect them to perform feature detection and compensate for it in
JS? Something else? What would that look like?

This and the other popover/dialog inspired animation features are a
progressive enhancement. They are hard to polyfill and we don't expect
developers to feature detect and compensate. If they choose to use these
features before they are implemented in other browsers, then the animations
won't happen but popovers and dialogs (the intended use cases) will still
work.

On Mon, Mar 20, 2023 at 2:03 AM Yoav Weiss  wrote:

>
>
> On Wed, Mar 15, 2023 at 11:09 PM Joey Arhar  wrote:
>
>> TAG review: https://github.com/w3ctag/design-reviews/issues/824
>> WebKit standards position:
>> https://github.com/WebKit/standards-positions/issues/147
>> Mozilla standards position:
>> https://github.com/mozilla/standards-positions/issues/762
>>
>> On Wed, Mar 15, 2023 at 1:37 PM Joey Arhar  wrote:
>>
>>> Contact emailsfla...@chromium.org, jar...@chromium.org
>>>
>>> Explainer
>>> https://github.com/w3c/csswg-drafts/issues/6429#issuecomment-1318933547
>>>
>>> Specificationhttps://drafts.csswg.org/css-display-4/#display-animation
>>>
>>> Summary
>>>
>>> Support specifying display and content-visibility in animations. This
>>> support allows for developers to create exit animations after which the
>>> element automatically becomes display: none or content-visibility: hidden
>>> without needing to write any javascript to handle that switch after the
>>> animation is finished. This allows exit animations for elements to be added
>>> purely in CSS.
>>>
>>>
>>> Blink componentBlink>Animation
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Developers may have display specified in existing animations which would
>>> start being included in their animation after this change.
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Positive (
>>> https://front-end.social/@mia/109433817951030826)
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This will be used in tandem with popover/dialog elements and the
>>> CSSTransitionDiscrete feature. Usage of this feature will not make it hard
>>> for chrome to maintain good performance.
>>>
>>>
>>> Activation
>>>
>>> It will not be challenging for developers to use this feature
>>> immediately.
>>>
>>
> How do we expect developers to use the feature before it is
> ubiquitously available?
> Do we expect them to perform feature detection and compensate for it in
> JS? Something else? What would that look like?
>
>
>>>
>>> Security
>>>
>>> This doesn't extend developer capabilities beyond styles the developer
>>> could set via existing CSS or scripts.
>>>
>>>
>>> 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?
>>>
>>> This is not high risk for WebView, but is controlled by a base::Feature
>>> anyway.
>>>
>>>
>>> Debuggability
>>>
>>> This feature extends the capabilities of existing css animations, css
>>> transitions and web animations and will show amongst other developer
>>> animations.
>>>
>>>
>>> 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 nameCSSDisplayAnimation
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1395394
>>>
>>> MeasurementThis feature does not have any UseCounters.
>>>
>>> Availability expectationI'm not sure when this will be implemented in
>>> safari and firefox. I don't think that they have started implementing this
>>> yet, but we only very recently got this resolved in CSSWG.
>>>
>>> Adoption expectationThis will be the best practice for animating the
>>> entry and exit if dialogs and popovers immediately.
>>>
>>> Adoption planI don't have an adoption plan.
>>>
>>> Non-OSS dependencies
>>>
>>> Does the feature depend on any code or APIs outside the Chromium open
>>> source repository and its open-source dependencies to function?
>>> This feature does not depend on anything outside of chromium.
>>>
>>> Sample linkshttps://output.jsbin.com/buquher
>>>
>>> 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

[blink-dev] Re: Intent to Ship: The Popover API

[Mason Freed]

On Mon, Mar 20, 2023 at 1:19 AM Noam Rosenthal 
wrote:

> Voicing some concern about this API that I've raised before, and perhaps
> I'm reading this wrong and it was addressed.
> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
> worked on popups for wikipedia).
> This HTML is usually sanitized to remove potentially malicious tags
> 

Re: [blink-dev] Intent to Ship: font-variant-alternates and the @font-feature-values at-rule

[Šime Vidas]

Could you also update MDN’s browser compat data? It still says that Chrome 
does not support things like styleset(). See 
https://caniuse.com/?search=font-variant-

On Wednesday, December 7, 2022 at 4:47:55 PM UTC+1 yoav...@chromium.org 
wrote:

> LGTM3
>
> On Wed, Dec 7, 2022 at 4:44 PM Chris Harrelson  
> wrote:
>
>> LGTM2
>>
>> On Wed, Dec 7, 2022, 7:41 AM Philip Jägenstedt  
>> wrote:
>>
>>> LGTM1, I'm very happy to see this ship. I tried out 
>>> https://roettsch.es/montecarlo.html in Firefox and Safari, and those 
>>> are some very swishy swashes, looking forward to that demo also working in 
>>> Chrome :)
>>>
>>> And the tests are here:
>>>
>>> https://wpt.fyi/results/css/css-fonts?label=master=experimental=font-variant-alternates
>>>
>>> On Wed, Dec 7, 2022 at 3:50 PM Dominik Röttsches  
>>> wrote:
>>>
 Contact emailsdr...@chromium.org

 Explainer / Specification
 https://drafts.csswg.org/css-fonts-4/#font-variant-alternates-prop
 (This section contains details examples including images on how this 
 feature enables easier activation of font features.)

 Summary

 font-variant-alternates enables simpler access to glyph alternates in 
 fonts such as swashes, character-variants, ornaments and more. It provides 
 an easier method over having to use 4-letter-codes (e.g. 'swsh', 
 'cv01'...) 
 as arguments to font-feature-settings. font-variant-alternates refers 
 to the @font-feature-values at-rule to map speaking feature names to 
 OpenType feature numbers. In the font-variant-alternates style rule, 
 the requested feature activation becomes easy to use and to read and 
 allows 
 flexible combination of font features. 


 *Motivation*

 As *part of Interop 2022* we committed to supporting 
 font-variant-alternates and @font-feature-values in order to reach parity 
 with Firefox and Safari on this aspect of OpenType feature selection 
 through CSS. 


 The ergonomics of font-variant-alternates are better than having to 
 know OpenType feature codes and passing them to font-feature-settings.


 Blink componentBlink>Fonts 
 

 TAG reviewShipping in two browsers for a long time.

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 Low, extensively tested in WPT, shipped in Firefox and Safari. 


 *Gecko*: Shipped/Shipping (
 https://caniuse.com/?search=font-variant-alternates) Shipped in 
 Firefox since 34.

 *WebKit*: Shipped/Shipping (
 https://caniuse.com/?search=font-variant-alternates) Shipped in Safari 
 since 9.1

 *Web developers*: Web developers opinions were taken into account in 
 the interop 2022 process - so I'd tend to say the fact it's part of 
 Interop 
 2022 indicates: "positive".

 *Other signals*: https://wpt.fyi/interop-2022 - 
 font-variant-alternates amounts to 16% improvement in the Fonts and 
 Typography Category of Interop 2022, about ~1% of the total score.

 Ergonomics

 This feature provides an ergonomics improvement over 
 font-feature-settings.


 Activation

 Developers can immediately benefit from this feature when they write 
 their own @font-feature-values mappings to font features, based on the 
 font's documentation or tools such as https://wakamaifondue.com/. On 
 top of that, if the font foundry provides a @font-feature-values block, it 
 becomes even easier to activate font features.


 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?



 Debuggability

 The font-variant-alternates property is debugged through DevTools as 
 usual. This way parsing issues or invalid values can be detected. There's 
 no extra support for the @font-feature-values rule. 

 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 nameAtm available behind experimental web platform features (sson 
 in Canary, from 12/8/22)

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/716567

 Sample linkshttps://roettsch.es/montecarlo.html

 Estimated milestones

 110

 Anticipated spec changes

 None

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

 -- 
 You received this message because you are subscribed to 

[blink-dev] Intent to deprecate forwarding of mdoc-scheme URLs as Android Intents

['Adam Langley' via blink-dev]

*Primary eng emails*

a...@chromium.org, rby...@chromium.org

*Summary*

Creating a dedicated secure browser API for mdoc selection to replace
mdoc-scheme URLs on Chrome and Android.

*Motivation*

Last month, we sent

an intent to prototype for a more secure browser API for mdoc
 selection, which we
believe will more safely enable mobile driver’s licenses on the web across
multiple wallets. In addition to allowing sites to request real-world
identity information for opening a bank account, for example, this
dedicated API will also provide users with more transparency and control
into what personal information is then shared with the website requesting
it.

As prototyping of the new API begins, we are considering blocking the URI
schemes mdoc and mdoc-openid4vp from being forwarded directly to the OS
(e.g. as Intents on Android). These schemes have been proposed as a way to
use Chromium's support for websites opening complementary apps, to instead
open and communicate directly with arbitrary wallet apps. We believe this
mechanism is more prone to security risks for consumers, such as phishing
attacks, by not providing enough information to the browser to be able to
explain the request to the user, and that it prevents the operating system
from mediating such requests.

For similar reasons, Android is exploring a complementary, API-based
solution, instead of supporting the URL schemes mentioned above.

Like all Chromium projects, the new API will be developed in the open and
we’ll be engaging with the developers, regulators, and industry groups for
feedback.

We are collecting feedback and metrics on this deprecation plan and will
follow up with a bug and feature dashboard entry when pertinent.

-- 
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/CAL9PXLycoChNiZAMB33jVCe%3DUvdrFAYkQ%3DiKH%2BXqPK-bgS2VEA%40mail.gmail.com.

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

[Mike Taylor]

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/56a38fd0-a18c-0767-8706-5072f693c945%40chromium.org.

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

[Mike Taylor]

LGTM to experiment in canary/dev. For clarity, how long do you plan to 
experiment?


(I don't think you need an LGTM in this case, 
https://www.chromium.org/blink/launching-features/#origin-trials 
mentions needing an LGTM to experiment on beta or stable - but thanks 
for sending the intent!).


On 3/20/23 10:16 AM, Jiacheng Guo wrote:

The spec says:
User agents may copy entries from one |Document 
| object's 
list of available images 
 to 
another at any time
I believe the change is in line with the spec. It makes this behavior 
more frequent. The spec does not define behavior for other resources 
for now. The other involved resource types are stylesheet, fonts and 
scripts. It would be desirable to add a description about MemoryCache 
for these resources in the spec and allow cross-document reusing. For 
now I believe it is acceptable to launch the experiment in dev and canary.


We plan to launch the experiment in dev and canary in April. There are 
concerns about the memory footprint increase introduced by the change 
so we decide to hold the experiment in beta or stable. The experiment 
will provide data for the tradeoff between memory consumption and load 
speed. If the experiments in dev and canary show a positive impact on 
page loading metrics, we plan to refine the resource saving strategy 
and launch with the new implementation.


On Mon, Mar 20, 2023 at 10:49 PM Mike Taylor  
wrote:


What are the desired timelines for the experiments?

The design doc mentions only testing in dev and canary - do you
plan to eventually experiment in beta or stable?

On 3/17/23 2:08 PM, 'Jiacheng Guo' via blink-dev wrote:



Contact emails

g...@google.com


Explainer


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


Specification

The feature is not web-spec related.


Design docs



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


Summary

To measure the impact of garbage collection on Blink memory cache
and potential performance boost, we plan to keep strong
references to loaded resources in the Blink memory cache. The
change will serve as an estimation only project to collect data
about the maximal cache hit rate with all resources available.



Blink component

Blink>Loader




TAG review


TAG review is not required since the experiment changes the
internal behavior of renderer and is transparent to the websites
and web developers.


Risks



Interoperability and Compatibility


Resource reference lifetime does not affect the behavior of the
browser. We do not expect there to be interoperability or
compatibility issues.

/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

The change does not modify the behavior of web APIs


Goals for experimentation

The four configurations will be launched on dev/canary. The
combinations are: * The control group. No strong reference to
resources. * Save strong references for all resources of all
types for all the pages. * Save strong references for only
script, fonts and stylesheets for all pages. * Save strong
references for all resources for only one page. * Save strong
references for only script, fonts and stylesheets for only one
page. We will evaluate the following metrics under different
configurations * Core web browsing metric (FCP/LCP etc) * Cache
hit rate: Blink.MemoryCache.RevalidationPolicy * Memory footprint
* Crash Rate



Reason this experiment is being extended



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, resource reference lifetime in blink is invisible to the
websites.


Flag name

MemoryCacheStrongReference for the overall configuration.
MemoryCacheStrongReferenceSingleUnload and
MemoryCacheStrongReferenceFilterImages for sub configurations


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1409349


Estimated milestones

The feature is for experiment only. We do not expect to launch it
to stable as it is. If the experiment 

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

['Steven Valdez' via blink-dev]

The larger differences between privacypass and PST include some of the
token versions that we are currently using and that privacypass supports.
Even once the core drafts get standardized (which may still be months out)
we'll need to update drafts for the token types we're using in PST and get
those standardized. We're hoping to get a list of the differences between
the current draft of privacypass and PST out in the explainer repository,
though that has been delayed a bit getting the spec document and other I2S
requirements sorted out.



On Mon, Mar 20, 2023 at 4:30 AM Mike West  wrote:

> Thanks.
>
>
> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md#privacypass-version
> suggests that the privacypass versioning concern that Apple raised in
> https://github.com/WebKit/standards-positions/issues/72#issuecomment-1279177030
> will be mitigated through the protocol solidifying nowish, followed by
> y'all updating the private state tokens to match. Given
> https://datatracker.ietf.org/wg/privacypass/documents/, it looks like
> things are generally stable and proceeding to WG last call. Have y'all
> considered adopting the final version of the protocol prior to shipping?
> That would avoid the necessity of a future migration, and remove one avenue
> of objection others might have.
>
> Regarding Mozilla, they deferred judgement on both this API and
> privacypass (https://github.com/mozilla/standards-positions/issues/261)
> in 2020. Pinging those threads might be helpful in soliciting an opinion
> that takes the last 2+ years into account. :)
>
> -mike
>
>
> On Fri, Mar 17, 2023 at 8:29 PM Steven Valdez  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 <
>> blink-dev@chromium.org> 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 cross-site identification by
 limiting the amount of information stored in a token. Blind signatures
 prevent the issuer from linking a token redemption to the identity of the
 user in the issuance context.

 Private State Token API does not generate or define anti-fraud signals.
 This is up to the corresponding first party and the token issuers. The API
 enforces limits on the information transferred in these signals for privacy
 concerns. Private State Token API is based on the Privacy Pass
 protocol from the IETF working group
 . It can be
 considered as a web-exposed form of the Privacy Pass protocols.

 The Private State Token API was formerly known as the Trust Token API.
 It is renamed to more accurately reflect its functionality.

 Blink component

 Internals>Network>TrustTokens

 NB: As a part of the process of renaming the Trust Token API to the
 Private State Token API, the blink component will also be renamed.


 TAG review

 https://github.com/w3ctag/design-reviews/issues/414
 https://github.com/w3ctag/design-reviews/issues/780

 TAG review status

 No concerns, aside from lack of clear interest from other browsers

 Risks

 Interoperability and Compatibility

 We intend to update the 

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

['Jiacheng Guo' via blink-dev]

The spec says:
User agents may copy entries from one Document
 object's list of
available images

to
another at any time
I believe the change is in line with the spec. It makes this behavior more
frequent. The spec does not define behavior for other resources for now.
The other involved resource types are stylesheet, fonts and scripts. It
would be desirable to add a description about MemoryCache for these
resources in the spec and allow cross-document reusing. For now I believe
it is acceptable to launch the experiment in dev and canary.

We plan to launch the experiment in dev and canary in April. There are
concerns about the memory footprint increase introduced by the change so we
decide to hold the experiment in beta or stable. The experiment will
provide data for the tradeoff between memory consumption and load speed. If
the experiments in dev and canary show a positive impact on page loading
metrics, we plan to refine the resource saving strategy and launch with the
new implementation.

On Mon, Mar 20, 2023 at 10:49 PM Mike Taylor  wrote:

> What are the desired timelines for the experiments?
>
> The design doc mentions only testing in dev and canary - do you plan to
> eventually experiment in beta or stable?
> On 3/17/23 2:08 PM, 'Jiacheng Guo' via blink-dev wrote:
>
> Contact emails g...@google.com
>
> Explainer
> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>
> Specification The feature is not web-spec related.
>
> Design docs
>
> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>
> Summary
>
> To measure the impact of garbage collection on Blink memory cache and
> potential performance boost, we plan to keep strong references to loaded
> resources in the Blink memory cache. The change will serve as an estimation
> only project to collect data about the maximal cache hit rate with all
> resources available.
>
>
> Blink component Blink>Loader
> 
>
> TAG review
> TAG review is not required since the experiment changes the internal
> behavior of renderer and is transparent to the websites and web developers.
>
> Risks
>
>
> Interoperability and Compatibility
>
> Resource reference lifetime does not affect the behavior of the browser.
> We do not expect there to be interoperability or compatibility issues.
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> The change does not modify the behavior of web APIs
>
> Goals for experimentation
>
> The four configurations will be launched on dev/canary. The combinations
> are: * The control group. No strong reference to resources. * Save strong
> references for all resources of all types for all the pages. * Save strong
> references for only script, fonts and stylesheets for all pages. * Save
> strong references for all resources for only one page. * Save strong
> references for only script, fonts and stylesheets for only one page. We
> will evaluate the following metrics under different configurations * Core
> web browsing metric (FCP/LCP etc) * Cache hit rate:
> Blink.MemoryCache.RevalidationPolicy * Memory footprint * Crash Rate
>
>
> Reason this experiment is being extended
>
> 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, resource reference lifetime in blink is invisible to the websites.
>
> Flag name MemoryCacheStrongReference for the overall configuration.
> MemoryCacheStrongReferenceSingleUnload and
> MemoryCacheStrongReferenceFilterImages for sub configurations
>
> Requires code in //chrome? False
>
> Tracking bug https://crbug.com/1409349
>
> Estimated milestones
>
> The feature is for experiment only. We do not expect to launch it to
> stable as it is. If the experiment provides positive results, we will move
> on to further refine the resource lifetime management strategy in Blink.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5196823129489408
>
> 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/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%40mail.gmail.com
> 

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

[Mike Taylor]

What are the desired timelines for the experiments?

The design doc mentions only testing in dev and canary - do you plan to 
eventually experiment in beta or stable?


On 3/17/23 2:08 PM, 'Jiacheng Guo' via blink-dev wrote:



Contact emails

g...@google.com


Explainer

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


Specification

The feature is not web-spec related.


Design docs


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


Summary

To measure the impact of garbage collection on Blink memory cache and 
potential performance boost, we plan to keep strong references to 
loaded resources in the Blink memory cache. The change will serve as 
an estimation only project to collect data about the maximal cache hit 
rate with all resources available.




Blink component

Blink>Loader 




TAG review


TAG review is not required since the experiment changes the internal 
behavior of renderer and is transparent to the websites and web 
developers.



Risks



Interoperability and Compatibility


Resource reference lifetime does not affect the behavior of the 
browser. We do not expect there to be interoperability or 
compatibility issues.


/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


WebView application risks

The change does not modify the behavior of web APIs


Goals for experimentation

The four configurations will be launched on dev/canary. The 
combinations are: * The control group. No strong reference to 
resources. * Save strong references for all resources of all types for 
all the pages. * Save strong references for only script, fonts and 
stylesheets for all pages. * Save strong references for all resources 
for only one page. * Save strong references for only script, fonts and 
stylesheets for only one page. We will evaluate the following metrics 
under different configurations * Core web browsing metric (FCP/LCP 
etc) * Cache hit rate: Blink.MemoryCache.RevalidationPolicy * Memory 
footprint * Crash Rate




Reason this experiment is being extended



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, resource reference lifetime in blink is invisible to the websites.


Flag name

MemoryCacheStrongReference for the overall configuration. 
MemoryCacheStrongReferenceSingleUnload and 
MemoryCacheStrongReferenceFilterImages for sub configurations



Requires code in //chrome?

False


Tracking bug

https://crbug.com/1409349


Estimated milestones

The feature is for experiment only. We do not expect to launch it to 
stable as it is. If the experiment provides positive results, we will 
move on to further refine the resource lifetime management strategy in 
Blink.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5196823129489408

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/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%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/cbae85cf-ec02-77bd-7ce3-059212ccb6c2%40chromium.org.

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

[Noam Rosenthal]

On Mon, Mar 20, 2023 at 11:47 AM Yoav Weiss  wrote:

> Thanks for sending the intent and for experimenting with the MemoryCache!
>
> On Fri, Mar 17, 2023 at 7:08 PM 'Jiacheng Guo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails...@google.com
>>
>> Explainer
>> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>>
>> SpecificationThe feature is not web-spec related.
>>
>
> The situation as I remember it is a bit more complex than that :)
> I think the memory cache is defined for images
> ,
> but not for other resource types.
> So if we end up changing the behavior for images, it'd be good to see if
> we can reflect that behavior change in the spec.
> And ideally, it'd be great if we're able to actually specify the behavior
> of the memory cache once we figure out where we want it to land, as I
> believe it is observable. (Through ResourceTiming, as well as timing in
> general).
>

See spec meta-bug for context: https://github.com/whatwg/html/issues/6110
There are lots of existing interop issues around memory cache, we should
try to make things better there (or at least not make them worse...)
interoperability-wise.

-- 
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/CAJn%3DMYarzcCbJK5e5WYeeEM-QcMqF8-BbvbX%2BQ800zr-H8g2Bw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: The Popover API

[Noam Rosenthal]

https://github.com/apostrophecms/sanitize-html for example is allow-list by
default but can be configurable to work as a block-list.

This is hypothetically a problem for any new HTML attribute, however with
this particular one we break a very old CSS contract (stacking/overflow
contexts are only esacapable by JS).

On Mon, Mar 20, 2023 at 12:26 PM Philip Jägenstedt 
wrote:

> Hi Noam,
>
> Do you know if these sanitizers generally work as allowlists or
> blocklists? In other words, will the new popover attribute be allowed
> through current versions of those sanitizers?
>
> Best regards,
> Philip
>
> On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal 
> wrote:
>
>> Voicing some concern about this API that I've raised before, and perhaps
>> I'm reading this wrong and it was addressed.
>> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
>> worked on popups for wikipedia).
>> This HTML is usually sanitized to remove potentially malicious tags
>> 

Re: [blink-dev] Re: Intent to Ship: The Popover API

['Jake Archibald' via blink-dev]

DOMPurify  seems to block the popover
attribute, and I don't see any code for handling it specifically, so I
assume it's not on an allowlist.

On Mon, Mar 20, 2023 at 10:26 AM Philip Jägenstedt 
wrote:

> Hi Noam,
>
> Do you know if these sanitizers generally work as allowlists or
> blocklists? In other words, will the new popover attribute be allowed
> through current versions of those sanitizers?
>
> Best regards,
> Philip
>
> On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal 
> wrote:
>
>> Voicing some concern about this API that I've raised before, and perhaps
>> I'm reading this wrong and it was addressed.
>> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
>> worked on popups for wikipedia).
>> This HTML is usually sanitized to remove potentially malicious tags
>> 

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

['Jiacheng Guo' via blink-dev]

In the "for all the pages" scenario, we will keep strong references for the
resources for five minutes when each page unloads.
In the "only one page" scenario, when a page unloads, it will override the
saved strong references.

The UMA "Blink.MemoryCache.CrossDocumentCachedResource2" records how many
resources are reused among different documents. We will compare this metric
between the control group and the experiments.

On Mon, Mar 20, 2023 at 6:47 PM Yoav Weiss  wrote:

> Thanks for sending the intent and for experimenting with the MemoryCache!
>
> On Fri, Mar 17, 2023 at 7:08 PM 'Jiacheng Guo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails...@google.com
>>
>> Explainer
>> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>>
>> SpecificationThe feature is not web-spec related.
>>
>
> The situation as I remember it is a bit more complex than that :)
> I think the memory cache is defined for images
> ,
> but not for other resource types.
> So if we end up changing the behavior for images, it'd be good to see if
> we can reflect that behavior change in the spec.
> And ideally, it'd be great if we're able to actually specify the behavior
> of the memory cache once we figure out where we want it to land, as I
> believe it is observable. (Through ResourceTiming, as well as timing in
> general).
>
>
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>>
>> Summary
>>
>> To measure the impact of garbage collection on Blink memory cache and
>> potential performance boost, we plan to keep strong references to loaded
>> resources in the Blink memory cache. The change will serve as an estimation
>> only project to collect data about the maximal cache hit rate with all
>> resources available.
>>
>>
>> Blink componentBlink>Loader
>> 
>>
>> TAG review
>> TAG review is not required since the experiment changes the internal
>> behavior of renderer and is transparent to the websites and web developers.
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>> Resource reference lifetime does not affect the behavior of the browser.
>> We do not expect there to be interoperability or compatibility issues.
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> The change does not modify the behavior of web APIs
>>
>> Goals for experimentation
>>
>> The four configurations will be launched on dev/canary. The combinations
>> are: * The control group. No strong reference to resources. * Save strong
>> references for all resources of all types for all the pages. * Save strong
>> references for only script, fonts and stylesheets for all pages. * Save
>> strong references for all resources for only one page. * Save strong
>> references for only script, fonts and stylesheets for only one page.
>>
>
> Can you explain the differences between the "for all the pages" and the
> "only one page" variants?
>
>
>> We will evaluate the following metrics under different configurations *
>> Core web browsing metric (FCP/LCP etc) * Cache hit rate:
>> Blink.MemoryCache.RevalidationPolicy
>>
>
> Could we also count how many resources are no longer loaded over the
> network? (so are now a MemoryCache HIT that were formerly an HTTP cache
> MISS)
>
>
>> * Memory footprint * Crash Rate
>>
>>
>> Reason this experiment is being extended
>>
>>
>>
>> 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, resource reference lifetime in blink is invisible to the websites.
>>
>> Flag nameMemoryCacheStrongReference for the overall configuration.
>> MemoryCacheStrongReferenceSingleUnload and
>> MemoryCacheStrongReferenceFilterImages for sub configurations
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1409349
>>
>> Estimated milestones
>>
>> The feature is for experiment only. We do not expect to launch it to
>> stable as it is. If the experiment provides positive results, we will move
>> on to further refine the resource lifetime management strategy in Blink.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5196823129489408
>>
>> 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 

Re: [blink-dev] Re: Intent to Ship: The Popover API

[Philip Jägenstedt]

Hi Noam,

Do you know if these sanitizers generally work as allowlists or blocklists?
In other words, will the new popover attribute be allowed through current
versions of those sanitizers?

Best regards,
Philip

On Mon, Mar 20, 2023 at 9:19 AM Noam Rosenthal 
wrote:

> Voicing some concern about this API that I've raised before, and perhaps
> I'm reading this wrong and it was addressed.
> Think of CMS-style sites that embed user-generated HTML, like Wikis (I
> worked on popups for wikipedia).
> This HTML is usually sanitized to remove potentially malicious tags
> 

Re: [blink-dev] Intent to Prototype: CSS font-palette property animation

[Philip Jägenstedt]

Hi Munira,

Do you think this will require any changes to DevTools for debuggability?
There's a checklist at https://goo.gle/devtools-checklist, where the key
question is "how would a web developer making use of your new WPF test and
debug their code?"

Best regards,
Philip

On Mon, Mar 20, 2023 at 10:14 AM Yoav Weiss  wrote:

> Thanks for working on less-blinky color transitions for fonts! :)
>
> On Mon, Mar 20, 2023 at 9:58 AM 'Munira Tursunova' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> moon...@google.com, dr...@google.com
>>
>> Explainer
>>
>>
>> https://docs.google.com/document/d/1XMTrKH003KBOes6hxzI-3E7LTwp5YwFC-rnzoFpFrfw/edit?usp=sharing
>>
>> Specification
>>
>> Will be written as a part of the implementation.
>>
>> Summary
>>
>> The CSS font-palette property allows selection of a specific palette used
>> to render a font. The CSS Fonts 4 spec defines the animation behavior of
>> this property as discrete, which is insufficient to achieve a smooth
>> transition between two selected palettes. Creating the smooth transition
>> between the palettes is rather difficult to achieve if the property is not
>> interpolatable, web authors would need to manually compute the value for
>> each frame in order to achieve that.
>>
>> Blink component
>>
>> Blink>Fonts
>> 
>>
>> Motivation
>>
>> Color fonts have vastly improved typographic expressiveness on the web.
>> They provide web authors with a variety of new features, like defining the
>> palette of the font, that will allow them to style glyph appearance
>> flexibly, on top of what’s pre-defined by the font. Currently the animation
>> type of the font-palette property is discrete, meaning that there is no
>> smooth transition between the different color values of the font. The only
>> way to animate the font-palette property smoothly is by doing it manually,
>> which is rather complicated: in order for animation to work, web authors
>> need to retrieve information about color records from the font and compute
>> font-palette values for each frame.
>>
>> Defining animation behavior for the CSS font-palette property solves this
>> by enabling a declarative CSS way of achieving a smooth transition. This
>> feature will provide web authors with an easy way to have a smooth
>> transition between font-palette values.
>>
>> Initial public proposal
>>
>> We plan to raise this as an issue for the CSS Fonts spec in the CSS WG
>> once we gain more insights from prototyping.
>>
>> Search tags
>>
>> font-palette ,
>> animation , transition
>> , font-palette-values
>> , color fonts
>> 
>>
>> TAG review
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Probably positive, since they implemented color fonts, font-palette
>>
>
> Let's not assume their position, but file to ask for it when the time is
> right.
>
>
>>
>> Web developers: Positive
>>
>> Ollie Williams expressed his interest in this CSS Tricks post
>> ,
>> describing it as a dream if that feature was real.
>>
>> Scott Kellum (of typetura.com) has also been suggesting it as a useful
>> feature for the web (origin: a Twitter thread and email conversation, the
>> original twitter post was deleted).
>>
>> Other signals:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None expected
>>
>>
>> Debuggability
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Not yet, but tests will be written as part of the implementation.
>>
>> Flag name
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1400620
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5177171439517696
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group 

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

[Yoav Weiss]

Thanks for sending the intent and for experimenting with the MemoryCache!

On Fri, Mar 17, 2023 at 7:08 PM 'Jiacheng Guo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails...@google.com
>
> Explainer
> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>
> SpecificationThe feature is not web-spec related.
>

The situation as I remember it is a bit more complex than that :)
I think the memory cache is defined for images
, but
not for other resource types.
So if we end up changing the behavior for images, it'd be good to see if we
can reflect that behavior change in the spec.
And ideally, it'd be great if we're able to actually specify the behavior
of the memory cache once we figure out where we want it to land, as I
believe it is observable. (Through ResourceTiming, as well as timing in
general).


>
> Design docs
>
> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>
> Summary
>
> To measure the impact of garbage collection on Blink memory cache and
> potential performance boost, we plan to keep strong references to loaded
> resources in the Blink memory cache. The change will serve as an estimation
> only project to collect data about the maximal cache hit rate with all
> resources available.
>
>
> Blink componentBlink>Loader
> 
>
> TAG review
> TAG review is not required since the experiment changes the internal
> behavior of renderer and is transparent to the websites and web developers.
>
> Risks
>
>
> Interoperability and Compatibility
>
>
> Resource reference lifetime does not affect the behavior of the browser.
> We do not expect there to be interoperability or compatibility issues.
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> The change does not modify the behavior of web APIs
>
> Goals for experimentation
>
> The four configurations will be launched on dev/canary. The combinations
> are: * The control group. No strong reference to resources. * Save strong
> references for all resources of all types for all the pages. * Save strong
> references for only script, fonts and stylesheets for all pages. * Save
> strong references for all resources for only one page. * Save strong
> references for only script, fonts and stylesheets for only one page.
>

Can you explain the differences between the "for all the pages" and the
"only one page" variants?


> We will evaluate the following metrics under different configurations *
> Core web browsing metric (FCP/LCP etc) * Cache hit rate:
> Blink.MemoryCache.RevalidationPolicy
>

Could we also count how many resources are no longer loaded over the
network? (so are now a MemoryCache HIT that were formerly an HTTP cache
MISS)


> * Memory footprint * Crash Rate
>
>
> Reason this experiment is being extended
>
>
>
> 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, resource reference lifetime in blink is invisible to the websites.
>
> Flag nameMemoryCacheStrongReference for the overall configuration.
> MemoryCacheStrongReferenceSingleUnload and
> MemoryCacheStrongReferenceFilterImages for sub configurations
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1409349
>
> Estimated milestones
>
> The feature is for experiment only. We do not expect to launch it to
> stable as it is. If the experiment provides positive results, we will move
> on to further refine the resource lifetime management strategy in Blink.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5196823129489408
>
> 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/CAJQw1NwNzokqhvwtnrV-J-8BeMeRjfC-cvkXMBmZYK4Vej%3DX%2Bg%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 

Re: [blink-dev] Intent to Prototype: CSS font-palette property animation

[Yoav Weiss]

Thanks for working on less-blinky color transitions for fonts! :)

On Mon, Mar 20, 2023 at 9:58 AM 'Munira Tursunova' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> moon...@google.com, dr...@google.com
>
> Explainer
>
>
> https://docs.google.com/document/d/1XMTrKH003KBOes6hxzI-3E7LTwp5YwFC-rnzoFpFrfw/edit?usp=sharing
>
> Specification
>
> Will be written as a part of the implementation.
>
> Summary
>
> The CSS font-palette property allows selection of a specific palette used
> to render a font. The CSS Fonts 4 spec defines the animation behavior of
> this property as discrete, which is insufficient to achieve a smooth
> transition between two selected palettes. Creating the smooth transition
> between the palettes is rather difficult to achieve if the property is not
> interpolatable, web authors would need to manually compute the value for
> each frame in order to achieve that.
>
> Blink component
>
> Blink>Fonts
> 
>
> Motivation
>
> Color fonts have vastly improved typographic expressiveness on the web.
> They provide web authors with a variety of new features, like defining the
> palette of the font, that will allow them to style glyph appearance
> flexibly, on top of what’s pre-defined by the font. Currently the animation
> type of the font-palette property is discrete, meaning that there is no
> smooth transition between the different color values of the font. The only
> way to animate the font-palette property smoothly is by doing it manually,
> which is rather complicated: in order for animation to work, web authors
> need to retrieve information about color records from the font and compute
> font-palette values for each frame.
>
> Defining animation behavior for the CSS font-palette property solves this
> by enabling a declarative CSS way of achieving a smooth transition. This
> feature will provide web authors with an easy way to have a smooth
> transition between font-palette values.
>
> Initial public proposal
>
> We plan to raise this as an issue for the CSS Fonts spec in the CSS WG
> once we gain more insights from prototyping.
>
> Search tags
>
> font-palette ,
> animation , transition
> , font-palette-values
> , color fonts
> 
>
> TAG review
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: No signal
>
> WebKit: No signal
>
> Probably positive, since they implemented color fonts, font-palette
>

Let's not assume their position, but file to ask for it when the time is
right.


>
> Web developers: Positive
>
> Ollie Williams expressed his interest in this CSS Tricks post
> ,
> describing it as a dream if that feature was real.
>
> Scott Kellum (of typetura.com) has also been suggesting it as a useful
> feature for the web (origin: a Twitter thread and email conversation, the
> original twitter post was deleted).
>
> Other signals:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None expected
>
>
> Debuggability
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Not yet, but tests will be written as part of the implementation.
>
> Flag name
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1400620
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5177171439517696
>
> --
> 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/CAAO7W_DFvgY9yqz_Tr%2B2sHMwsydbWMQ66yZWwF7ZoxDZ2yE1QA%40mail.gmail.com
> 
> .
>

-- 
You received this message 

Re: [blink-dev] Re: Intent to Ship: Display and content-visibility animations

[Yoav Weiss]

On Wed, Mar 15, 2023 at 11:09 PM Joey Arhar  wrote:

> TAG review: https://github.com/w3ctag/design-reviews/issues/824
> WebKit standards position:
> https://github.com/WebKit/standards-positions/issues/147
> Mozilla standards position:
> https://github.com/mozilla/standards-positions/issues/762
>
> On Wed, Mar 15, 2023 at 1:37 PM Joey Arhar  wrote:
>
>> Contact emailsfla...@chromium.org, jar...@chromium.org
>>
>> Explainer
>> https://github.com/w3c/csswg-drafts/issues/6429#issuecomment-1318933547
>>
>> Specificationhttps://drafts.csswg.org/css-display-4/#display-animation
>>
>> Summary
>>
>> Support specifying display and content-visibility in animations. This
>> support allows for developers to create exit animations after which the
>> element automatically becomes display: none or content-visibility: hidden
>> without needing to write any javascript to handle that switch after the
>> animation is finished. This allows exit animations for elements to be added
>> purely in CSS.
>>
>>
>> Blink componentBlink>Animation
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Developers may have display specified in existing animations which would
>> start being included in their animation after this change.
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Positive (
>> https://front-end.social/@mia/109433817951030826)
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This will be used in tandem with popover/dialog elements and the
>> CSSTransitionDiscrete feature. Usage of this feature will not make it hard
>> for chrome to maintain good performance.
>>
>>
>> Activation
>>
>> It will not be challenging for developers to use this feature immediately.
>>
>
How do we expect developers to use the feature before it is
ubiquitously available?
Do we expect them to perform feature detection and compensate for it in JS?
Something else? What would that look like?


>>
>> Security
>>
>> This doesn't extend developer capabilities beyond styles the developer
>> could set via existing CSS or scripts.
>>
>>
>> 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?
>>
>> This is not high risk for WebView, but is controlled by a base::Feature
>> anyway.
>>
>>
>> Debuggability
>>
>> This feature extends the capabilities of existing css animations, css
>> transitions and web animations and will show amongst other developer
>> animations.
>>
>>
>> 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 nameCSSDisplayAnimation
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1395394
>>
>> MeasurementThis feature does not have any UseCounters.
>>
>> Availability expectationI'm not sure when this will be implemented in
>> safari and firefox. I don't think that they have started implementing this
>> yet, but we only very recently got this resolved in CSSWG.
>>
>> Adoption expectationThis will be the best practice for animating the
>> entry and exit if dialogs and popovers immediately.
>>
>> Adoption planI don't have an adoption plan.
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>> This feature does not depend on anything outside of chromium.
>>
>> Sample linkshttps://output.jsbin.com/buquher
>>
>> 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).
>> This change has been specced and I don't think any more changes to the
>> spec will happen.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5154958272364544
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMCg_NwX3apO7K2t%3DauPVKXWwF9B2RHbkE6yfjCNc8a1w%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 

[blink-dev] Intent to Prototype: CSS font-palette property animation

['Munira Tursunova' via blink-dev]

Contact emails

moon...@google.com, dr...@google.com

Explainer

https://docs.google.com/document/d/1XMTrKH003KBOes6hxzI-3E7LTwp5YwFC-rnzoFpFrfw/edit?usp=sharing

Specification

Will be written as a part of the implementation.

Summary

The CSS font-palette property allows selection of a specific palette used
to render a font. The CSS Fonts 4 spec defines the animation behavior of
this property as discrete, which is insufficient to achieve a smooth
transition between two selected palettes. Creating the smooth transition
between the palettes is rather difficult to achieve if the property is not
interpolatable, web authors would need to manually compute the value for
each frame in order to achieve that.

Blink component

Blink>Fonts


Motivation

Color fonts have vastly improved typographic expressiveness on the web.
They provide web authors with a variety of new features, like defining the
palette of the font, that will allow them to style glyph appearance
flexibly, on top of what’s pre-defined by the font. Currently the animation
type of the font-palette property is discrete, meaning that there is no
smooth transition between the different color values of the font. The only
way to animate the font-palette property smoothly is by doing it manually,
which is rather complicated: in order for animation to work, web authors
need to retrieve information about color records from the font and compute
font-palette values for each frame.

Defining animation behavior for the CSS font-palette property solves this
by enabling a declarative CSS way of achieving a smooth transition. This
feature will provide web authors with an easy way to have a smooth
transition between font-palette values.

Initial public proposal

We plan to raise this as an issue for the CSS Fonts spec in the CSS WG once
we gain more insights from prototyping.

Search tags

font-palette ,
animation , transition
, font-palette-values
, color fonts


TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Probably positive, since they implemented color fonts, font-palette

Web developers: Positive

Ollie Williams expressed his interest in this CSS Tricks post
,
describing it as a dream if that feature was real.

Scott Kellum (of typetura.com) has also been suggesting it as a useful
feature for the web (origin: a Twitter thread and email conversation, the
original twitter post was deleted).

Other signals:

WebView application risks

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

None expected


Debuggability

Is this feature fully tested by web-platform-tests

?

Not yet, but tests will be written as part of the implementation.

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1400620

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177171439517696

-- 
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/CAAO7W_DFvgY9yqz_Tr%2B2sHMwsydbWMQ66yZWwF7ZoxDZ2yE1QA%40mail.gmail.com.

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

[Mike West]

Thanks.

https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md#privacypass-version
suggests that the privacypass versioning concern that Apple raised in
https://github.com/WebKit/standards-positions/issues/72#issuecomment-1279177030
will be mitigated through the protocol solidifying nowish, followed by
y'all updating the private state tokens to match. Given
https://datatracker.ietf.org/wg/privacypass/documents/, it looks like
things are generally stable and proceeding to WG last call. Have y'all
considered adopting the final version of the protocol prior to shipping?
That would avoid the necessity of a future migration, and remove one avenue
of objection others might have.

Regarding Mozilla, they deferred judgement on both this API and privacypass
(https://github.com/mozilla/standards-positions/issues/261) in 2020.
Pinging those threads might be helpful in soliciting an opinion that takes
the last 2+ years into account. :)

-mike


On Fri, Mar 17, 2023 at 8:29 PM Steven Valdez  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 <
> blink-dev@chromium.org> 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 cross-site identification by
>>> limiting the amount of information stored in a token. Blind signatures
>>> prevent the issuer from linking a token redemption to the identity of the
>>> user in the issuance context.
>>>
>>> Private State Token API does not generate or define anti-fraud signals.
>>> This is up to the corresponding first party and the token issuers. The API
>>> enforces limits on the information transferred in these signals for privacy
>>> concerns. Private State Token API is based on the Privacy Pass protocol
>>> from the IETF working group
>>> . It can be
>>> considered as a web-exposed form of the Privacy Pass protocols.
>>>
>>> The Private State Token API was formerly known as the Trust Token API.
>>> It is renamed to more accurately reflect its functionality.
>>>
>>> Blink component
>>>
>>> Internals>Network>TrustTokens
>>>
>>> NB: As a part of the process of renaming the Trust Token API to the
>>> Private State Token API, the blink component will also be renamed.
>>>
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/414
>>> https://github.com/w3ctag/design-reviews/issues/780
>>>
>>> TAG review status
>>>
>>> No concerns, aside from lack of clear interest from other browsers
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> We intend to update the underlying cryptographic and token issuance
>>> protocols to align with the eventual Privacy Pass standard. This will
>>> affect compatibility with the small number of token issuers. Private State
>>> Token API fetch requests include a token type and version field that
>>> enables backward compatibility while allowing possible extensions for
>>> future token types and versions. While we will have a standard
>>> deprecation path of supporting multiple versions, we expect this to be
>>> easier with this API as each issuer using this API will need to register to
>>> become an issuer and will provide contact information as part of that
>>> process.
>>>
>>>
>>> Gecko: Defer
>>> 

[blink-dev] Re: Intent to Ship: The Popover API

[Noam Rosenthal]

Voicing some concern about this API that I've raised before, and perhaps 
I'm reading this wrong and it was addressed.
Think of CMS-style sites that embed user-generated HTML, like Wikis (I 
worked on popups for wikipedia).
This HTML is usually sanitized to remove potentially malicious tags