[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Anton Bershanskyi]

Hi Grzegorz,

HTTP/2 server push was disabled by default in Chrome 106[1]. You can 
achieve the almost the same latency speedup via preloading and prerendering 
(rel=preload [2] and rel=prerender) and HTTP Early Hints[3] (supported 
since Chrome 103) and speculation rules.

[1] https://developer.chrome.com/blog/removing-push/
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload
[3] https://developer.chrome.com/blog/early-hints/

Hope that helps.
On Monday, October 16, 2023 at 1:41:53 AM UTC+3 Grzegorz Szeliga wrote:

> Is this function still active? I was just getting around to using it to 
> speed up my site and here I find such threads of concern
>
> czwartek, 27 kwietnia 2023 o 21:14:40 UTC+2 Gerald Witichis napisał(a):
>
>> The reason is if your website is fast you don't need to buy CDN and 
>> Akamai (and the like) looses money.
>> All this technical reasoning is false.
>> Also fake are the statistics about saying nobody uses push. How could 
>> Akamai actually know how much traffic my site does with push? They simply 
>> can't. The only thing they can count is the number of their customers. 
>> But most stupid is Googles reasoning to disable a working feature in 
>> Chrome based on statistics. They had a very strong reason to come up with 
>> spdy and push in the first place. Simply leaving the feature as it is would 
>> not cost them a dime. But since it does harm to the CDN business the world 
>> is not allowed to enjoy fast sites with push.
>> Oh the internet is slow I need a faster computer 
>> Also saying that because push is optional in http2, turning it off would 
>> leave Chrome HTTP/2 standard compliant is like saying a browser is HTTP/2 
>> compliant if it downgrades to http/1.0 and gets the page.
>> Push may be optional to use but it is THE killer feature of http2. Why 
>> should one use http2 insted? For header compression or binary - nope. With 
>> brotli or gzip there is already binary and why bother for a few headers.
>> But every end is a new beginning. I look forward to the push enabled 
>> forks of the browsers. 
>> Goodbye Chrome.  
>> On Thursday, November 12, 2020 at 6:13:08 AM UTC+1 Samuel Williams wrote:
>>
>>> As someone who has implemented HTTP/2 push in both the client and 
>>> server, I fully support this change and would like to see it deprecated 
>>> from the RFCs. The complexity in both the client and the server is 
>>> non-trivial, and the benefit has not been proven even in isolation.
>>>
>>> The HTTP request/response model is well understood and lends itself to 
>>> relatively sane client and server interfaces. The addition of server push 
>>> extends clients and servers in an unnatural way, where a response can can 
>>> potentially trigger more responses than the client was interested in. When 
>>> you try to write code that handles this, the only abstraction that comes to 
>>> mind is a queue:
>>>
>>> response = client.request(path)
>>> response.promises.each do |promise|
>>>   add_to_cache(promise)
>>> end
>>> response.body.read # etc
>>>
>>> But this is very unnatural to most users. Not to mention that this also 
>>> invites issues around concurrency.
>>>
>>> Browsers (and clients in general) are far better at knowing what 
>>> resources they need. My experience has been that HTTP/2 push can only helps 
>>> users on the first request. Looking at implementations like h2o, we see the 
>>> extreme level of complexity required to try and avoid superfluous pushing. 
>>> After the first request, the local browser has cached everything of 
>>> interest, and from that point on HTTP/2 push does not serve any purpose as 
>>> far as I can tell.
>>>
>>> The level of complexity introduced by this feature does not balance out 
>>> with the value it brings.
>>>
>>> To repeat, I fully support this change.
>>>
>>> Kind regards,
>>> Samuel
>>> On Thursday, November 12, 2020 at 3:26:20 PM UTC+13 Ian Swett wrote:
>>>
 Anyone who objects should feel free to share data publicly which 
 supports their case, as Akamai did a few years ago.  That data was very 
 mixed and not particularly compelling on average, and the metrics have 
 degraded since then, so I expect the metrics would look worse today.

 On Wed, Nov 11, 2020 at 9:22 PM Jay Phelps  wrote:

> We disagree with this decision based on the real world data we have 
> seen and the products we build around Http/2 Push. Just making our 
> objection known.
>
> --
> Jay Phelps
> Outsmartly
>
> On Wednesday, November 11, 2020 at 9:00:52 PM UTC-5 Ian Swett wrote:
>
>> To clarify, server push is an optimization in HTTP/2(and presumably 
>> HTTP/3) that is optional and there is no requirement to implement it in 
>> either spec.  It does not exist in HTTP/1.1.  This is not an indicatoin 
>> Chrome does not support HTTP(S), since clearly Chrome would be useless 
>> if 
>> that occurred, but rather about removing an optimiza

Re: [blink-dev] Intent to Experiment: Unrestricted access to performance.measureUserAgentSpecificMemory()

[Michael Lippautz]

On Fri, Oct 13, 2023 at 3:58 PM Michael Lippautz 
wrote:

> Thanks!
>
> On Fri, Oct 13, 2023 at 10:52 AM Yoav Weiss 
> wrote:
>
>> This is exciting! Thanks for working on this!!
>>
>> On Fri, Oct 13, 2023 at 10:42 AM Michael Lippautz 
>> wrote:
>>
>>> Contact emails
>>>
>>> v...@chromium.org, mlippa...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/performance-measure-memory
>>>
>>> Specification
>>>
>>> https://github.com/WICG/performance-measure-memory
>>>
>>> Design docs
>>>
>>> Original docs:
>>>
>>> https://web.dev/monitor-total-page-memory-usage
>>>
>>>
>>> https://github.com/WICG/performance-measure-memory/blob/master/ORIGIN_TRIAL.md
>>>
>>> Summary
>>>
>>> performance.measureUserAgentSpecificMemory() is specified to only be
>>> available in cross-origin isolated environments (behind COOP/COEP).
>>>
>>> This is a request for removing the COOP/COEP restriction for a limited
>>> amount of time from M120 to M121. This is to allow partners that adopted
>>> WasmGC on WebWorkers to perform regression tests in the wild as well as
>>> measure their impact. These partners are not fully ready to deploy
>>> COOP/COEP.
>>>
>>
>> Do you want to experiment with removing the API's restrictions generally
>> or to sites that opt-in to this? (Through an OT flag, I'm assuming)
>>
>
> We don't want this generally but through an OT for a limited time.
>
>
>>
>>> Note that performance.memory (legacy API) cannot be used for this
>>> purpose as it was never enabled on workers.
>>>
>>> The timeline has been adjusted to match the OT for SharedArrayBuffer on
>>> non-isolated pages.
>>>
>>
>> IIUC the restrictions on measureUASpecificMemory and SharedArrayBuffer
>> are similar but for different reasons. Would we have a separate OT token
>> for this?
>>
>
> We would want a separate OT token.  We already reached out to a few
> security folks which would want us to align the times and make it as short
> as possible (for good reasons). The unrestricted SAB OT also has issues
> with privacy which is why we should align the OT times.
>
>
>>
>>
>>>
>>> Blink component
>>>
>>> Blink>PerformanceAPIs
>>> 
>>>
>>> Search tags
>>>
>>> JavaScript memory
>>> ,
>>> crossOriginIsolated
>>> ,
>>> performance.measureMemory()
>>> 
>>>
>>> TAG review
>>>
>>> -
>>>
>>> TAG review status
>>>
>>> -
>>>
>>> Chromium Trial Name
>>>
>>> MeasureMemory
>>>
>>> Link to origin trial feedback summary
>>>
>>> -
>>>
>>> Origin Trial documentation link
>>>
>>> -
>>>
>>> Risks
>>>
>>> This area is unchanged from the original launch.
>>>
>>> Interoperability and Compatibility
>>>
>>> The actual memory usage of a web page is not comparable across browsers.
>>> The granularity of memory usage breakdown will differ across browsers.
>>>
>>>
>>> Gecko: Under consideration (
>>> https://github.com/mozilla/standards-positions/issues/281)
>>>
>>> WebKit: No signal (
>>> https://lists.webkit.org/pipermail/webkit-dev/2020-April/031160.html)
>>>
>>> Web developers: Positive (
>>> https://docs.google.com/document/d/1u21oa3-R1FhHgrPsh8-mpb8dIFVj60wcFiM5FFrfIQA/edit#heading=h.6si74uwp7sq8)
>>> Developers from Gmail, Google Docs/Slides/Sheet, Facebook, YouTube
>>> contributed use cases for a memory measurement API. The proposal was
>>> presented at WebPerf WG F2F June 2019 meeting with positive feedback from
>>> developers.
>>>
>>> Other signals:
>>>
>>> Ergonomics
>>>
>>> None
>>>
>>>
>>> Activation
>>>
>>> None
>>>
>>>
>>> Security
>>>
>>> The API relies on COOP and COEP for security. See
>>> https://github.com/ulan/performance-measure-memory#security-considerations
>>>
>>> This is the restriction that is supposed to be temporarily lifted.
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Goals for experimentation
>>>
>>> Allow partners to perform A/B testing when deploying relatively heavy
>>> applications on web workers.
>>>
>>> Ongoing technical constraints
>>>
>>> -
>>>
>>> Debuggability
>>>
>>> -
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No (unchanged)
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes
>>>
>>> Flag name on chrome://flags
>>>
>>> Finch feature name
>>>
>>> None
>>>
>>> Non-finch justification
>>>
>>> None
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> Bug for OT:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1486857
>>>
>>> https://bugs.chromium.org/

Re: [blink-dev] Intent to Experiment: 'priority' HTTP request header

[Patrick Meenan]

Issue has been filed  with the
whatwg spec to specify the behavior of the priority header, either by
adding it to the forbidden header list or by defining how the networking
layer should behave if there is an application-supplied value.

On Wed, Oct 11, 2023 at 12:12 PM Yoav Weiss  wrote:

> LGTM to experiment in 120
>
> On Wed, Oct 11, 2023 at 6:11 PM Patrick Meenan 
> wrote:
>
>> Sorry, forgot to mention the milestone - 120 for running the experiment.
>> The code is in place to run the experiment as of 119 but since it hasn't
>> run enabled in dev channel and 119 is in Beta now, the plan is to
>> experiment in 120.
>>
>> On Wed, Oct 11, 2023 at 11:04 AM Yoav Weiss 
>> wrote:
>>
>>> One last question: what milestones are you planning to run this
>>> experiment on?
>>>
>>> On Tuesday, October 10, 2023 at 7:02:51 PM UTC+2 Patrick Meenan wrote:
>>>
>>> On Tue, Oct 10, 2023 at 3:18 AM Yoav Weiss 
>>> wrote:
>>>
>>>
>>> Can you briefly describe what the header parts are good for, and how
>>> would developers use them?
>>>
>>>
>>> There are 2 parts to the header which is formatted as a structured-field
>>> dictionary (comma-separated entries with each entry being key=value.
>>>
>>> The 2 keys are:
>>> u (urgency )
>>> = numeric from 0 to 7 with 0 being the highest priority and 7 being the
>>> lowest (and 3 being the default).
>>> i (incremental
>>> ) =
>>> boolean to specify if the response should be interleaved with other
>>> responses of the same priority (defaults to disabled).
>>>
>>> e.g. "priority: u=1, i" would indicate a high priority request that
>>> allows for interleaving.
>>>
>>> I'm not expecting a lot of direct web developer use of it. It's more for
>>> the HTTP/2 and HTTP/3 servers to use to prioritize multiplexed responses
>>> and to align with Firefox and Safari for any servers that prefer to just
>>> use the headers for prioritization and not do the frame-level priorities
>>>
>>> So this will be sent in both H2 and H3?
>>>
>>>
>>> (which Chrome is the only browser to use for HTTP/3).
>>>
>>>
>>> Do you know why other browsers don't implement the frame version?
>>>
>>>
>>>
>>> In theory, a web developer could prioritize the processing of
>>> higher-priority requests differently than low-priority requests but most
>>> cases where that makes sense would probably be relying on other headers
>>> like "Sec-Purpose: prefetch" if they want to segregate their infrastructure
>>> and de-prioritize background fetches.
>>>
>>>
>>>
>>>
>>>
>>> *Gecko*: Shipped/Shipping
>>> *WebKit*: Shipped/Shipping
>>>
>>>
>>> Any links that show this is shipping?
>>> I see some evidence that this is available behind a flag in Safari, but
>>> nothing beyond that.
>>>
>>>
>>> Safari removed the explicit flag in 16.4 for HTTP/3 and enabled it for a
>>> subset of users but I don't see mention of it in the release notes in 16.4
>>> or later so the status hasn't been communicated externally. When HTTP/3
>>> does get used in Safari, the Priority header is always enabled. I have a
>>> test page here (https://headers.patrickmeenan.com/) that has HTTP/3
>>> enabled and will echo the protocol and headers that were received by the
>>> server. If you can get Safari to use HTTP/3 (at a minimum you have to turn
>>> off private relay) then it will show the Priority header.
>>>
>>> Firefox pretty reliably switches to HTTP/3 on the test page after a few
>>> reloads and will show the header.
>>>
>>> The test page also tests what the browser does if fetch() is called with
>>> a priority header that is application-set.  Safari (and the Chrome
>>> implementation) defer to the application-set value and do not add the
>>> protocol-specific value in that case. Firefox sends 2 Priority headers.
>>>
>>>
>>> Would be great to get an official word from them on what they are
>>> shipping and when. Maybe file (non-blocking) positions on this?
>>>
>>>
>>>
>>>
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> HTTP headers (and protocols) are not testable in Web Platform Tests.
>>>
>>>
>>> I don't think that's correct. You could create custom handlers
>>> 
>>>  that
>>> would reflect the request's priority header in the response.
>>>
>>>
>>> Sorry, headers themselves are testable but this header specifically
>>> requires a HTTP/3 server for cross-browser testing (or at least a HTTP/2
>>> server for Chrome testing) AFAIK, the server in wpt can't test HTTP/3. Even
>>> if it could, the actual priority values themselves aren't standardized and
>>> wouldn't be testable in wpt (other than their presence).
>>>
>>> If the header is added to HTTP/1.1 requests (or if at least HTTP/2 is
>>> support

Re: [blink-dev] Intent to Prototype and Ship: URL.canParse

[Mike Taylor]

LGTM1

On 10/13/23 6:08 PM, Jeremy Roman wrote:



Contact emails

jbro...@chromium.org


Explainer

None


Specification

https://url.spec.whatwg.org/#dom-url-canparse


Summary

A static operation to determine whether a URL string is valid. More 
concise than catching an exception thrown from the URL constructor.




Blink component

Blink>DOM 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This improves interoperability -- this feature is already supported in 
stable releases of Firefox and Safari. It is not expected to have any 
compatibility risk.




/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: Positive (https://github.com/whatwg/url/issues/713)

/Other signals/:


Ergonomics

Improves ergonomics of checking URL validity.



Activation

None anticipated.



Security

None -- this is an ergonomic change.



WebView application risks

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


None



Debuggability

None.



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes

Covered under url/ directory, and functionality is close to trivial.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 120

Shipping on Android 120

Shipping on WebView 120



Anticipated spec changes

Open questions about a feature may be a source of future web compat or 
interop issues. Please list open issues (e.g. links to known github 
issues in the project for the feature specification) whose resolution 
may introduce web compat/interop risk (e.g., changing to naming or 
structure of the API in a non-backward-compatible way).


None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5123302532317184

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/CACuR13cbGAQn0-F_ygyqh1n0SP4p4rxdWO-0VYcb__fGYwgXqA%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/c61d7298-ba71-4cae-89d6-bfdcbb94b211%40chromium.org.

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Mike Taylor]

Hi Nan, a few questions inline:

On 10/6/23 8:45 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org , johni...@chromium.org


Explainer

Attribution Reporting with event-level reports 



Attribution Reporting API with Aggregatable Reports 



Aggregation Service for the Attribution Reporting API 




Specification

https://wicg.github.io/attribution-reporting-api/ 




Blink component

Internals > AttributionReporting 




Summary

We plan on landing one change to the Attribution Reporting API focused on:

 *

Multiple cloud providers support for aggregate reporting,
supporting AWS and GCP

 o

**Note**: This change will also affect Private Aggregation API
’s
aggregatable reports by adding a new top-level field
aggregation_coordinator_origin.

Does this proposed change correspond to the TODO at the bottom of 
https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service? 
I think no, but I'm not entirely sure.


In the Private Aggregation API, 
https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports 
seems to define this aggregation_coordinator_origin but there's an open 
inline spec issue just after (pointing to a closed issue 78). Is that 
entirely resolved, or are there still open questions that may change the 
API?




Explainer changes

 *

Add aggregation coordinator identifier to support multiple cloud
providers 

 *

Use aggregation coordinator origin instead of identifier



Spec changes

 *

Add aggregation coordinator identifier to aggregatable report


 *

Use aggregation coordinator origin instead of identifier


 *

Add aggregation_coordinator_origin to PAA serialized report




Risks


Interoperability and Compatibility

The change is backwards compatible, and allows developers to select 
the deployment option for the aggregation service. By default, the AWS 
coordinator will be used (the existing behavior), and the public keys 
will be served on both old and new endpoints during the transition period.


Can you say more about this transition period? Is this related to 
"transitional debugging reports", or something else entirely?



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

All except Android WebView


Is this feature fully tested by web-platform-tests

?

Yes


Estimated milestones

Chrome 119


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5197591256236032 




Links to previous Intent discussions

Previous I2S:

Intent to Ship: Attribution Reporting API 



Intent to Ship: Attribution Reporting features M117 



Intent to Ship: Attribution Reporting features M118 




--
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/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%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/

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Nan Lin]

Thanks Mike, please see the inline comment.

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  wrote:

> Hi Nan, a few questions inline:
> On 10/6/23 8:45 AM, Nan Lin wrote:
>
> Contact emails
>
> lin...@chromium.org, johni...@chromium.org
>
> Explainer
>
> Attribution Reporting with event-level reports
> 
>
> Attribution Reporting API with Aggregatable Reports
> 
>
> Aggregation Service for the Attribution Reporting API
> 
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/
>
> Blink component
>
> Internals > AttributionReporting
> 
>
> Summary
>
> We plan on landing one change to the Attribution Reporting API focused on:
>
>-
>
>Multiple cloud providers support for aggregate reporting, supporting
>AWS and GCP
>-
>
>   **Note**: This change will also affect Private Aggregation API
>   ’s
>   aggregatable reports by adding a new top-level field
>   aggregation_coordinator_origin.
>
> Does this proposed change correspond to the TODO at the bottom of
> https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service?
> I think no, but I'm not entirely sure.
>
> In the Private Aggregation API,
> https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports
> seems to define this aggregation_coordinator_origin but there's an open
> inline spec issue just after (pointing to a closed issue 78). Is that
> entirely resolved, or are there still open questions that may change the
> API?
>
> Explainer changes
>
>-
>
>Add aggregation coordinator identifier to support multiple cloud
>providers 
>-
>
>Use aggregation coordinator origin instead of identifier
>
>
> Spec changes
>
>-
>
>Add aggregation coordinator identifier to aggregatable report
>
>-
>
>Use aggregation coordinator origin instead of identifier
>
>-
>
>Add aggregation_coordinator_origin to PAA serialized report
>
> 
>
>
> Risks
> Interoperability and Compatibility
>
> The change is backwards compatible, and allows developers to select the
> deployment option for the aggregation service. By default, the AWS
> coordinator will be used (the existing behavior), and the public keys will
> be served on both old and new endpoints during the transition period.
>
> Can you say more about this transition period? Is this related to
> "transitional debugging reports", or something else entirely?
>

This is about the transition period for releasing multiple cloud providers
support. M119+ is going to fetch public keys from the new endpoint, whereas
older versions still fetch from the old endpoint.
Therefore to ensure not breaking older versions, the public keys will be
served on both endpoints for some time after M119 release.

>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All except Android WebView
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Estimated milestones
>
> Chrome 119
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5197591256236032
>
> Links to previous Intent discussions
>
> Previous I2S:
>
> Intent to Ship: Attribution Reporting API
> 
>
> Intent to Ship: Attribution Reporting features M117
> 
>
> Intent to Ship: Attribution Reporting features M118
> 
>
> --
> 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/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%40mail.gmail.com
> 

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Nan Lin]

A few more inline comments, thanks!

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  wrote:

> Hi Nan, a few questions inline:
> On 10/6/23 8:45 AM, Nan Lin wrote:
>
> Contact emails
>
> lin...@chromium.org, johni...@chromium.org
>
> Explainer
>
> Attribution Reporting with event-level reports
> 
>
> Attribution Reporting API with Aggregatable Reports
> 
>
> Aggregation Service for the Attribution Reporting API
> 
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/
>
> Blink component
>
> Internals > AttributionReporting
> 
>
> Summary
>
> We plan on landing one change to the Attribution Reporting API focused on:
>
>-
>
>Multiple cloud providers support for aggregate reporting, supporting
>AWS and GCP
>-
>
>   **Note**: This change will also affect Private Aggregation API
>   ’s
>   aggregatable reports by adding a new top-level field
>   aggregation_coordinator_origin.
>
> Does this proposed change correspond to the TODO at the bottom of
> https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service?
> I think no, but I'm not entirely sure.
>
The TODO is actually related to the proposed change. We have a pending PR
 to expose the
allowlist of the aggregation coordinator origins that will be used to
verify the aggregation coordinator origin specified in the API surface. Any
origins not included in the allowlist will be rejected.

> In the Private Aggregation API,
> https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports
> seems to define this aggregation_coordinator_origin but there's an open
> inline spec issue just after (pointing to a closed issue 78). Is that
> entirely resolved, or are there still open questions that may change the
> API?
>
This is not resolved yet and the proposed spec change is here
.
The aggregation coordinator selection is not supported in Private
Aggregation API yet, which is being spec'ed and implemented,
but the aggregatable reports created by the API will include the
aggregation_coordinator_origin field with the default value.

> Explainer changes
>
>-
>
>Add aggregation coordinator identifier to support multiple cloud
>providers 
>-
>
>Use aggregation coordinator origin instead of identifier
>
>
> Spec changes
>
>-
>
>Add aggregation coordinator identifier to aggregatable report
>
>-
>
>Use aggregation coordinator origin instead of identifier
>
>-
>
>Add aggregation_coordinator_origin to PAA serialized report
>
> 
>
>
> Risks
> Interoperability and Compatibility
>
> The change is backwards compatible, and allows developers to select the
> deployment option for the aggregation service. By default, the AWS
> coordinator will be used (the existing behavior), and the public keys will
> be served on both old and new endpoints during the transition period.
>
> Can you say more about this transition period? Is this related to
> "transitional debugging reports", or something else entirely?
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All except Android WebView
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Estimated milestones
>
> Chrome 119
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5197591256236032
>
> Links to previous Intent discussions
>
> Previous I2S:
>
> Intent to Ship: Attribution Reporting API
> 
>
> Intent to Ship: Attribution Reporting features M117
> 
>
> Intent to Ship: Attribution Reporting features M118
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving 

Re: [blink-dev] Intent to Ship: WebGPU f16 support

[Ryan Harrison]

I cannot figure out how in the chromestatus entry how to set these
reviews (privacy & security) as being 'N/A'. The only entries related to
these that appear in 'Edit All Fields' are up in the dev trial section, and
changing those values, don't appear to affect the chips.

Clicking on the chips for me just brings up the comments/review dialogue on
the side. I am unsure if the issue is that the review has already started,
so I cannot change the status to N/A now, or if that is something that can
only be done by a reviewer.

(cwallez @google and @chromium are both on the editors list already, I have
added cwal...@chromium.org to the owners list incase that was needed)


On Wed, 11 Oct 2023 at 16:42, Ken Russell  wrote:

> Chris, is there any way to grant Corentin edit access to the Chromestatus
> entry? Ryan's OOO the rest of this week and we'd like to progress this
> before then. Thanks.
>
>
> On Wed, Oct 11, 2023 at 11:44 AM Corentin Wallez 
> wrote:
>
>> Thank you for the guidance. I commented on each of these, but
>> unfortunately don't have edit rights on the feature status so I can't mark
>> the reviews as started.
>>
>> On Wed, Oct 11, 2023 at 8:20 PM Chris Harrelson 
>> wrote:
>>
>>> Hi Corentin,
>>>
>>> The reviews I'm talking about are the "chips" UI in your chromestatus
>>> entry . Screenshot
>>> below. Once the reviews have begun the gray chips will turn blue or green.
>>> This is a recent change to chromestatus, see here
>>> 
>>> for more context. If a review category is not applicable there is a way to
>>> mark it as such in the chromestatus review flow for your feature.
>>>
>>>
>>> [image: image.png]
>>>
>>> On Wed, Oct 11, 2023 at 11:10 AM Corentin Wallez 
>>> wrote:
>>>
 You mention 5 reviews, there's Security / Privacy / TAG but I'm not
 sure what the others are. We believe that the three reviews we know of are
 not applicable both because this feature doesn't impact them, and because
 any review would be a rehash of parts of the reviews for the original
 WebGPU release. Is there a way to mark this in the status entry?

 On Wed, Oct 11, 2023 at 4:52 PM Chris Harrelson 
 wrote:

> Please fill out the 5 other review categories (security, privacy, etc)
> in chromestatus. Those will need to be started before the API owners can
> review.
>
> On Thu, Oct 5, 2023 at 1:17 PM Ryan Harrison 
> wrote:
>
>> +cc cwallez, since he is the WebGPU lead, and can respond
>> authoritatively if I am OOO
>>
>> Contact emailsrharri...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://www.w3.org/TR/webgpu/#shader-f16
>>
>> Summary
>>
>> Allows for the use of the half-precision floating-point type f16 in
>> WebGPU shaders (WGSL). Developers can use the 'shader-f16' feature from 
>> the
>> WebGPU spec and the 'f16' extension from the WGSL spec to access 16-bit
>> floating point variables and APIs in their shaders.
>>
>>
>> Blink componentInternals>GPU>Dawn
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Positive Mozilla has already implemented this feature.
>>
>> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=254668)
>>
>> *Web developers*: Positive f16 support in general has been requested
>> feature in multiple different web runtimes/frameworks, e.g.
>> https://github.com/microsoft/onnxruntime/issues/9758 and
>> http://tc39.es/proposal-float16array/ From the initial proposal,
>> https://github.com/gpuweb/gpuweb/issues/658, there were multiple
>> benchmarks/demoes that indicate a substantial performance benefit shown 
>> in
>> demos/tests, ~25% if ALU bound, and upto 50% if memory bound. TF.js has
>> been investigating using f16 in WebGPU,
>> https://github.com/gpuweb/gpuweb/issues/658#issuecomment-606492757 and
>> already has it available in the WebGL implementation TF.js has 
>> significant
>> improvements from forcing using Half Float (the GL equivalent feature),
>> https://github.com/tensorflow/tfjs/issues/1047 The Dawn team has
>> interacted with multiple internal and external partners that have 
>> indicated
>> that f16 support is an important feature for them to get the performance
>> needed to adopt WebGPU
>>
>> *Other signals*: Intel has dedicated significant resources to help
>> implement f16 in Dawn/Tint, and write proper testing coverage in the CTS.
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such
>> 

Re: [blink-dev] Intent to Experiment: Web app scope extensions

['Lu Huang' via blink-dev]

Quick update: 
We would like to push the start back to M121, and request that it run for 6 
milestones initially.
First milestone: 121. 
Last milestone: 126.

On Thursday, October 12, 2023 at 10:11:29 AM UTC-7 mike...@chromium.org 
wrote:

> Jason, could you please work with Lu to figure out why he can't post 
> comments in the chromestatus entry (but can request a review)?
>
> thanks.
> On 10/11/23 5:25 PM, 'Lu Huang' via blink-dev wrote:
>
> For the 3 review categories in chromestatus (security, privacy, and 
> debuggability), I have clicked on request review but have not found a way 
> to post comments from the UI.
>
> For security and privacy, we have a self-review at:  
> manifest-incubations/scope_extensions-security-privacy-questionnaire.md 
> at gh-pages · WICG/manifest-incubations (github.com) 
> 
> For debuggability, here are the survey responses until I find out how to 
> add to the comments at chromestatus:
>
> (1) Does the introduction of the new Web Platform feature break Chrome 
> DevTools' existing developer experience? No. (2) Does Chrome DevTools' 
> existing set of tooling features interact with the new Web Platform feature 
> in an expected way? 
> Yes. (3) Would the new Web Platform feature's acceptance and/or adoption 
> benefit from adding a new developer workflow to Chrome DevTools? Yes. If 
> adopted, this new feature would benefit from new UI and tooling in the 
> Application Page of Chrome DevTools. DevTools support can help developers 
> determine if they have set up the web app association configuration 
> correctly and if their specified scope_extensions are valid.
>
> On Wednesday, October 11, 2023 at 2:12:09 PM UTC-7 Lu Huang wrote:
>
>> We would like to start running this experiment from 120 through 123 
>> inclusive, but may have to delay start to 121 running through 124. 
>>
>>
>>
>> On Wednesday, October 11, 2023 at 7:54:51 AM UTC-7 Chris Harrelson wrote:
>>
>>> Please also fill out the 3 other review categories (security, privacy, 
>>> debuggability) in chromestatus. 
>>>
>>>
>>> On Wed, Oct 11, 2023 at 7:13 AM Mike Taylor  
>>> wrote:
>>>
 Hi there,

 Could you clarify which milestones you would like to run the experiment 
 on?

 thanks,
 Mike
 On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:

 Contact emails 
 lu...@microsoft.com, luig...@microsoft.com, alanc...@chromium.org

 Explainer

 https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md

 Specification
 None

 Design docs

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

 Summary 

 Adds a "scope_extensions" app manifest member that enables web apps to 
 extend their scope to other origins. Example usage: { "name": "Example", 
 "display": "standalone", "start_url": "/index.html", "scope_extensions": [ 
 {"origin": "https://*.example.com"}, {"origin": "https://example.co.uk"; 
 }, {"origin": "https://*.example.co.uk"} ] } 
 This allows sites that control multiple subdomains and top level domains 
 to 
 be presented as a single web app. Requires listed origins to confirm 
 association with the web app using a 
 .well-known/web-app-origin-association 
 configuration file. { "web_apps" : [ {"web_app_identity": 
 "https://sample-app.com/"; } ] }


 Blink component
 UI>Browser>WebAppInstalls 
 

 TAG review
 https://github.com/w3ctag/design-reviews/issues/875

 TAG review status
 Pending

 Risks

 Interoperability and Compatibility 
 *Gecko*: No signal (
 https://github.com/mozilla/standards-positions/issues/904)

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

 *Web developers*: No signals

 *Other signals*:

 Ergonomics

 None.


 Activation 

 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?


 Goals for experimentationAllow app partners to experiment more broadly 
 with the scope_extensions feature and provide feedback. We want to 
 evaluate 
 the shape of the scope_extensions API for ease of use and expose any 
 corner 
 cases. Specifically, we want to understand if origin-level granularity is 
 sufficient without path filters. We will evaluate this based on feedback 
 from OT participants. 

 Ongoing technical constraints 

 None.


 Debuggability 

Re: [blink-dev] Intent to Experiment: Web app scope extensions

[Alex Russell]

I'm supportive of this, but curious why 6 milestones. If there are partners
signed up to provide feedback, can we summarize that input sooner than 6
months?

Best,

Alex

On Mon, Oct 16, 2023 at 9:00 AM 'Lu Huang' via blink-dev <
blink-dev@chromium.org> wrote:

> Quick update:
> We would like to push the start back to M121, and request that it run for
> 6 milestones initially.
> First milestone: 121.
> Last milestone: 126.
>
> On Thursday, October 12, 2023 at 10:11:29 AM UTC-7 mike...@chromium.org
> wrote:
>
>> Jason, could you please work with Lu to figure out why he can't post
>> comments in the chromestatus entry (but can request a review)?
>>
>> thanks.
>> On 10/11/23 5:25 PM, 'Lu Huang' via blink-dev wrote:
>>
>> For the 3 review categories in chromestatus (security, privacy, and
>> debuggability), I have clicked on request review but have not found a way
>> to post comments from the UI.
>>
>> For security and privacy, we have a self-review at:  
>> manifest-incubations/scope_extensions-security-privacy-questionnaire.md
>> at gh-pages · WICG/manifest-incubations (github.com)
>> 
>> For debuggability, here are the survey responses until I find out how to
>> add to the comments at chromestatus:
>>
>> (1) Does the introduction of the new Web Platform feature break Chrome
>> DevTools' existing developer experience? No. (2) Does Chrome DevTools'
>> existing set of tooling features interact with the new Web Platform feature
>> in an expected way?
>> Yes. (3) Would the new Web Platform feature's acceptance and/or adoption
>> benefit from adding a new developer workflow to Chrome DevTools? Yes. If
>> adopted, this new feature would benefit from new UI and tooling in the
>> Application Page of Chrome DevTools. DevTools support can help developers
>> determine if they have set up the web app association configuration
>> correctly and if their specified scope_extensions are valid.
>>
>> On Wednesday, October 11, 2023 at 2:12:09 PM UTC-7 Lu Huang wrote:
>>
>>> We would like to start running this experiment from 120 through 123
>>> inclusive, but may have to delay start to 121 running through 124.
>>>
>>>
>>>
>>> On Wednesday, October 11, 2023 at 7:54:51 AM UTC-7 Chris Harrelson wrote:
>>>
 Please also fill out the 3 other review categories (security, privacy,
 debuggability) in chromestatus.


 On Wed, Oct 11, 2023 at 7:13 AM Mike Taylor 
 wrote:

> Hi there,
>
> Could you clarify which milestones you would like to run the
> experiment on?
>
> thanks,
> Mike
> On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:
>
> Contact emails
> lu...@microsoft.com, luig...@microsoft.com, alanc...@chromium.org
>
> Explainer
>
> https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md
>
> Specification
> None
>
> Design docs
>
> https://docs.google.com/document/d/1-idhx8heajbPYl3cdXFVCjpIuf96cRa_DrRk6147ELI/edit?usp=sharing
>
> Summary
>
> Adds a "scope_extensions" app manifest member that enables web apps to
> extend their scope to other origins. Example usage: { "name": "Example",
> "display": "standalone", "start_url": "/index.html", "scope_extensions": [
> {"origin": "https://*.example.com"}, {"origin":
> "https://example.co.uk"; }, {"origin": "https://
> *.example.co.uk"} ] } This allows sites that control multiple
> subdomains and top level domains to be presented as a single web app.
> Requires listed origins to confirm association with the web app using a
> .well-known/web-app-origin-association configuration file. { "web_apps" : 
> [
> {"web_app_identity": "https://sample-app.com/";
> } ] }
>
>
> Blink component
> UI>Browser>WebAppInstalls
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/875
>
> TAG review status
> Pending
>
> Risks
>
> Interoperability and Compatibility
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/904)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/265)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> None.
>
>
> Activation
>
> 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?
>
>
> Goals for experimentationAllow app partners to experiment more
> broadly with the scope_extensions feature and provide feedback. We want to
> evaluate the

Re: [blink-dev] Intent to Prototype and Ship: URL.canParse

[Alex Russell]

LGTM2

On Mon, Oct 16, 2023 at 7:24 AM Mike Taylor  wrote:

> LGTM1
> On 10/13/23 6:08 PM, Jeremy Roman wrote:
>
> Contact emails jbro...@chromium.org
>
> Explainer None
>
> Specification https://url.spec.whatwg.org/#dom-url-canparse
>
> Summary
>
> A static operation to determine whether a URL string is valid. More
> concise than catching an exception thrown from the URL constructor.
>
>
> Blink component Blink>DOM
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This improves interoperability -- this feature is already supported in
> stable releases of Firefox and Safari. It is not expected to have any
> compatibility risk.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>
> *Web developers*: Positive (https://github.com/whatwg/url/issues/713)
>
> *Other signals*:
>
> Ergonomics
>
> Improves ergonomics of checking URL validity.
>
>
> Activation
>
> None anticipated.
>
>
> Security
>
> None -- this is an ergonomic change.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
>
> Covered under url/ directory, and functionality is close to trivial.
>
>
> Flag name on chrome://flags None
>
> Finch feature name None
>
> Non-finch justification None
>
> Requires code in //chrome? False
>
> Estimated milestones
> Shipping on desktop 120
> Shipping on Android 120
> Shipping on WebView 120
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5123302532317184
>
> 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/CACuR13cbGAQn0-F_ygyqh1n0SP4p4rxdWO-0VYcb__fGYwgXqA%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/c61d7298-ba71-4cae-89d6-bfdcbb94b211%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Re-implement and Ship: CSS Font Loading API - FontFaceSet: check() method

[Alex Russell]

LGTM1

On Sun, Oct 15, 2023 at 1:01 PM ChangSeok Oh  wrote:

> Contact emails
> changseok...@bytedance.com, shivami...@gmail.com
>
> Specification
> https://drafts.csswg.org/css-font-loading/#font-face-set-check
>
> Summary
>
> The FontFaceSet's check() function verifies whether it's possible to
> display text using the specified fonts without attempting to utilize fonts
> in the FontFaceSet that have not completed loading. This allows users to
> safely employ the font without later triggering a font replacement (i.e.,
> font swap).
>
>
> *Motivation*While having a review [1] to fix issue 1416842 [2], I heard
> that an "Intent to ship" email is required since the fix changes Blink's
> behavior. The font loading API was updated, so we need to update our
> implementation in conformance with the spec.
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/4913179
> [2] https://crbug.com/1416842
>
> Blink component
> Blink>Fonts
> 
>
> Search tags
> CSS , Font
> , Loading
> , FontFaceSet
> , check
> 
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> The current behavior of Blink does neither follow the updated spec nor
> match other engines' behavior. This proposal aims at fixing it.
> https://github.com/w3c/csswg-drafts/issues/5744
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1252821)
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=156035
> )
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
> Debuggability
>
> None
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> The following WPT tests cover this feature. *
> css/css-fonts/fallback-remote-to-data-url.html *
> css/css-fonts/fallback-url-to-local.html
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1416842
>
> Estimated milestones
> Shipping on desktop
> 120
> Shipping on Android
> 120
> Shipping on WebView
> 120
> Shipping on WebView
> 120
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5174086494060544
>
> 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/f1705c1e-cf65-4c2e-bfe2-3ee3b4fb12d1n%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

[Chris Fredrickson]

We're now rolling this feature out to 100% on Chrome Stable (M117 and 
later).

On Tuesday, September 26, 2023 at 11:20:29 AM UTC-4 Chris Fredrickson wrote:

> Belatedly updating this thread in case folks are monitoring it -- we've 
> enabled this feature on 1% of Chrome Stable (M117) clients. We'll update 
> this thread again when we roll out to a higher percentage.
>
> As a reminder: if people would like to test this feature out before we've 
> fully shipped it, they can can follow the testing instructions here: 
> https://github.com/cfredric/chrome-storage-access-api#testing-instructions
>
> On Tuesday, August 22, 2023 at 1:26:10 PM UTC-4 Mike Taylor wrote:
>
>> LGTM3
>> On 8/22/23 10:49 AM, Yoav Weiss wrote:
>>
>> LGTM2
>>
>> On Wed, Aug 16, 2023 at 7:31 PM Chris Harrelson  
>> wrote:
>>
>>> I agree with Chris F. that it's not worth the disruption to change the 
>>> name or its location, and that leaving the name as-is, even if suboptimal, 
>>> is a better outcome for web developers. 
>>>
>>> LGTM1
>>>
>>> On Wed, Aug 16, 2023 at 9:37 AM 'Jeffrey Yasskin' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 I see this as the other vendors endorsing Blink's general policy, 
 implied by the wording in 
 https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews,
  
 that there's a high bar for name changes after shipping. If this API, 
 which 
 has a clearly inaccurate name and was shipped with no invitation for 
 cross-vendor feedback, isn't worth changing after shipping, then it's not 
 worth changing most APIs that Blink ships first either.

 Jeffrey

 On Wed, Aug 16, 2023 at 8:52 AM Alex Russell  
 wrote:

> Hrm; the TAG had (many years ago, when I served) noted big problems 
> with the shape of this API. It's surprising we're taking it as-is.
>
> On Tuesday, August 8, 2023 at 9:08:43 AM UTC-7 Chris Fredrickson wrote:
>
>> Hi Alex, 
>>
>> I hear you about the method names. However since Safari, Firefox, and 
>> Edge had all previously shipped this API using these names and web 
>> developers have already begun using it, it would have been disruptive 
>> for 
>> Chrome to force a rename. We opted to limit the disruption we caused to 
>> improving the ergonomics and security posture of the API instead (1 
>> , 2 
>> , 3 
>> , 4 
>> , 5 
>> , 6 
>> ), since that 
>> was indeed disruptive but there was at least cross-browser interest in 
>> making those changes.
>>
>> Re: navigator vs document, there was previous discussion of this here 
>> . We did not 
>> specifically ask the TAG about which object they preferred, but they 
>> closed 
>> their review with no comments. Considering that each document's access 
>> is 
>> independent of access obtained by other documents (due to the per-frame 
>> security model), the choice of document makes some sense to me, 
>> personally 
>> - but there may be some best practice I'm unaware of.
>>
>> FWIW, Chrome is exploring 
>> 
>>  
>> ways to use document.requestStorageAccess() to provide access to 
>> unpartitioned DOM storage in the future, in which case the current name 
>> would be more appropriate.
>>
>> Chris
>>
>> On Monday, August 7, 2023 at 6:46:41 PM UTC-4 Alex Russell wrote:
>>
>>> Hey Chris, 
>>>
>>> Thanks for the details here.
>>>
>>> Can you perhaps outline why we didn't take the opportunity here to 
>>> rename this to better represent what the API actually does? E.g., 
>>> `requestUnpartitionedCookieAccess()`? And was any effort made to move 
>>> the 
>>> API to a more suitable object; e.g. `navigator`? Was this discussed 
>>> with 
>>> the TAG?
>>>
>>> Best,
>>>
>>> Alex
>>>
>>>
>>>
>>> On Monday, August 7, 2023 at 11:47:45 AM UTC-7 Chris Fredrickson 
>>> wrote:
>>>
 Hi Mike,

 Sure. MDN has a section 
 
  
 (which may be incomplete or outdated) on the implementation 
 differences 
 between Safari, Firefox, and Chromium-based browsers. But specifically 
 related to the prompt requirements, there are two aspects that may 
 cause 
 compat issues:
>

Re: [blink-dev] Intent to Experiment: Web app scope extensions

['Lu Huang' via blink-dev]

In this case, I want to make sure there's enough time for app partners to 
enroll in January when M121 reaches Stable and for us to help them 
troubleshoot the configuration needed. This feature requires more 
server-side configuration ( of /.well-known/web-app-origin-association) 
that could take time to troubleshoot than other web app manifest features 
in the past. 

If things go well and we get the desired feedback in time, we could try to 
move forward from OT before the 6 months are up. 

On Monday, October 16, 2023 at 10:32:28 AM UTC-7 sligh...@chromium.org 
wrote:

> I'm supportive of this, but curious why 6 milestones. If there are 
> partners signed up to provide feedback, can we summarize that input sooner 
> than 6 months?
>
> Best,
>
> Alex
>
> On Mon, Oct 16, 2023 at 9:00 AM 'Lu Huang' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Quick update: 
>> We would like to push the start back to M121, and request that it run for 
>> 6 milestones initially.
>> First milestone: 121. 
>> Last milestone: 126.
>>
>> On Thursday, October 12, 2023 at 10:11:29 AM UTC-7 mike...@chromium.org 
>> wrote:
>>
>>> Jason, could you please work with Lu to figure out why he can't post 
>>> comments in the chromestatus entry (but can request a review)?
>>>
>>> thanks.
>>> On 10/11/23 5:25 PM, 'Lu Huang' via blink-dev wrote:
>>>
>>> For the 3 review categories in chromestatus (security, privacy, and 
>>> debuggability), I have clicked on request review but have not found a way 
>>> to post comments from the UI.
>>>
>>> For security and privacy, we have a self-review at:  
>>> manifest-incubations/scope_extensions-security-privacy-questionnaire.md 
>>> at gh-pages · WICG/manifest-incubations (github.com) 
>>> 
>>> For debuggability, here are the survey responses until I find out how to 
>>> add to the comments at chromestatus:
>>>
>>> (1) Does the introduction of the new Web Platform feature break Chrome 
>>> DevTools' existing developer experience? No. (2) Does Chrome DevTools' 
>>> existing set of tooling features interact with the new Web Platform feature 
>>> in an expected way? 
>>> Yes. (3) Would the new Web Platform feature's acceptance and/or adoption 
>>> benefit from adding a new developer workflow to Chrome DevTools? Yes. 
>>> If adopted, this new feature would benefit from new UI and tooling in the 
>>> Application Page of Chrome DevTools. DevTools support can help developers 
>>> determine if they have set up the web app association configuration 
>>> correctly and if their specified scope_extensions are valid.
>>>
>>> On Wednesday, October 11, 2023 at 2:12:09 PM UTC-7 Lu Huang wrote:
>>>
 We would like to start running this experiment from 120 through 123 
 inclusive, but may have to delay start to 121 running through 124. 



 On Wednesday, October 11, 2023 at 7:54:51 AM UTC-7 Chris Harrelson 
 wrote:

> Please also fill out the 3 other review categories (security, privacy, 
> debuggability) in chromestatus. 
>
>
> On Wed, Oct 11, 2023 at 7:13 AM Mike Taylor  
> wrote:
>
>> Hi there,
>>
>> Could you clarify which milestones you would like to run the 
>> experiment on?
>>
>> thanks,
>> Mike
>> On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:
>>
>> Contact emails 
>> lu...@microsoft.com, luig...@microsoft.com, alanc...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md
>>
>> Specification
>> None
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1-idhx8heajbPYl3cdXFVCjpIuf96cRa_DrRk6147ELI/edit?usp=sharing
>>
>> Summary 
>>
>> Adds a "scope_extensions" app manifest member that enables web apps 
>> to extend their scope to other origins. Example usage: { "name": 
>> "Example", 
>> "display": "standalone", "start_url": "/index.html", "scope_extensions": 
>> [ 
>> {"origin": "https://*.example.com"}, {"origin": 
>> "https://example.co.uk"; }, {"origin": 
>> "https://*.example.co.uk"} ] } This allows sites that control 
>> multiple subdomains and top level domains to be presented as a single 
>> web 
>> app. Requires listed origins to confirm association with the web app 
>> using 
>> a .well-known/web-app-origin-association configuration file. { 
>> "web_apps" : 
>> [ {"web_app_identity": "https://sample-app.com/"; 
>> } ] }
>>
>>
>> Blink component
>> UI>Browser>WebAppInstalls 
>> 
>>
>> TAG review
>> https://github.com/w3ctag/design-reviews/issues/875
>>
>> TAG review status
>> Pending
>>
>> Risks

Re: [blink-dev] Intent to Re-implement and Ship: CSS Font Loading API - FontFaceSet: check() method

[Mike Taylor]

LGTM2

On 10/16/23 1:35 PM, Alex Russell wrote:

LGTM1

On Sun, Oct 15, 2023 at 1:01 PM ChangSeok Oh  wrote:

Contact emails
changseok...@bytedance.com,shivami...@gmail.com

Specification
https://drafts.csswg.org/css-font-loading/#font-face-set-check

Summary

The FontFaceSet's check() function verifies whether it's possible
to display text using the specified fonts without attempting to
utilize fonts in the FontFaceSet that have not completed loading.
This allows users to safely employ the font without later
triggering a font replacement (i.e., font swap).


*Motivation
*While having a review [1] to fix issue 1416842 [2], I heard that
an "Intent to ship" email is required since the fix changes
Blink's behavior. The font loading API was updated, so we need to
update our implementation in conformance with the spec.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/4913179
[2] https://crbug.com/1416842

Blink component
Blink>Fonts


Search tags
CSS ,Font
,Loading
,FontFaceSet
,check


TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

The current behavior of Blink does neither follow the updated spec
nor match other engines' behavior. This proposal aims at fixing
it. https://github.com/w3c/csswg-drafts/issues/5744


/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1252821)

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=156035)

/Web developers/: No signals

/Other signals/:

WebView application risks

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

None


Debuggability

None


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

Is this feature fully tested byweb-platform-tests

?Yes


The following WPT tests cover this feature. *
css/css-fonts/fallback-remote-to-data-url.html *
css/css-fonts/fallback-url-to-local.html


Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

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

Estimated milestones
Shipping on desktop
120
Shipping on Android
120
Shipping on WebView
120
Shipping on WebView
120

Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known github issues in the project for the feature specification)
whose resolution may introduce web compat/interop risk (e.g.,
changing to naming or structure of the API in a
non-backward-compatible way).

None

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

This intent message was generated byChrome 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/f1705c1e-cf65-4c2e-bfe2-3ee3b4fb12d1n%40chromium.org

.

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

[blink-dev] PSA: Extra supported format for Protected Audience size macros

[Garrett Tanzer]

Hi blink-dev,

PSA:

In the Protected Audience API within the Privacy Sandbox, there is an
opt-in feature that allows you to macro the size of the ad that wins the
auction into the ad’s url, like:

https://ad.com?width={%AD_WIDTH%}&height={%AD_HEIGHT%}

(See https://github.com/WICG/turtledove/pull/417 for more details.)

To be more consistent with other types of macros in Protected Audience,
like those used by deprecatedReplaceInURN and registerAdMacro, in M119
we’re adding the ability to use ${AD_WIDTH} and ${AD_HEIGHT} as the format
for the macros in addition to the current format.

This is backwards compatible because the old format will continue to work.
Technically, there could be changes in behavior for ads that have already
opted in to the size macroing and erroneously use ${AD_WIDTH} or
${AD_HEIGHT} rather than {%AD_WIDTH%} and {%AD_HEIGHT%}: before the macros
wouldn’t work, and now they will. This seems exceedingly unlikely, and is
more like a bug fix.

More references:
ChromeStatus (https://chromestatus.com/feature/5140606359175168)
Spec (https://github.com/WICG/turtledove/pull/801)

Thanks!

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

[blink-dev] Intent to Prototype: Verifying IPFS client

[John Turpish]

*Contact emails*
j...@littlebearlabs.io (primary)
jfernan...@igalia.com
dietr...@protocol.ai

*Explainer*
https://github.com/little-bear-labs/ipfs-chromium/blob/main/doc/explainer.md

*Specification*
Multiple specs are relevant. The most important is:
https://specs.ipfs.tech/http-gateways/trustless-gateway/
Some others:
https://github.com/ipfs/specs/blob/main/UNIXFS.md
https://specs.ipfs.tech/ipns/ipns-record/
https://specs.ipfs.tech/routing/http-routing-v1/
https://specs.ipfs.tech/http-gateways/web-redirects-file/

*Summary*

IPFS is content-addressed networking.
https://en.wikipedia.org/wiki/InterPlanetary_File_System

The goal of this effort is to add effective/useful support for 3 styles 
of URLs to Chromium:

ipfs:///path
ipns:///path
ipns:///path

The plan is to use a multi-gateway trustless approach.

*Blink component*
Blink>Network 



*Motivation*
Web rendering engines today currently do not offer a way to retrieve and 
render content that is

1) verifiable at the data layer nor
2) available across origins.
Both of these features are aspects of a more resilient web than HTTP 
alone can provide - and which are both available in the Interplanetary 
FileSystem (IPFS) protocol.
However, as IPFS is not directly compatible with HTTP nor the origin 
security model, it must be implemented as a separate protocol in order 
to deliver these features, and also to communicate to the user this 
different model, and adequately manage user expectations.
This feature provides an HTTP-based approach to retrieving 
cryptographically verifiable content from an interchangeable pool of 
servers providing access to content over the IPFS public network.


*Initial public proposal*
https://groups.google.com/a/chromium.org/g/chromium-dev/c/kmmrpDWfF90/m/96HvP5QUBwAJ

*TAG review*

*TAG review status*
None yet

*Risks*
For users not making use of IPFS, fairly minimal as most of the code 
would be inactive for them.


It may be difficult or even impossible to fully protect URL 
canonicalization changes with a feature flag.


This protocol changes how people think about origins, which may raise 
same-origin security concerns.
The model is near-identical to the one used on subdomain gateways, so 
some relevant discussion appears in these pages.

https://specs.ipfs.tech/http-gateways/subdomain-gateway/
https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway

There could be concerns around impact on caching, or misunderstandings 
of the gateway settings.


*Interoperability and Compatibility*

Here are some of the attempts at supporting IPFS in web browsers:
https://github.com/ipfs/in-web-browsers/blob/master/README.md#current-projects

Some support in other web-related tools (ffmpeg, curl):
https://github.com/ipfs/integrations/blob/main/README.md#completed-integrations

*WebView application risks*
No

*Debuggability*
We intend to add IPFS-specific functionality to DevTools.
The POC's current approach (adding headers to the aggregate internal 
response for debugging's sake) might raise concerns and may be dropped 
entirely.


*Is this feature fully tested by web-platform-tests?*
Not yet.

*Flag name*
"enable-ipfs" / url::kEnableIpfs (Chromium flag)

*Build flag*
ENABLE_IPFS

*Requires code in //chrome?*
True (currently, discussion about other design options are on-going)

*Estimated milestones*
https://github.com/little-bear-labs/ipfs-chromium/milestones

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

*Tracking issue*
https://bugs.chromium.org/p/chromium/issues/detail?id=1440503#c_ts1682598269
--
You received this message because you are subscribed to a topic in the 
Google Groups "blink-network-dev" group.
To unsubscribe from this topic, visit 
https://groups.google.com/a/chromium.org/d/topic/blink-network-dev/o9asNNdx3Fk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
blink-network-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/09c250f0-22aa-4528-b339-77a8eeedec5an%40chromium.org 
.


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

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

['Liam Brady' via blink-dev]

Contact emails

shivani...@chromium.org d...@chromium.org jkar...@chromium.org 
lbr...@google.com 
Explainer(s)

Send Automatic Beacons To All Registered Destinations

https://github.com/WICG/turtledove/pull/808 

Spec(s)

Send Automatic Beacons To All Registered Destinations

(Initial version) https://github.com/WICG/fenced-frame/pull/122

(Post-security review updates) https://github.com/WICG/fenced-frame/pull/129

 
Summary

We launched Fenced Frames as a part of Chrome 115. One of its capabilities 
is being able to send reporting beacons automatically after a top-level 
navigation. We would like to modify that functionality:

Automatic beacons will now send to all registered URLs. Previously, only 
destinations specified when calling setReportEventDataForAutomaticBeacons() 
receive automatic beacons, even if that destination called 
registerAdBeacon() for "reserved.top_navigation" in their worklet. Now, any 
destination that called registerAdBeacon() for "reserved.top_navigation" 
will get an automatic beacon, but only destinations specified in 
setReportEventDataForAutomaticBeacons() will get automatic beacon data 
along with the beacon. setReportEventDataForAutomaticBeacons() still must 
be invoked before automatic beacons can send out, effectively making the 
function a way for the frame’s origin to opt in to automatic beacons.

Note: This chromestatus entry also includes changes to Protected Audience 
ad size macros. However, it is small enough that it will be taken care of 
in a separate PSA: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/3JfA8EUBEgQ

Blink component

Blink>FencedFrames 


TAG reviews and status

Fenced frames existing TAG review appended with these spec changes 
https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1765061770

Link to Origin Trial feedback summary

No Origin Trial performed

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

Supported on all the above platforms except Android WebView.

Debuggability

Additional debugging capabilities are not necessary for these feature 
changes.

Risks

Compatibility

There are no compatibility risks, as described below:

The API shape as exposed to ad frames is not changing. While the 
assumptions of which sites receive the beacon after calling 
setReportEventDataForAutomaticBeacons() is changing, no code changes will 
be required to have existing code work with this new behavior.

Interoperability

there are no interoperability risks as no other browsers have decided to 
implement these features yet.

Is this feature fully tested by web-platform-tests 
?
 
Link to test suite results from wpt.fyi.

Yes

automatic-beacon-no-destination.https.html (test 
)
 
(results 

)

automatic-beacon-no-opt-in.https.html (test 
)
 
(results 

)

Anticipated spec changes

None 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140606359175168

Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ko9UXQYPgUE/m/URRsB-qvAAAJ
 

Intent to experiment:

https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/Lcpmpi_LAgAJ
 

Intent to extend origin trial:

https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ
 

https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ
 

https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ
 

Intent to ship:

https://groups.google.com/a/chromium.org/g/blink-dev/c/tpw8wW0VenQ/m/mePLTiHlDQAJ

Intent to ship for functionality updates:

https://groups.google.com/a/chromium.org/g/blink-dev/c/2FKlwNZ0J4Q/m/oQmHtp1rAQAJ

-- 
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/8c564532-be09-4d4a-8801-8292cba18240n%40chromium.org.

Re: [blink-dev] Intent to Prototype: Verifying IPFS client

['Jeffrey Yasskin' via blink-dev]

Thanks for posting this here. I have a couple questions/suggestions:

* In your explainer, I don't see a description of the use cases for each of
the 3 URL forms you plan to implement. https://tag.w3.org/explainers/ has
some guidance around doing that.
* The explainer says "Why HTTP(s)?", but nothing before that says that
anything's using HTTP(s). What's going on here? :)
* Your "Initial public proposal" is a chromium-dev post, which isn't as
public as this field really wants. I think you have multiple organizations
interested, which means this is appropriate for a WICG proposal
 (unless there's another community group
or other incubation venue that's more appropriate). This is probably
eventually destined for Fetch, so the WHATWG Specification Acceptance Stages
 might be appropriate, but as
that's new, you might also not want to risk getting bogged down in its
growing pains.
* I don't see any Privacy Considerations in the explainer. My understanding
is that IPFS exposes requests to a different set of actors than HTTPS does,
and your explainer should discuss the differences, how they interact with
the expectations of someone browsing the web, and how browsers should help
people expect the right things. There may also be Security Considerations
to point out.

Thanks,
Jeffrey


On Mon, Oct 16, 2023 at 12:39 PM John Turpish 
wrote:

> *Contact emails*
> j...@littlebearlabs.io (primary)
> jfernan...@igalia.com
> dietr...@protocol.ai
>
> *Explainer*
>
> https://github.com/little-bear-labs/ipfs-chromium/blob/main/doc/explainer.md
>
> *Specification*
> Multiple specs are relevant. The most important is:
> https://specs.ipfs.tech/http-gateways/trustless-gateway/
> Some others:
> https://github.com/ipfs/specs/blob/main/UNIXFS.md
> https://specs.ipfs.tech/ipns/ipns-record/
> https://specs.ipfs.tech/routing/http-routing-v1/
> https://specs.ipfs.tech/http-gateways/web-redirects-file/
>
> *Summary*
>
> IPFS is content-addressed networking.
> https://en.wikipedia.org/wiki/InterPlanetary_File_System
>
> The goal of this effort is to add effective/useful support for 3 styles of
> URLs to Chromium:
> ipfs:///path
> ipns:///path
> ipns:///path
>
> The plan is to use a multi-gateway trustless approach.
>
> *Blink component*
> Blink>Network
> 
>
> *Motivation*
> Web rendering engines today currently do not offer a way to retrieve and
> render content that is
> 1) verifiable at the data layer nor
> 2) available across origins.
> Both of these features are aspects of a more resilient web than HTTP alone
> can provide - and which are both available in the Interplanetary FileSystem
> (IPFS) protocol.
> However, as IPFS is not directly compatible with HTTP nor the origin
> security model, it must be implemented as a separate protocol in order to
> deliver these features, and also to communicate to the user this different
> model, and adequately manage user expectations.
> This feature provides an HTTP-based approach to retrieving
> cryptographically verifiable content from an interchangeable pool of
> servers providing access to content over the IPFS public network.
>
> *Initial public proposal*
>
> https://groups.google.com/a/chromium.org/g/chromium-dev/c/kmmrpDWfF90/m/96HvP5QUBwAJ
>
> *TAG review*
>
> *TAG review status*
> None yet
>
> *Risks*
> For users not making use of IPFS, fairly minimal as most of the code would
> be inactive for them.
>
> It may be difficult or even impossible to fully protect URL
> canonicalization changes with a feature flag.
>
> This protocol changes how people think about origins, which may raise
> same-origin security concerns.
> The model is near-identical to the one used on subdomain gateways, so some
> relevant discussion appears in these pages.
> https://specs.ipfs.tech/http-gateways/subdomain-gateway/
> https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway
>
> There could be concerns around impact on caching, or misunderstandings of
> the gateway settings.
>
> *Interoperability and Compatibility*
>
> Here are some of the attempts at supporting IPFS in web browsers:
>
> https://github.com/ipfs/in-web-browsers/blob/master/README.md#current-projects
>
> Some support in other web-related tools (ffmpeg, curl):
>
> https://github.com/ipfs/integrations/blob/main/README.md#completed-integrations
>
> *WebView application risks*
> No
>
> *Debuggability*
> We intend to add IPFS-specific functionality to DevTools.
> The POC's current approach (adding headers to the aggregate internal
> response for debugging's sake) might raise concerns and may be dropped
> entirely.
>
> *Is this feature fully tested by web-platform-tests?*
> Not yet.
>
> *Flag name*
> "enable-ipfs" / url::kEnableIpfs (Chromium flag)
>
> *Build flag*
> ENABLE_IPFS
>
> *Requires code in //chrome?*
> True (currently, discussion about other design options are on-going)
>
>

[blink-dev] BlinkOn 18 is tomorrow!

[BlinkOn Planning Committee]

bcc: blink-dev@ and BlinkOn 18 attendees


Hi all,


BlinkOn 18 is tomorrow!  If you’re still needing to register to attend
virtually, do so here
.
Virtual registration will be open until the day of the event.


Schedule

You can view the schedule here
.
To join the event, click the Google Meet link here
 which can also be found in the
calendar invite. The link is the same for all three days.

   -

   Please join the call 10 min early to reduce disruption during the event.


Comms

For announcements and event chatter, join the Chromium workspace here

and join the #blinkon channel.


Code of conduct

We’d like to remind folks of the Code of Conduct
 for BlinkOn 18.


Session recording

All talks will be recorded and added to the BlinkOn YouTube channel
 following the event.


If you have any questions, please email us at blin...@chromium.org.


Thanks,

BlinkOn Planning Committee

-- 
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/CABjKNU59Qph97Okrhatppzu82P3RTmZwj4%2B%3Dx2wwJB%2Bre37ZLg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Mike Taylor]

On 10/16/23 7:57 AM, Nan Lin wrote:


A few more inline comments, thanks!

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  
wrote:


Hi Nan, a few questions inline:

On 10/6/23 8:45 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org ,
johni...@chromium.org


Explainer

Attribution Reporting with event-level reports


Attribution Reporting API with Aggregatable Reports


Aggregation Service for the Attribution Reporting API




Specification

https://wicg.github.io/attribution-reporting-api/



Blink component

Internals > AttributionReporting




Summary

We plan on landing one change to the Attribution Reporting API
focused on:

 *

Multiple cloud providers support for aggregate reporting,
supporting AWS and GCP

 o

**Note**: This change will also affect Private
Aggregation API

’s
aggregatable reports by adding a new top-level field
aggregation_coordinator_origin.


Does this proposed change correspond to the TODO at the bottom of

https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service?
I think no, but I'm not entirely sure.

The TODO is actually related to the proposed change. We have a pending 
PR  to 
expose the allowlist of the aggregation coordinator origins that will 
be used to verify the aggregation coordinator origin specified in the 
API surface. Any origins not included in the allowlist will be rejected.
Thanks for the pointer to the updated explainer (PR...). I see that the 
PR is approved - landing it ASAP may make reviews easier for others.


In the Private Aggregation API,

https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports
seems to define this aggregation_coordinator_origin but there's an
open inline spec issue just after (pointing to a closed issue 78).
Is that entirely resolved, or are there still open questions that
may change the API?

This is not resolved yet and the proposed spec change is here 
. 
The aggregation coordinator selection is not supported in Private 
Aggregation API yet, which is being spec'ed and implemented,
but the aggregatable reports created by the API will include the 
aggregation_coordinator_origin field with the default value.

I see - thanks.




Explainer changes

 *

Add aggregation coordinator identifier to support multiple
cloud providers


 *

Use aggregation coordinator origin instead of identifier



Spec changes

 *

Add aggregation coordinator identifier to aggregatable report


 *

Use aggregation coordinator origin instead of identifier


 *

Add aggregation_coordinator_origin to PAA serialized report




Risks


Interoperability and Compatibility

The change is backwards compatible, and allows developers to
select the deployment option for the aggregation service. By
default, the AWS coordinator will be used (the existing
behavior), and the public keys will be served on both old and new
endpoints during the transition period.


Can you say more about this transition period? Is this related to
"transitional debugging reports", or something else entirely?



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

All except Android WebView


Is this feature fully tested by web-platform-tests

?

Yes


Estimated milestones

Chrome 119


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5197591256236032

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Mike Taylor]

LGTM1

On 10/16/23 7:48 AM, Nan Lin wrote:

Thanks Mike, please see the inline comment.

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  
wrote:




Interoperability and Compatibility

The change is backwards compatible, and allows developers to
select the deployment option for the aggregation service. By
default, the AWS coordinator will be used (the existing
behavior), and the public keys will be served on both old and new
endpoints during the transition period.


Can you say more about this transition period? Is this related to
"transitional debugging reports", or something else entirely?


This is about the transition period for releasing multiple cloud 
providers support. M119+ is going to fetch public keys from the new 
endpoint, whereas older versions still fetch from the old endpoint.
Therefore to ensure not breaking older versions, the public keys will 
be served on both endpoints for some time after M119 release.
OK - got it. At some future point you'll send an Intent to Deprecate & 
Remove sending public keys from the old endpoint. :)


--
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/4616eb26-41c2-4186-b93a-9a8934097116%40chromium.org.

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Mike Taylor]

LGTM1

On 10/15/23 11:07 AM, 'Sahir Vellani' via blink-dev wrote:
Thanks for the feedback, I wasn't aware they were mandatory. The steps 
have been started, just awaiting feedback from Security and Privacy 
reviewers. I've received LGTMs for all other areas. After our response 
to WebKit's question, they did not have any further follow-up 
questions. So I'm assuming all is well.


On Wednesday, October 11, 2023 at 4:59:15 AM UTC-7 Daniel Bratell wrote:

I see that various mandatory steps in chromestatus
(privacy,security,enterprise,debuggability,testing) seems to be
unstarted. It is possible they were made mandatory after you
create the entry, but it would be good if you could get them
started now at least.

Also, it's unfortunate that TAG and standards positions requests
have not resulted in anything, but that is hardly your fault.
There were some questions in the WebKit request. Is all that ok now?

/Daniel

On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:



On Friday, October 6, 2023 at 9:03:35 AM UTC-7
mike...@chromium.org wrote:


On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:

Contact emails
gerc...@microsoft.com, sahir@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Specification

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Summary

As devices with advanced pen input capabilities are becoming
increasingly prevalent, it is important that the web
platform continues to evolve to fully support these advanced
features in order to unlock rich experiences for both end
users and developers. One such advancement is the ability
for a device's digitizer to recognize more than one pen
device interacting with it simultaneously. This feature is
an extension to the PointerEvent interface to include a new
attribute, deviceId, that represents a session-persistent,
document isolated, unique identifier that a developer can
reliably use to identify individual pens interacting with
the page.



Blink component
Blink>Input



TAG review
https://github.com/w3ctag/design-reviews/issues/880

TAG review status
Pending. TAG review has been pending for 2 months.

Risks


Interoperability and Compatibility


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

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

/Web developers/: No signals

/Other signals/:

WebView application risks

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

None



Debuggability


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

Is this feature fully tested by web-platform-tests

?

No. However, there are web tests in Chromium that test
PointerEventInit with this feature.

Flag name on chrome://flags
PointerEventDeviceId

Finch feature name


Non-finch justification
Edge origin trials successfully underway.

Any Origin Trial feedback you can share?


Absolutely, the feature has been working well. Our partners
(Microsoft Whiteboard) have enabled the feature that is dependent
on this API for their general audience! We did not receive any
constructive feedback. This API is being used by them on
Microsoft Surface Hub devices, which support multi-pen inking.



Requires code in //chrome?
False

Measurement
PointerEventDeviceId use counter implemented.

Availability expectation
Initially available on Chromium browsers on Windows.

Out of curiosity, are there limitations on other platforms
that prevent supporting this feature?


We haven't been able to get our hands on hardware that supports
other platforms in addition to multi pen inking in order to
implement and appropriately test this feature. We welcome any
sponsors for implementing and testing this, especially on
Linux/Android.



Adoption expectation
Feature is used by specific partner(s) to provide
functionality immediately upon launch.

Adoption plan
This feature has been through origin trials on Edge. It is
being used by partners that provide feat

Re: [blink-dev] Intent to Ship: WebGPU f16 support

[Ken Russell]

Blink API owners, could you please guide Ryan and Corentin on how to move
this feature forward?

Perhaps it's best to just have the privacy team sign off on it - this
should be easy because there is no privacy concern for this feature.

Again, while this is a medium-sized WebGPU shading language feature, it's
well understood and multiple customers are eager for it to become generally
available so they can speed up their machine learning workloads running on
WebGPU.

Thanks,

-Ken



On Mon, Oct 16, 2023 at 8:31 AM Ryan Harrison 
wrote:

> I cannot figure out how in the chromestatus entry how to set these
> reviews (privacy & security) as being 'N/A'. The only entries related to
> these that appear in 'Edit All Fields' are up in the dev trial section, and
> changing those values, don't appear to affect the chips.
>
> Clicking on the chips for me just brings up the comments/review dialogue
> on the side. I am unsure if the issue is that the review has already
> started, so I cannot change the status to N/A now, or if that is something
> that can only be done by a reviewer.
>
> (cwallez @google and @chromium are both on the editors list already, I
> have added cwal...@chromium.org to the owners list incase that was needed)
>
>
> On Wed, 11 Oct 2023 at 16:42, Ken Russell  wrote:
>
>> Chris, is there any way to grant Corentin edit access to the Chromestatus
>> entry? Ryan's OOO the rest of this week and we'd like to progress this
>> before then. Thanks.
>>
>>
>> On Wed, Oct 11, 2023 at 11:44 AM Corentin Wallez 
>> wrote:
>>
>>> Thank you for the guidance. I commented on each of these, but
>>> unfortunately don't have edit rights on the feature status so I can't mark
>>> the reviews as started.
>>>
>>> On Wed, Oct 11, 2023 at 8:20 PM Chris Harrelson 
>>> wrote:
>>>
 Hi Corentin,

 The reviews I'm talking about are the "chips" UI in your chromestatus
 entry . Screenshot
 below. Once the reviews have begun the gray chips will turn blue or green.
 This is a recent change to chromestatus, see here
 
 for more context. If a review category is not applicable there is a way to
 mark it as such in the chromestatus review flow for your feature.


 [image: image.png]

 On Wed, Oct 11, 2023 at 11:10 AM Corentin Wallez 
 wrote:

> You mention 5 reviews, there's Security / Privacy / TAG but I'm not
> sure what the others are. We believe that the three reviews we know of are
> not applicable both because this feature doesn't impact them, and because
> any review would be a rehash of parts of the reviews for the original
> WebGPU release. Is there a way to mark this in the status entry?
>
> On Wed, Oct 11, 2023 at 4:52 PM Chris Harrelson 
> wrote:
>
>> Please fill out the 5 other review categories (security, privacy,
>> etc) in chromestatus. Those will need to be started before the API owners
>> can review.
>>
>> On Thu, Oct 5, 2023 at 1:17 PM Ryan Harrison 
>> wrote:
>>
>>> +cc cwallez, since he is the WebGPU lead, and can respond
>>> authoritatively if I am OOO
>>>
>>> Contact emailsrharri...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://www.w3.org/TR/webgpu/#shader-f16
>>>
>>> Summary
>>>
>>> Allows for the use of the half-precision floating-point type f16 in
>>> WebGPU shaders (WGSL). Developers can use the 'shader-f16' feature from 
>>> the
>>> WebGPU spec and the 'f16' extension from the WGSL spec to access 16-bit
>>> floating point variables and APIs in their shaders.
>>>
>>>
>>> Blink componentInternals>GPU>Dawn
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: Positive Mozilla has already implemented this feature.
>>>
>>> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=254668)
>>>
>>> *Web developers*: Positive f16 support in general has been
>>> requested feature in multiple different web runtimes/frameworks, e.g.
>>> https://github.com/microsoft/onnxruntime/issues/9758 and
>>> http://tc39.es/proposal-float16array/ From the initial proposal,
>>> https://github.com/gpuweb/gpuweb/issues/658, there were multiple
>>> benchmarks/demoes that indicate a substantial performance benefit shown 
>>> in
>>> demos/tests, ~25% if ALU bound, and upto 50% if memory bound. TF.js has
>>> been investigating using f16 in WebGPU,
>>> https://github.com/gpuweb/gpuweb/issues/658#issuecomment-606492757 and
>>> already has it available in the WebGL implementation TF.js has

Re: [blink-dev] Intent to Ship: WebGPU f16 support

[Chris Harrelson]

Hi,

I don't think you need to do anything else. We'll re-review this intent at
our next meeting Wednesday morning PDT.

The security review is already done
 and the other one is in
progress. The API owners won't block on both finishing, we just wanted to
make sure they were started before finishing our review.


On Mon, Oct 16, 2023 at 4:40 PM Ken Russell  wrote:

> Blink API owners, could you please guide Ryan and Corentin on how to move
> this feature forward?
>
> Perhaps it's best to just have the privacy team sign off on it - this
> should be easy because there is no privacy concern for this feature.
>
> Again, while this is a medium-sized WebGPU shading language feature, it's
> well understood and multiple customers are eager for it to become generally
> available so they can speed up their machine learning workloads running on
> WebGPU.
>
> Thanks,
>
> -Ken
>
>
>
> On Mon, Oct 16, 2023 at 8:31 AM Ryan Harrison 
> wrote:
>
>> I cannot figure out how in the chromestatus entry how to set these
>> reviews (privacy & security) as being 'N/A'. The only entries related to
>> these that appear in 'Edit All Fields' are up in the dev trial section, and
>> changing those values, don't appear to affect the chips.
>>
>> Clicking on the chips for me just brings up the comments/review dialogue
>> on the side. I am unsure if the issue is that the review has already
>> started, so I cannot change the status to N/A now, or if that is something
>> that can only be done by a reviewer.
>>
>> (cwallez @google and @chromium are both on the editors list already, I
>> have added cwal...@chromium.org to the owners list incase that was
>> needed)
>>
>>
>> On Wed, 11 Oct 2023 at 16:42, Ken Russell  wrote:
>>
>>> Chris, is there any way to grant Corentin edit access to the
>>> Chromestatus entry? Ryan's OOO the rest of this week and we'd like to
>>> progress this before then. Thanks.
>>>
>>>
>>> On Wed, Oct 11, 2023 at 11:44 AM Corentin Wallez 
>>> wrote:
>>>
 Thank you for the guidance. I commented on each of these, but
 unfortunately don't have edit rights on the feature status so I can't mark
 the reviews as started.

 On Wed, Oct 11, 2023 at 8:20 PM Chris Harrelson 
 wrote:

> Hi Corentin,
>
> The reviews I'm talking about are the "chips" UI in your chromestatus
> entry . Screenshot
> below. Once the reviews have begun the gray chips will turn blue or green.
> This is a recent change to chromestatus, see here
> 
> for more context. If a review category is not applicable there is a way to
> mark it as such in the chromestatus review flow for your feature.
>
>
> [image: image.png]
>
> On Wed, Oct 11, 2023 at 11:10 AM Corentin Wallez 
> wrote:
>
>> You mention 5 reviews, there's Security / Privacy / TAG but I'm not
>> sure what the others are. We believe that the three reviews we know of 
>> are
>> not applicable both because this feature doesn't impact them, and because
>> any review would be a rehash of parts of the reviews for the original
>> WebGPU release. Is there a way to mark this in the status entry?
>>
>> On Wed, Oct 11, 2023 at 4:52 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>
>>> Please fill out the 5 other review categories (security, privacy,
>>> etc) in chromestatus. Those will need to be started before the API 
>>> owners
>>> can review.
>>>
>>> On Thu, Oct 5, 2023 at 1:17 PM Ryan Harrison 
>>> wrote:
>>>
 +cc cwallez, since he is the WebGPU lead, and can respond
 authoritatively if I am OOO

 Contact emailsrharri...@chromium.org

 ExplainerNone

 Specificationhttps://www.w3.org/TR/webgpu/#shader-f16

 Summary

 Allows for the use of the half-precision floating-point type f16 in
 WebGPU shaders (WGSL). Developers can use the 'shader-f16' feature 
 from the
 WebGPU spec and the 'f16' extension from the WGSL spec to access 16-bit
 floating point variables and APIs in their shaders.


 Blink componentInternals>GPU>Dawn
 

 TAG reviewNone

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 None


 *Gecko*: Positive Mozilla has already implemented this feature.

 *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=254668)

 *Web developers*: Positive f16 support in general has been
 requested feature in multiple different web runtimes/

Re: [blink-dev] Intent to Ship: WebGPU f16 support

[Ken Russell]

Got it - thanks Chris.


On Mon, Oct 16, 2023 at 4:54 PM Chris Harrelson 
wrote:

> Hi,
>
> I don't think you need to do anything else. We'll re-review this intent at
> our next meeting Wednesday morning PDT.
>
> The security review is already done
>  and the other one is
> in progress. The API owners won't block on both finishing, we just wanted
> to make sure they were started before finishing our review.
>
>
> On Mon, Oct 16, 2023 at 4:40 PM Ken Russell  wrote:
>
>> Blink API owners, could you please guide Ryan and Corentin on how to move
>> this feature forward?
>>
>> Perhaps it's best to just have the privacy team sign off on it - this
>> should be easy because there is no privacy concern for this feature.
>>
>> Again, while this is a medium-sized WebGPU shading language feature, it's
>> well understood and multiple customers are eager for it to become generally
>> available so they can speed up their machine learning workloads running on
>> WebGPU.
>>
>> Thanks,
>>
>> -Ken
>>
>>
>>
>> On Mon, Oct 16, 2023 at 8:31 AM Ryan Harrison 
>> wrote:
>>
>>> I cannot figure out how in the chromestatus entry how to set these
>>> reviews (privacy & security) as being 'N/A'. The only entries related to
>>> these that appear in 'Edit All Fields' are up in the dev trial section, and
>>> changing those values, don't appear to affect the chips.
>>>
>>> Clicking on the chips for me just brings up the comments/review dialogue
>>> on the side. I am unsure if the issue is that the review has already
>>> started, so I cannot change the status to N/A now, or if that is something
>>> that can only be done by a reviewer.
>>>
>>> (cwallez @google and @chromium are both on the editors list already, I
>>> have added cwal...@chromium.org to the owners list incase that was
>>> needed)
>>>
>>>
>>> On Wed, 11 Oct 2023 at 16:42, Ken Russell  wrote:
>>>
 Chris, is there any way to grant Corentin edit access to the
 Chromestatus entry? Ryan's OOO the rest of this week and we'd like to
 progress this before then. Thanks.


 On Wed, Oct 11, 2023 at 11:44 AM Corentin Wallez 
 wrote:

> Thank you for the guidance. I commented on each of these, but
> unfortunately don't have edit rights on the feature status so I can't mark
> the reviews as started.
>
> On Wed, Oct 11, 2023 at 8:20 PM Chris Harrelson 
> wrote:
>
>> Hi Corentin,
>>
>> The reviews I'm talking about are the "chips" UI in your chromestatus
>> entry .
>> Screenshot below. Once the reviews have begun the gray chips will turn 
>> blue
>> or green. This is a recent change to chromestatus, see here
>> 
>> for more context. If a review category is not applicable there is a way 
>> to
>> mark it as such in the chromestatus review flow for your feature.
>>
>>
>> [image: image.png]
>>
>> On Wed, Oct 11, 2023 at 11:10 AM Corentin Wallez <
>> cwal...@chromium.org> wrote:
>>
>>> You mention 5 reviews, there's Security / Privacy / TAG but I'm not
>>> sure what the others are. We believe that the three reviews we know of 
>>> are
>>> not applicable both because this feature doesn't impact them, and 
>>> because
>>> any review would be a rehash of parts of the reviews for the original
>>> WebGPU release. Is there a way to mark this in the status entry?
>>>
>>> On Wed, Oct 11, 2023 at 4:52 PM Chris Harrelson <
>>> chris...@chromium.org> wrote:
>>>
 Please fill out the 5 other review categories (security, privacy,
 etc) in chromestatus. Those will need to be started before the API 
 owners
 can review.

 On Thu, Oct 5, 2023 at 1:17 PM Ryan Harrison <
 rharri...@chromium.org> wrote:

> +cc cwallez, since he is the WebGPU lead, and can respond
> authoritatively if I am OOO
>
> Contact emailsrharri...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://www.w3.org/TR/webgpu/#shader-f16
>
> Summary
>
> Allows for the use of the half-precision floating-point type f16
> in WebGPU shaders (WGSL). Developers can use the 'shader-f16' feature 
> from
> the WebGPU spec and the 'f16' extension from the WGSL spec to access 
> 16-bit
> floating point variables and APIs in their shaders.
>
>
> Blink componentInternals>GPU>Dawn
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>>

[blink-dev] PSA: New baseline format for test-harness tests

['Weizhong Xia' via blink-dev]

Hi Blink Developers

We want to let you know that we are in the process of converting baselines
for test-harness tests into a new format. The reason is that we want to
make baselines machine-parsable so that we can regenerate Wpt Metadata from
Test Expectations and Baselines.

We are doing this directory by directory. Until now we have done this for
all legacy web tests, wpt_internal and external/wpt/html, and we are
expecting to complete this work by the end of this week.

This should mostly have no impact on your work, but a rebaseline might be
needed if we happened to work on the same directory at the same time.

thanks, Weizhong

-- 
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/CADXrSiobktBNXd1WD%2BK9gnaqAgW-oAq5Fn_3xGG1H9fUZ8Ezig%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Compression dictionary transport with Shared Brotli

[Tsuyoshi Horo]

Hi, blink-dev

We recently discovered a critical issue in the compression dictionary
transport feature. As a result, we disabled the feature several days ago.
This means that Origin Trial tokens for the feature will not work on the
current Chrome Stable version.

We have since fixed the bug and re-enabled the feature in Chrome
119.0.6045.29. Origin Trial tokens will work on Chrome Stable 119 and
later, which will be released on October 31, 2023.

We apologize for any inconvenience this may cause.

Thank you for your understanding.

On Wed, Sep 27, 2023 at 6:26 AM Patrick Meenan  wrote:

> It's probably also worth noting that adding encodings to the compression
> streams API would require browsers to bundle the compression code for the
> relevant encodings (where they only pull in the decompression code for
> network-level content encodings).
>
> Not saying the discussions shouldn't happen, just that they are separate
> discussions that should have the appropriate use cases and justifications
> laid out.
>
> On Tue, Sep 26, 2023 at 1:54 PM Patrick Meenan 
> wrote:
>
>> We had put the compression stream API out of scope
>> 
>> for the dictionary work because the dictionaries would require a different
>> constructor that allows for specifying the dictionary bytes (or stream).
>> That's independent of supporting zstd and br on the compression streams API
>> itself though (which would be necessary to add dictionary support).
>>
>> On Tue, Sep 26, 2023 at 1:17 PM Alex Russell 
>> wrote:
>>
>>> Hey folks,
>>>
>>> Glad to see there's excitement around the OT; was wondering if there has
>>> been any work to extend Compression Streams for zstd as part of this
>>> effort? I don't see it in the explainer, and it would be great for us not
>>> to be adding new ecodings that aren't also exposed to userland.
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Thursday, August 3, 2023 at 9:23:13 PM UTC-7 Tsuyoshi Horo wrote:
>>>
 Hi, blink-dev@ members.

 The origin trial for the new CompressionDictionaryTransport feature is
 now available in the Origin Trial console at:
 https://developer.chrome.com/origintrials/

 We have also published a document that provides more information about
 the feature and how to participate in the trial. The document can be found
 here:

 https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/compression-dictionary-transport.md

 We hope this information is helpful. Please let us know if you have any
 questions.

 Thanks.


 On Thu, Jul 27, 2023 at 12:29 AM Mike Taylor 
 wrote:

> LGTM to experiment from 117 to 122 inclusive.
>
> (Good luck, looks cool!)
> On 7/25/23 9:52 PM, Tsuyoshi Horo wrote:
>
> Contact emails h...@chromium.org, pmee...@chromium.org,
> yoavwe...@chromium.org, kenjibah...@chromium.org
>
> Explainer https://github.com/WICG/compression-dictionary-transport
>
> Specification https://github.com/WICG/compression-dictionary-transport
>
> Design docs
>
> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
> https://github.com/WICG/compression-dictionary-transport
>
> https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary
>
> Summary
>
> This feature adds support for using designated previous responses, as
> an external dictionary for Brotli-compressing HTTP responses.
>
>
> Blink component Blink>Network
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/877
>
> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability and Compatibility risk are low. This feature
> introduces a new compression method for transporting resources over HTTP.
> Web sites can know the browser support for the new feature by checking
> `document.createElement('link').relList.supports('dictionary')`. Also web
> servers can know the browser support by checking the `Accept-Encoding`
> request header and the new `Use-As-Dictionary` request header. This 
> feature
> is an opt-in feature. And the dictionary storage is isolated using the top
> level site and the frame origin as the key. That means, if there is no
> dictionary registered for the site, the behavior of Chrome will not change
> while browsing the site. Also this feature is usable only on
> secure-context. So this feature will not increase the risk of
> non-supporting network proxies misunderstanding the content’s encoding.
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/771)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/is

Re: [blink-dev] Re: Intent to Ship: HTTPS Upgrades

[Mike West]

Fantastic, thanks for the update. Hope it sticks!

-mike

On Mon, Oct 16, 2023 at 20:15 Chris Thompson  wrote:

> We enabled HTTPS-Upgrades by default on trunk last week, and are currently
> rolling out to 100% Stable.
>
> On Thu, Oct 5, 2023 at 10:42 AM Chris Thompson 
> wrote:
>
>> This week we increased the rollout of HTTPS Upgrades up to 35% Stable. We
>> are continuing to monitor issues and feedback. Given that we have not heard
>> any unexpected feedback yet we are planning to proceed to 100% Stable next
>> week.
>>
>> On Fri, Sep 1, 2023 at 10:42 AM Chris Thompson 
>> wrote:
>>
>>> This is currently enabled at 20% Stable. We have not heard any
>>> unexpected feedback yet, and are continuing to monitor for issues and
>>> feedback.
>>>
>>> On Thu, Aug 24, 2023 at 9:51 AM Daniel Bratell 
>>> wrote:
>>>
 Same (LGTM).

 I assume you have also not had any unexpected feedback. The methods you
 added to force http seemed adequate but you never know when you encounter
 the wild wild web.

 /Daniel
 On 2023-08-23 18:45, Chris Harrelson wrote:

 Still LGTM from me too.

 On Wed, Aug 23, 2023 at 8:58 AM Yoav Weiss 
 wrote:

> Still LGTM
>
> On Wed, Aug 23, 2023 at 5:47 PM Chris Thompson 
> wrote:
>
>> We have iterated on the Fetch spec PR
>>  and believe it is ready
>> to land modulo some editorial tweaks.
>>
>
> Please be sure to follow up on the PR once the reviewers get back to
> it.
>
>
>>
>> From our 1% Stable experiment, we saw a substantial decrease in
>> insecure plaintext HTTP navigation requests, and no regressions in Core 
>> Web
>> Vitals metrics.
>>
>> We would like to proceed with this Intent-to-Ship, doing a gradual
>> rollout to 100% in order to continue monitoring potential breakage.
>>
>> We did see a possible regression in renderer crash proportion, but we
>> have not been able to identify a plausible cause or crash signature. Due 
>> to
>> this possible stability risk we will be coordinating our gradual rollout
>> with release owners. I can update this thread each time we increase our
>> rollout percentage.
>>
>> - Chris
>>
>>
>>
>>
>> On Wed, Jul 19, 2023 at 9:01 PM Yoav Weiss 
>> wrote:
>>
>>> LGTM3 with similar conditions. If the PR takes an unreasonable
>>> amount of time to land, please let us know.
>>>
>>> On Wed, Jul 19, 2023 at 9:02 PM Chris Harrelson <
>>> chris...@chromium.org> wrote:
>>>
 LGTM2 with the same conditions as Daniel. Thanks also for following
 up with a summary before proceeding with rollout!

 On Wed, Jul 19, 2023 at 11:56 AM Chris Thompson <
 cth...@chromium.org> wrote:

> Thanks Daniel. As a quick update, this was just enabled at 1%
> Stable in M115 (released yesterday). We have not seen any blockers 
> come up
> from Beta, but since issues may arise mainly in the long tail of 
> sites we
> might not see anything until Stable anyway. We'll keep an eye on our
> experimental rollout and follow up here with a summary.
>
> On Wed, Jul 19, 2023 at 11:52 AM Daniel Bratell <
> bratel...@gmail.com> wrote:
>
>> I've been waiting a bit to see if the experiment would blow
>> anything up, but if it doesn't, and continue to not do so, then
>>
>> LGTM1 as soon as the PR has landed.
>>
>> /Daniel
>> On 2023-06-14 17:40, Yoav Weiss wrote:
>>
>>
>>
>> On Thursday, June 8, 2023 at 5:53:49 PM UTC+2 Chris Thompson
>> wrote:
>>
>> On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss 
>> wrote:
>>
>> Thanks for working on this!
>>
>> On Wed, Jun 7, 2023 at 11:44 PM Chris Thompson <
>> cth...@chromium.org> wrote:
>>
>> Thanks all. Some updates:
>>
>>- We have filed a TAG review request
>>
>>- We are working on writing WPTs and we will update this
>>thread when those are ready -- thanks for the added details about 
>> how those
>>are run
>>- We have added a `Non-Authoritative-Reason: HttpsUpgrades`
>>header to the synthetic redirects (CL
>>
>> ,
>>which we are planning to merge back to M-115)
>>- We are continuing to iterate on the spec PR
>>
>> For now we will continue to provide updates on this I2S -- closer
>> to M115 going to Stable we may send an I2E to request the ability to
>> proceed with a 1% Stable experiment if we have not