[blink-dev] Intent to Ship: Subresource Loading with Web Bundles

[Hayato Ito]

Contact emails:hay...@chromium.org, denom...@chromium.org


Explainer:

https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md


Specification:

https://wicg.github.io/webpackage/subresource-loading.html


Summary:

Provides a new approach to load a large number of resources efficiently
using a format that allows multiple resources to be bundled, Web Bundles

.


Note that the scope of this "Intent to Ship" is only v1, which is explained
in our long term plan . We
have been conducting the Origin Trial for v1 features
.
Given that the outcome is promising, we’d like to ship v1 as MVP in order
to mitigate the risk of "develop everything and ship them all at once".


After shipping v1, we'll explore *v2*, designing and implementing missing
key features, eg. cache-aware WebBundles. There are several proposals, such
as Bundle Preloading  (discussion
), Bundle Dependencies
,
and others. We continue to explore this area to identify a missing Web
Platform primitive in order to serve large Web Apps in a cache-efficient
way with Web Bundles.


Blink component

Blink>Loader>WebPackaging


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

TAG review status: While the status of the review is open, we have
addressed the concerns raised in the discussion. In particular, we plan to
explore the designs in v2 as explained above. Additionally, if a concern
with the extension part

continues to be an issue, we aim to address it in v2 as well.


Risks:

Interoperability and Compatibility:

No interoperability and compatibility risk has been identified. This is
purely a feature addition. A browser which doesn’t support this feature
should load subresources from the network, as usual.


Gecko: No signal (issue
)

WebKit: No signal (ML
)


Web Developers:

Google Ads (use case )
(origin trial participant)

> Web bundle serving is a major overhaul of how GPT requests and renders
ads, built on top of a new browser API which we have been designing with
the Chrome team.  It offers large loading performance improvements and
security and privacy relative to safeframe rendering:

   -

   Performance improvements by fetching multiple Ads creatives in a single
   request.
   -

   Enhance privacy: Creative contents can no longer be read or modified by
   the publisher or others in the publisher's JS context. Creatives can no
   longer read or modify each other.


Ergonomics

This feature can be used to improve loading performance by fetching
multiple resources in a single request. If a browser doesn’t support this
feature, a request should be served from a network as usual.

`HTMLScriptElement.supports("webbundle")` can be used for feature detection
as well.

There are several tools and plugins
 available for packaging
Web Bundles.


Security

Received approval for Security and Privacy in our launch bug
. We had addressed a security concern for the
usage of  elements. The API now uses 

Re: [blink-dev] Intent to Ship: Cookie Expires/Max-Age attribute upper limit

[Ari Chivukula]

Deal, but let's call metrics for M103 and the feature in M104.

~ Ari Chivukula (Their/There/They're)


On Mon, Apr 11, 2022 at 8:57 PM Yoav Weiss  wrote:

> LGTM1 conditional on:
>
>- Landing the metrics in M102 and the feature in M103
>- Coming back to this thread when the numbers start coming in on the
>metrics
>- Having a flag in place that'd enable us to disable the feature in
>case the numbers indicate that the loss of cookies due to lack of updates
>would be very high
>
>
> On Mon, Apr 11, 2022 at 10:58 PM Ari Chivukula 
> wrote:
>
>> Here's a design doc for the additional data to be measured:
>> https://docs.google.com/document/d/1x7_2wVY2gSEfMlvpS4AoQtN5x7fHG_AsQ01V4CkSELI/edit
>>
>> The target ship date for this thread is now M103, but we're still looking
>> for LGTMs.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Mon, Apr 11, 2022 at 7:46 AM Ari Chivukula 
>> wrote:
>>
>>> Since we don't currently store the last date a cookie was updated in
>>> chrome (just the original creation date) we wouldn't be able to get data on
>>> how many cookies would expire due to a lack of timely refreshes by the site
>>> (as opposed to a lack of site visits) for up to 400 days. The problem is
>>> that sites might be tuned to refresh periodically (instead of on every
>>> visit), which means we would have to wait for that unknown periodic refresh
>>> for a last update date to even be recorded.
>>>
>>> I think we should move forward with this change *and* add metrics so we
>>> have an idea (before the 400 day mark) which sites risk expiration and can
>>> alert them.
>>>
>>> I don't think there's an issue with sites taking 6 months to change
>>> refresh behavior as the expires logic only affects sites with
>>> less-than-annually active users. That is, affected users would login to use
>>> a site post-chrome expires change but pre-site refresh change, and then
>>> wait 400 days to try to use the site again for their login to expire.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>> On Mon, Apr 11, 2022, 05:18 Yoav Weiss  wrote:
>>>
 IIUC from offline conversations, once we start changing the expiration
 dates of cookies, we won't have a way to avoid enforcing that expiration
 date 400 days from now. So we probably want to get this right and avoid
 breakage for sites that don't currently update their cookies every time (as
 even if they change their behavior ~6 months from now, they'd accumulate 6
 months worth of users that visited their site but will have their cookies
 expired).

 Would it make sense to collect data on the cookie update dates (maybe
 even just data from beta), and only then ship the expiration max-age 
 change?


 On Mon, Apr 11, 2022 at 11:51 AM Ari Chivukula 
 wrote:

> We don't currently, but we know only 20% of cookies set in chrome are
> over the limit (and that 20% will continue to work if not updated). We're
> planning proactive communication about the change once it's approved since
> there's a 400 day window from the change going in until effects are first
> felt.
>
> ~ Ari Chivukula (Their/There/They're)
>
> On Mon, Apr 11, 2022, 02:03 Yoav Weiss  wrote:
>
>> Thanks! It seems like we'd need to tell developers then that they
>> need to update their cookies on every site visit. I don't know if this 
>> is a
>> big change from what they are already largely doing. Do we have data on
>> that?
>>
>> On Fri, Apr 8, 2022 at 7:26 PM Ari Chivukula 
>> wrote:
>>
>>> The actual expiration date written to the cookie store is capped at
>>> 400 days for any new/updated cookies.
>>>
>>> If a newly logged-in site doesn't refresh its cookies for 400 days
>>> after they are set, the cookies expire and the user will be logged out 
>>> no
>>> matter how often the user visits the site.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Fri, Apr 8, 2022 at 8:57 AM Yoav Weiss 
>>> wrote:
>>>
 What happens if a newly logged-in site doesn't refresh its cookies
 on every visit, the user visits that site every ~months, and 400 days 
 pass?
 In other words, when does the 400 days clock get reset: on visit or
 on cookie renewal?

 On Fri, Apr 8, 2022 at 4:59 PM Ari Chivukula 
 wrote:

> Cookies already in storage will not have this new limit imposed,
> but any cookies newly set or updated will have it imposed.
>
> If an existing logged-in site isn't visited for 400 days, and it
> previously allowed > 400 day retention, the user will still be logged 
> in on
> the 401st day.
>
> If an existing logged-in site newly updates its login cookies and
> then isn't visited for 400 days, the login cookies will expire after 
> 400

[blink-dev] Intent to Ship: Navigation API

[Domenic Denicola]

Contact emails

dome...@chromium.org, jap...@chromium.org

Explainer

https://github.com/WICG/navigation-api/blob/main/README.md

Specification

https://wicg.github.io/navigation-api/

Summary

The window.navigation API provides the ability to intercept and initiate
navigations, as well as introspect an application's history entries. This
provides a more useful alternative to window.history and window.location,
specifically aimed at the needs of single-page web applications.

(Note: this API was formerly known as the app history API.)

Blink component

Blink>History


TAG review

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

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

TAG review status

Issues addressed

Link to origin trial feedback summary

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

Risks
Interoperability

The biggest interoperability risk with this API is that it is building on a
rocky foundation. The existing session history spec does not match browsers
very well, and browsers do not match each other. Since this new API layers
on top of the existing model, this could cause issues.

We have attempted to address this via a solid and well-tested specification
for the new API, as well as ongoing efforts in whatwg/html PR #6315
 and elsewhere on the HTML
Standard issue tracker

to reform the foundational parts of the specification. For example,
although the navigation API's new events, such as currententrychange, are
fired at well-specified times, there is an existing interop problem
 regarding the timing of
popstate vs. hashchange events, which makes it difficult to write tests for
the ordering of currententrychange vs. hashchange/popstate. Working on such
existing interop issues and specification problems, and then expanding the
navigation API test suite to cover any such interactions, is our team's top
priority after this launch. See also this tracking issue
.

Regarding whether this new API will be implemented in other browsers, we
have been encouraged by the consistent and positive collaboration with
Gecko engineers, which has led to several API changes and a good amount of
review. (We have no signal from WebKit.)

Compatibility

This has been the team's main focus for the last few months, as we burned
through the list of potentially-compat-impacting issues
. In collaboration with
Gecko this led to several improvements, such as the API rename (from app
history), a change  in
how replacement navigations are requested, and the addition
 of an indicator for when
a download is requested. We believe the remaining issues (3 at the time of
writing) are manageable:


   -

   #72 : this will result
   in firing an event more often during extreme edge case scenarios involving
   replacement navigations, or in less-rare-but-still-rare scenarios involving
   the user clearing their history. Neither case should prove problematic.
   -

   #207 : the most
   likely solution will either be leaving things as they are, or changing the
   timing of an event in a way that will not disturb "normal" usage of the
   API. Although such a timing change could be risky if this API had wide
   deployment, we believe that changing the timing within a milestone or three
   would not be problematic if it ends up being desirable.
   -

   #202 : this issue is
   about the default for how focus is managed following a navigation
   API-intercepted navigation. We believe the currently-chosen default is
   probably the best, especially given testaments on that thread from the
   accessibility community and from web framework authors. However we have not
   yet closed the issue as we haven't concluded the discussion with Gecko
   engineers. Similar to #207, this would probably be changeable within a few
   milestones if necessary, without significant impact to sites using the API.
   And if we did change it, early-adopter sites could easily restore the
   previous behavior by changing the value of an option.


Signals

Gecko: No signal .
Initial positive opinions on the issue, and continued engagement on the
design, but not yet an official position.

WebKit: No signal
.

[blink-dev] Re: Intent to Enable Origin Trial support on Android WebView

['Peter Birk Pakkenberg' via blink-dev]

Hi Joe,

The 14 trials I listed

all
target Android, which also includes WebView. So far they haven't been
active on WebView because origin trials haven't been enabled, but once we
do enable the origin trial component, any trial that is active on Android
will become available for WebView clients.

Sincerely,
[image: Google Logo]
Peter Birk Pakkenberg
Software Engineer
pb...@google.com
+447469379358 <+44%207469%20379358>


On Tue, 12 Apr 2022 at 15:46, Joe Medley  wrote:

> So 102 stable could have an origin trial that includes WebView?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Tue, Apr 12, 2022 at 4:35 AM Peter Birk Pakkenberg 
> wrote:
>
>> Hi Joe,
>>
>> Yes, we are planning to start the roll out once M102 has launched on
>> Stable.
>>
>> Sincerely,
>> [image: Google Logo]
>> Peter Birk Pakkenberg
>> Software Engineer
>> pb...@google.com
>> +447469379358 <+44%207469%20379358>
>>
>>
>> On Mon, 11 Apr 2022 at 18:42, Joe Medley  wrote:
>>
>>> Peter,
>>>
>>> Do you know any release/availability dates yet? We need to add fields
>>> to the Chrome Status
>>> .
>>>
>>> On Thursday, April 7, 2022 at 8:59:53 AM UTC-7 Peter Birk Pakkenberg
>>> wrote:
>>>
 Hello blink-dev@

 We are hoping to begin rolling out origin trial support on WebView. The
 goal is to ensure that the origins who wish to test new Blink features can
 reach users in Android WebView as well.
 Launch Bugs

 http://crbug.com/1186236

 http://crbug.com/1308425 (internal launch bug)
 Summary

 We will soon enable origin trials on Android WebView, which means that
 clients will start to honour Origin-Trial headers for trials that target
 the Android platform in runtime_enabled_features.json5
 ,
 provided the feature is implemented for WebView. This means that a number
 of existing Blink trials will be enabled.

 The long term goal is to achieve parity between WebView and Chrome on
 Android when it comes to experimentation for features implemented in Blink,
 which has two key benefits to the Chromium project. First, it provides a
 large number of additional clients to test new Blink features. Due to the
 embedded nature of WebView, this will provide new insights into a part of
 the web ecosystem that has previously not been accessible to
 experimentation (for example hybrid apps). In turn, this will help to avoid
 surprises for feature developers who rely on origin trials to launch new
 features, which will hopefully lead to smoother feature launches.
 Why Now

 Planned features on WebView require origin testing, making it a
 necessity to enable the framework. Additionally, the longer origin trials
 remain disabled on WebView, the more likely it is that a trial misses an
 issue on WebView that could have been found, like it has happened in
 the past .
 Affected trials

 By our analysis, 14 trials
 
 will be affected by the enablement on WebView. This means that they a) are
 targeting the Android platform, and b) have been implemented in shared code
 that is used by WebView. Other trials may rely on integrations in the
 embedder, which have not been implemented for WebView, which means that
 they won’t exhibit any new behaviour during the roll-out.
 Rollout plan

 WebView does not have good penetration on the dev/beta channels, so we
 will have to do the primary experiment on Stable. Given that we will be
 enabling all applicable origin trials on WebView at the same time as part
 of our feature roll-out, we expect full support to reach all WebView users
 in 3-4 weeks.
 Feedback from the Blink community

 We’d love to receive feedback and questions from the Blink community,
 either via this thread, in the launch bug
  or
 privately. Some of the things that we’ve been thinking about:


-

Should targeting Android in runtime_enabled_features.json5 include
or exclude WebView? We propose for it to be included as the majority of
trials are either applicable to WebView as well, or have the 
 corresponding
features disabled through other means in Chromium.

-

How should trial owners consider WebView metrics in their analysis?
For Googlers, the UMA dashboards provide this 

[blink-dev] Re: Intent to Enable Origin Trial support on Android WebView

['Joe Medley' via blink-dev]

So 102 stable could have an origin trial that includes WebView?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Tue, Apr 12, 2022 at 4:35 AM Peter Birk Pakkenberg 
wrote:

> Hi Joe,
>
> Yes, we are planning to start the roll out once M102 has launched on
> Stable.
>
> Sincerely,
> [image: Google Logo]
> Peter Birk Pakkenberg
> Software Engineer
> pb...@google.com
> +447469379358 <+44%207469%20379358>
>
>
> On Mon, 11 Apr 2022 at 18:42, Joe Medley  wrote:
>
>> Peter,
>>
>> Do you know any release/availability dates yet? We need to add fields to
>> the Chrome Status
>> .
>>
>> On Thursday, April 7, 2022 at 8:59:53 AM UTC-7 Peter Birk Pakkenberg
>> wrote:
>>
>>> Hello blink-dev@
>>>
>>> We are hoping to begin rolling out origin trial support on WebView. The
>>> goal is to ensure that the origins who wish to test new Blink features can
>>> reach users in Android WebView as well.
>>> Launch Bugs
>>>
>>> http://crbug.com/1186236
>>>
>>> http://crbug.com/1308425 (internal launch bug)
>>> Summary
>>>
>>> We will soon enable origin trials on Android WebView, which means that
>>> clients will start to honour Origin-Trial headers for trials that target
>>> the Android platform in runtime_enabled_features.json5
>>> ,
>>> provided the feature is implemented for WebView. This means that a number
>>> of existing Blink trials will be enabled.
>>>
>>> The long term goal is to achieve parity between WebView and Chrome on
>>> Android when it comes to experimentation for features implemented in Blink,
>>> which has two key benefits to the Chromium project. First, it provides a
>>> large number of additional clients to test new Blink features. Due to the
>>> embedded nature of WebView, this will provide new insights into a part of
>>> the web ecosystem that has previously not been accessible to
>>> experimentation (for example hybrid apps). In turn, this will help to avoid
>>> surprises for feature developers who rely on origin trials to launch new
>>> features, which will hopefully lead to smoother feature launches.
>>> Why Now
>>>
>>> Planned features on WebView require origin testing, making it a
>>> necessity to enable the framework. Additionally, the longer origin trials
>>> remain disabled on WebView, the more likely it is that a trial misses an
>>> issue on WebView that could have been found, like it has happened in
>>> the past .
>>> Affected trials
>>>
>>> By our analysis, 14 trials
>>> 
>>> will be affected by the enablement on WebView. This means that they a) are
>>> targeting the Android platform, and b) have been implemented in shared code
>>> that is used by WebView. Other trials may rely on integrations in the
>>> embedder, which have not been implemented for WebView, which means that
>>> they won’t exhibit any new behaviour during the roll-out.
>>> Rollout plan
>>>
>>> WebView does not have good penetration on the dev/beta channels, so we
>>> will have to do the primary experiment on Stable. Given that we will be
>>> enabling all applicable origin trials on WebView at the same time as part
>>> of our feature roll-out, we expect full support to reach all WebView users
>>> in 3-4 weeks.
>>> Feedback from the Blink community
>>>
>>> We’d love to receive feedback and questions from the Blink community,
>>> either via this thread, in the launch bug
>>>  or
>>> privately. Some of the things that we’ve been thinking about:
>>>
>>>
>>>-
>>>
>>>Should targeting Android in runtime_enabled_features.json5 include
>>>or exclude WebView? We propose for it to be included as the majority of
>>>trials are either applicable to WebView as well, or have the 
>>> corresponding
>>>features disabled through other means in Chromium.
>>>
>>>-
>>>
>>>How should trial owners consider WebView metrics in their analysis?
>>>For Googlers, the UMA dashboards provide this ability, although WebView
>>>does not record UKM. Externally we’re investigating whether we can 
>>> publish
>>>WebView metrics as part of chromestatus.com, but that’s adjacent to
>>>this effort.
>>>
>>>-
>>>
>>>How should Web developers consider WebView usage? For the trials
>>>that are applicable to WebView, ideally they wouldn’t. WebView powers a
>>>significant share of browsing time on Android, so in most cases this is 
>>> an
>>>audience they already reach today, but (possibly unknowingly) isn’t 
>>> covered
>>>by their own experimentation
>>>
>>>
>>>
>>> Sincerely,
>>> [image: Google Logo]
>>> Peter Birk Pakkenberg
>>> Software Engineer
>>> 

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

['Joe Medley' via blink-dev]

Please ping me if it ends up being 103. I don't like missing things in the 
beta release post.

On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7 and...@chromium.org wrote:

> On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:
>
>> Are you aiming for 102?
>>
>
> That's branching very soon, so definitely not. I'm not really aiming for 
> any particular release. But if you want a prediction anyway, then likely 
> 104. 
>  
>
>>
>> On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:
>>
>>>
>>>
>>> On 4/11/22 15:02, Anders Hartvoll Ruud wrote: 
>>> > Ah, I'm not familiar with that way of doing compat research. What 
>>> would 
>>> > we gain from doing that vs. regular use-counter + HTTP Archive? 
>>> > 
>>> > Do we expect those 0.1% to visibly break? (I guess that depends on 
>>> > what they're feature testing for..) 
>>> > 
>>> > 
>>> > I would not expect that at all based on the HTTP Archive query. If 
>>> > testing against "not all" was commonplace, I'd expect more results 
>>> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it 
>>> > happens mostly on features that actually *are* supported at the 
>>> moment. 
>>> > 
>>> > Just as an example (and to show that "not all" testing isn't a myth), 
>>> > one of the few (non-Yandex-script) sites that did show up was 
>>> > https://ww.sapo.pt , which does the following: 
>>> > 
>>> > if(rule.mediaText.includes("not all") || ...) 
>>> > 
>>> > By the looks of it, it's an early-out related to the theme switching, 
>>> > which prevents the code from amending the query if 
>>> prefers-color-scheme 
>>> > is not supported. Had we not supported prefers-color-scheme, then I 
>>> > think the worst that could happen is that we end up with a more 
>>> > complicated query that still ultimately evaluates to false. Testing 
>>> the 
>>> > page with the feature enabled (with and without dark mode preference), 
>>> > their color switcher still works normally. 
>>> > 
>>> > That is just one site though, it's probably theoretically possible to 
>>> > write *something* that breaks. I did try to look at the "sample URLs" 
>>> > for the counters, but I couldn't actually reproduce the counters being 
>>> hit. 
>>>
>>>
>>> It's a thing that even Google DevRel people have recommended in the 
>>> past, ftr :) 
>>>
>>> https://web.dev/prefers-color-scheme/#supporting-dark-mode 
>>>
>>>
> Ouch ... 
>  
>
>> But if you have data to indicate this is not a problem in the wild I'd 
>>> be happy to implement it in Gecko after you ship this change. 
>>>
>>> Cheers, 
>>>
>>> -- Emilio 
>>>
>>

-- 
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/87a783d4-dbd7-4b0c-8ba1-7a118a87d759n%40chromium.org.

Re: [blink-dev] Re: Intent to Experiment: First "Locally-Executed Decision over Groups" Experiment (FLEDGE)

[Paul Jensen]

On Mon, Apr 11, 2022 at 3:22 PM Shaojie Wang  wrote:

> The feature "FLEDGE interest groups can also be viewed in Chrome’s
> Developer tools: in the "Application" tab, there is an "Interest Groups"
> item on the left side-bar that, when clicked, should display all interest
> groups that this page interacted with, e.g. when a page joins/leaves an
> interest group, bids on an auction, or wins an auction on this page then
> the interest group should show up." stated in the "Debuggability" section
> is useful. Are there any plans of its rollout?
>

This debugging functionality is included in this experiment.


> On Thursday, March 31, 2022 at 6:47:46 AM UTC-7 yoav...@chromium.org
> wrote:
>
>> LGTM to experiment till M104, inclusive
>>
>> On Thu, Mar 31, 2022 at 1:38 PM Paul Jensen 
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 30, 2022 at 5:53 AM Yoav Weiss  wrote:
>>>


 On Friday, March 25, 2022 at 11:46:45 PM UTC+1 Paul Jensen wrote:

> Contact emails
>
> paulj...@chromium.org , kle...@google.com
> 
>
> Developers interested in the FLEDGE API can also join the FLEDGE API
> announcements
> 
> group for updates and announcements.
>
> Explainer
>
> https://github.com/WICG/turtledove/blob/master/FLEDGE.md
>
> Specification
>
> May be heavily influenced by origin trial feedback, so not yet started.
>
> Summary
>
> FLEDGE provides a privacy advancing API to facilitate interest group
> based advertising.  FLEDGE shifts the interest data and the final ad
> decision browser-side instead of server-side, offering many advantages:
> strong privacy guarantees, as well as time limits on group membership,
> transparency into how the advertiser interest groups are built and used,
> and granular or global controls over this type of ad targeting.
>
> Blink component
>
> Blink
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/723
>
> (The first “F” and last “E” in FLEDGE stand for First Experiment, as
> such FLEDGE specifies a prototype for ads serving in the TURTLEDOVE 
> family,
> so the TAG review request was made for the overall family, TURTLEDOVE,
> rather than the first experiment specification, FLEDGE.)
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability
>
> Gecko: No signal
>
> WebKit: No signal
>
> Edge: Edge is also exploring interest group based advertising, namely
> with the PARAKEET proposal
> .
> PARAKEET shares much of its API with FLEDGE but has a different trust
> model.  Deployment experience is necessary to inform the choice between 
> the
> trust models.
>
> Web developers: Significant interest from many web advertising
> technology developers.  WICG FLEDGE calls
>  are heavily attended.
> Interest in FLEDGE is further evidenced by the many related discussions
> and proposals that FLEDGE design draws from, most notably:
>
>-
>
>The original TURTLEDOVE
>
>from Chrome.
>-
>
>SPARROW  from Criteo.
>-
>
>Outcome-based TURTLEDOVE
>
>and Product-level TURTLEDOVE
>
>from RTB House.
>-
>
>Dovekey
>
>from Google Ads.
>-
>
>PARRROT
>
> 
>from Magnite.
>-
>
>TERN  from
>NextRoll.
>
>
> Compatibility and WebView Application Risks
>
> FLEDGE does not deprecate or change existing web behavior, so there
> should be no compatibility risk.
>
> Activation
>
> Successful testing of FLEDGE in-browser ad auctions requires
> participation from both parties selling ad space and advertisers buying ad
> space.  This level of cooperation during an origin trial is a heavy lift,
> but one that seems feasible given the high level of interest we’ve seen
> from ad techs.
>
> Security
>
> FLEDGE involves downloading and running JavaScript functions, referred
> to as worklets.  Chrome runs worklets from different origins in separate

Re: [blink-dev] Re: Intent to Ship: Origin Private File System extension: AccessHandle

[Mike Taylor]

LGTM3

On 4/12/22 2:04 AM, Mike West wrote:

LGTM2.

-mike


On Tue, Apr 12, 2022 at 6:08 AM Yoav Weiss  wrote:

LGTM1

Thanks for pushing this through. Please make sure to follow-up on
any feedback we'd get on the PR itself.

On Mon, Apr 11, 2022 at 7:44 PM Emanuel Krivoy
 wrote:

Hello!

I've removed the options object from our implementation, and
filed a new PR against the WHATWG repo
(https://github.com/whatwg/fs/pull/21) that incorporates the
previous feedback.

Yoav:
Yes, we'd like to keep the current OT running and then ship on
102 without removing availability of the surface in between.

On Thu, Apr 7, 2022 at 12:38 PM Yoav Weiss
 wrote:



On Mon, Apr 4, 2022 at 5:11 PM Emanuel Krivoy
 wrote:

Hello,Replying to Mike inline:


https://github.com/WICG/file-system-access/pull/344
doesn't
seem to have moved in the last ~2 weeks, and I
don't see a new PR against the WHATWG spec. What's
y'all's timeline for finishing the specification
of this feature?


The plan is to create the PR against the spec in
WHATWG this week. It should include the changes from
the current feedback in the old PR.

Thanks for doing this investigation! It does sound
like something we'd want to resolve before
shipping, as it would be unfortunate for this to
present a barrier to interop.
I didn't see a bug filed against webkit in a quick
search, can you follow up on that (or point it out
if I missed it)?

I directly followed up with WebKit and the Storage
team. The result of the discussions was that, to avoid
compatibility issues with Safari and leave the design
of the options object fully open, we should
temporarily remove the options parameter from
createSyncAccessHandle().

Once there is consensus on how options should be
handled, it should be easy to add them back. We would
end up in the desired final state, but with an
inverted default: the OPFS Access Handle behavior is
the default one, and specific options would be needed
to use them in other file systems. Since the OPFS use
case is the one that has been proven with trials, and
the one that other browsers intend to implement for
now, I think it makes sense to leave it as the default.

To all:

Since we have to do code changes to remove the options
object, and since the spec still has to be rebased, I
wanted to change this request from shipment on 101 to
a gapless shipment on 102. I’ll keep working on those
two pending items and ping this thread when they are done.


Just to clarify, you're planning to run the OT till the
end of M101 and then gaplessly ship in M102?


Thanks!Emanuel

On Wed, Mar 30, 2022 at 3:01 PM Mike West
 wrote:

On Wed, Mar 23, 2022 at 5:48 PM Emanuel Krivoy
 wrote:

Hey Yoav,

So the plan is to land the PR in WICG, and
then (immediately) move it over to
https://fs.spec.whatwg.org/?
What are the current blockers for the WICG
PR from landing?


My plan would be to act on the current round
of feedback in the WICG PR and then move the
spec to its final home in WHATWG to finish the
review/merge there.
The situation is an artifact of me wanting to
do a quick round of feedback before investing
time in the rebase, just to make sure the spec
was going in the right direction. Now I think
it might have made things more confusing than
they should have been, sorry!


https://github.com/WICG/file-system-access/pull/344
doesn't seem to have moved in the last ~2 weeks,
and I don't see a new PR against the WHATWG spec.
What's y'all's timeline for finishing the
specification of this feature?

Have you tried running 

[blink-dev] Re: Intent to Enable Origin Trial support on Android WebView

['Peter Birk Pakkenberg' via blink-dev]

Hi Joe,

Yes, we are planning to start the roll out once M102 has launched on Stable.

Sincerely,
[image: Google Logo]
Peter Birk Pakkenberg
Software Engineer
pb...@google.com
+447469379358


On Mon, 11 Apr 2022 at 18:42, Joe Medley  wrote:

> Peter,
>
> Do you know any release/availability dates yet? We need to add fields to
> the Chrome Status
> .
>
> On Thursday, April 7, 2022 at 8:59:53 AM UTC-7 Peter Birk Pakkenberg wrote:
>
>> Hello blink-dev@
>>
>> We are hoping to begin rolling out origin trial support on WebView. The
>> goal is to ensure that the origins who wish to test new Blink features can
>> reach users in Android WebView as well.
>> Launch Bugs
>>
>> http://crbug.com/1186236
>>
>> http://crbug.com/1308425 (internal launch bug)
>> Summary
>>
>> We will soon enable origin trials on Android WebView, which means that
>> clients will start to honour Origin-Trial headers for trials that target
>> the Android platform in runtime_enabled_features.json5
>> ,
>> provided the feature is implemented for WebView. This means that a number
>> of existing Blink trials will be enabled.
>>
>> The long term goal is to achieve parity between WebView and Chrome on
>> Android when it comes to experimentation for features implemented in Blink,
>> which has two key benefits to the Chromium project. First, it provides a
>> large number of additional clients to test new Blink features. Due to the
>> embedded nature of WebView, this will provide new insights into a part of
>> the web ecosystem that has previously not been accessible to
>> experimentation (for example hybrid apps). In turn, this will help to avoid
>> surprises for feature developers who rely on origin trials to launch new
>> features, which will hopefully lead to smoother feature launches.
>> Why Now
>>
>> Planned features on WebView require origin testing, making it a necessity
>> to enable the framework. Additionally, the longer origin trials remain
>> disabled on WebView, the more likely it is that a trial misses an issue on
>> WebView that could have been found, like it has happened in the past
>> .
>> Affected trials
>>
>> By our analysis, 14 trials
>> 
>> will be affected by the enablement on WebView. This means that they a) are
>> targeting the Android platform, and b) have been implemented in shared code
>> that is used by WebView. Other trials may rely on integrations in the
>> embedder, which have not been implemented for WebView, which means that
>> they won’t exhibit any new behaviour during the roll-out.
>> Rollout plan
>>
>> WebView does not have good penetration on the dev/beta channels, so we
>> will have to do the primary experiment on Stable. Given that we will be
>> enabling all applicable origin trials on WebView at the same time as part
>> of our feature roll-out, we expect full support to reach all WebView users
>> in 3-4 weeks.
>> Feedback from the Blink community
>>
>> We’d love to receive feedback and questions from the Blink community,
>> either via this thread, in the launch bug
>>  or
>> privately. Some of the things that we’ve been thinking about:
>>
>>
>>-
>>
>>Should targeting Android in runtime_enabled_features.json5 include or
>>exclude WebView? We propose for it to be included as the majority of 
>> trials
>>are either applicable to WebView as well, or have the corresponding
>>features disabled through other means in Chromium.
>>
>>-
>>
>>How should trial owners consider WebView metrics in their analysis?
>>For Googlers, the UMA dashboards provide this ability, although WebView
>>does not record UKM. Externally we’re investigating whether we can publish
>>WebView metrics as part of chromestatus.com, but that’s adjacent to
>>this effort.
>>
>>-
>>
>>How should Web developers consider WebView usage? For the trials that
>>are applicable to WebView, ideally they wouldn’t. WebView powers a
>>significant share of browsing time on Android, so in most cases this is an
>>audience they already reach today, but (possibly unknowingly) isn’t 
>> covered
>>by their own experimentation
>>
>>
>>
>> Sincerely,
>> [image: Google Logo]
>> Peter Birk Pakkenberg
>> Software Engineer
>> pb...@google.com
>> +447469379358 <+44%207469%20379358>
>>
>

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

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

[Mitar]

Hi!

Kenji, I have been following progress around HTTP2 push and it looks to me
that all the focus is on HTTP2 pushes which happen at the page loading
time. But there are also pushes which happen later on, after the page has
already loaded. Concrete example: I have an app which subscribes to
notifications from the server (using SSE or WebSockets), when it gets a
notification that some resource changed, the app makes a HTTP request to
fetch the new resource (to then update DOM reactively). By separating
notification from payload and not pushing data itself over WebSocket, those
resources can be cached so that the next time the page loads they can be
reused. With HTTP2 push the server can send the resource to the client
together with the notification itself, so that data is available together
with the notification. I do not see something like possible with Early
Hints?

Another limitation of Early Hints seems to be that resources which require
Authorization header cannot be preloaded, am I mistaken? With HTTP2 push
you can push such a resource and add a corresponding anticipated header.


Mitar

On Wed, Mar 16, 2022 at 7:05 AM Kenji Baheux 
wrote:

> Hi Thomas,
>
> I'm part of the team working on Early Hints.
>
> On Wed, Mar 16, 2022 at 6:58 AM BIANCONI Thomas <
> thomas.bianc...@loreal.com> wrote:
>
>> I am sad to read this...
>> A new step before the deprecation of server push.
>>
>> I would love to see comparaison in term of performance between server
>> push and early hint.
>> On a pure theoric point of view early hint starts during the html parsing
>> whereas the server push start with the response header. So server push by
>> design is better.
>>
>
> If I understand correctly, I believe that there is some misunderstanding
> about Early Hints.
> Clearly, it's on us to make this easier to understand. Sorry...
> We'll put extra efforts in providing clear & detailed developer
> documentation when Early Hints ships.
>
> In the meantime, here is a high level summary of what Early Hints is, and
> how it works:
>
>1. Early Hints is a status code (103) which is used in HTTP responses
>while the server is preparing the final response. This intermediate
>response can include other HTTP headers, in particular LINK REL headers
>such as preload or preconnect.
>2. In some cases, it can take time for the server to prepare the main
>response: accessing the DB, having an edge cache go talk to the origin
>server, etc. So, the idea is to speed up overall page load times by giving
>the browser hints about what it might do while waiting for the actual
>response. Typically, the hints are about critical sub-resources or origins
>which would be used by the final response.
>3. The browser processes these hints, and decides to preconnect or
>preload any missing origins/resources while waiting for the final 200 OK
>response (usually containing the main resource). Since the browser got some
>work done ahead of time, the overall page load time is improved.
>
> In other words, the key point here is that Early Hints doesn't start
> during the HTML parsing: it starts with the non-final response headers, way
> before HTML parsing kicks in since that is blocked on the final response.
>
> See this section of the RFC
> 
> for an example of how this looks at the HTTP level.
>
>
>
>
>> Regarding the complexity to put it in place early hints is easy when you
>> serve different page but for Single Page Application the build process
>> don't generate differentiate serving based on the route since the routing
>> of the application is generally managed in the frontend.
>> So for Single Page Application to managed server push not global to all
>> route it will more complexe to include it in the build process.
>>
>
> The MPA angle is indeed easier, deployment wise.
> We'll look into the SPA case in more details including discussion with
> various framework authors.
>
> I hope this was useful.
>
>
>>
>> Just wanted to share my feeling about this whole topic.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards
>>
>>
>>
>> *Thomas BIANCONI*
>>
>> Head of Data Technologies
>>
>> & Data Privacy Champion
>>
>> Global CDMO Team
>>
>> 41 Rue Martre - 92110 Clichy
>>
>> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057>
>>
>> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095>
>>
>> *E-mail* : thomas.bianc...@loreal.com
>>
>> --
>> *De :* Chris Harrelson 
>> *Envoyé :* mercredi 2 mars 2022 18:51
>> *À :* Daisuke Enomoto 
>> *Cc :* blink-dev ; las...@chromium.org <
>> las...@chromium.org>; pme...@chromium.org ;
>> Francesco Montanari ; Maxim Makarov <
>> maxpain...@gmail.com>; b...@chromium.org ;
>> dsch...@chromium.org ; ians...@chromium.org <
>> iansw...@chromium.org>; 

[blink-dev] Re: Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Anders Hartvoll Ruud]

On Mon, Apr 11, 2022 at 1:40 PM Anders Hartvoll Ruud 
wrote:

> Contact emails
>
>
> *andr...@chromium.org kbabb...@microsoft.com
> *Explainer
>
>
>
> *NoneThis article by Bramus
> 
> may be helpful.*Specification
>
>
> *https://www.w3.org/TR/mediaqueries-4/#mq-range-context
> *Summary
>
>
>
>
> *Allows writing media queries using ordinary mathematical comparison
> operators , and
> adds support for or
> , not
> , nesting
> , and the
> special evaluation of “unknown”
> 
> features.Tiny example:Without this feature: @media (min-width: 100px)With
> this feature: @media (width >= 100px)*Blink component
>
>
> *Blink>CSS
> *TAG
> review
>
>
> *Probably not needed(?)*TAG review status
>
>
> *Not applicable*Risks
>
> Interoperability and Compatibility
>
>
>
>
> *Gecko: Shipped/Shipping
> (https://bugzilla.mozilla.org/show_bug.cgi?id=145
> ) Except: - Support
> for ``, due to concerns that are discussed below.- The
> `  ` form, due to Issue 2791
> , which was resolved as
> no-change.WebKit: I sent an e-mail to webkit-dev just now. I’ll update
> if/when I get a response. Related info: @container, which is implemented in
> Safari TP, uses an almost identical syntax, so there appears to be no
> fundamental objections, at least.*
>

Update: support from Webkit:
https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30451.html


>
>
> *Web developers: No signalsOther 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?One
> significant concern (raised by Emilio) is regarding the
> “unknown”/ evaluation. Currently, a media query like
> @media (unknown: 500kg) will parse to (and serialize as) “@media not all”.
> (In mediaqueries-3, a media query with unknown parts doesn't fail parsing
> in the normal sense, but instead becomes “not all”
> ).
> The concern is that authors compare the parsed result of a media query
> condition against “not all” in order to detect features. For example:let
> prefersContrastSupported = matchMedia("(prefers-contrast)").media != "not
> all";With this I2S, prefers-contrast (and any other unknown feature
> matching ) will appear to parse successfully, and won’t
> be converted to “not all” anymore.To understand the impact of this, I added
> some use-counters for various APIs which count whenever a media query that
> would contain  is serialized:Window.matchMedia | ~0.1%
> MediaList::mediaText
> | ~0.1%
> CSSConditionRule.conditionText
> | ~0.007%
> Note:
> Chromestatus has a bug where the name does not show up for these counters.I
> then queried HTTP Archive for response bodies containing `not all` (in
> quotes) from sites that hit one of the above use-counters, and the results
> show that it’s almost entirely coming from the following two scripts [full
> data
> ]:
> - https://mc.yandex.ru/metrika/tag.js
> -
> https://mc.yandex.ru/metrika/watch.js
> However, looking at the live version
> of those files in Chrome (Desktop), I can’t find “not all”. It would appear
> that they don’t use this technique anymore. (Or I’m not using the right
> headers/User-Agent in the request).This research is not perfect, e.g. there
> could be other ways of doing feature detection that does not involve “not
> all”, or people could be using .cssText, and I assume not the entire web is
> in the HTTP Archive. But overall I’m fairly confident that it’s not an
> exceedingly common practice. The risk seems worth the gain of avoiding
> future-proofing mistakes
> 
> for media queries.*Debuggability
>
>
>
> *The new syntax is automatically visible in devtools.*Is this feature
> fully tested by web-platform-tests
> 

[blink-dev] Re: Intent to Ship: Origin Private File System extension: AccessHandle

[Mike West]

LGTM2.

-mike


On Tue, Apr 12, 2022 at 6:08 AM Yoav Weiss  wrote:

> LGTM1
>
> Thanks for pushing this through. Please make sure to follow-up on any
> feedback we'd get on the PR itself.
>
> On Mon, Apr 11, 2022 at 7:44 PM Emanuel Krivoy 
> wrote:
>
>> Hello!
>>
>> I've removed the options object from our implementation, and filed a new
>> PR against the WHATWG repo (https://github.com/whatwg/fs/pull/21) that
>> incorporates the previous feedback.
>>
>> Yoav:
>> Yes, we'd like to keep the current OT running and then ship on 102
>> without removing availability of the surface in between.
>>
>> On Thu, Apr 7, 2022 at 12:38 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Apr 4, 2022 at 5:11 PM Emanuel Krivoy 
>>> wrote:
>>>
 Hello,

 Replying to Mike inline:

 https://github.com/WICG/file-system-access/pull/344 doesn't seem to
> have moved in the last ~2 weeks, and I don't see a new PR against the
> WHATWG spec. What's y'all's timeline for finishing the specification of
> this feature?


 The plan is to create the PR against the spec in WHATWG this week. It
 should include the changes from the current feedback in the old PR.



> Thanks for doing this investigation! It does sound like something we'd
> want to resolve before shipping, as it would be unfortunate for this to
> present a barrier to interop.
>
> I didn't see a bug filed against webkit in a quick search, can you
> follow up on that (or point it out if I missed it)?



 I directly followed up with WebKit and the Storage team. The result of
 the discussions was that, to avoid compatibility issues with Safari and
 leave the design of the options object fully open, we should temporarily
 remove the options parameter from createSyncAccessHandle().



 Once there is consensus on how options should be handled, it should be
 easy to add them back. We would end up in the desired final state, but with
 an inverted default: the OPFS Access Handle behavior is the default one,
 and specific options would be needed to use them in other file systems.
 Since the OPFS use case is the one that has been proven with trials, and
 the one that other browsers intend to implement for now, I think it makes
 sense to leave it as the default.



 To all:



 Since we have to do code changes to remove the options object, and
 since the spec still has to be rebased, I wanted to change this request
 from shipment on 101 to a gapless shipment on 102. I’ll keep working on
 those two pending items and ping this thread when they are done.

>>>
>>> Just to clarify, you're planning to run the OT till the end of M101 and
>>> then gaplessly ship in M102?
>>>
>>>

 Thanks!
 Emanuel

 On Wed, Mar 30, 2022 at 3:01 PM Mike West  wrote:

> On Wed, Mar 23, 2022 at 5:48 PM Emanuel Krivoy 
> wrote:
>
>> Hey Yoav,
>>
>>
>>> So the plan is to land the PR in WICG, and then (immediately) move
>>> it over to https://fs.spec.whatwg.org/?
>>> What are the current blockers for the WICG PR from landing?
>>>
>>
>> My plan would be to act on the current round of feedback in the WICG
>> PR and then move the spec to its final home in WHATWG to finish the
>> review/merge there.
>> The situation is an artifact of me wanting to do a quick round of
>> feedback before investing time in the rebase, just to make sure the spec
>> was going in the right direction. Now I think it might have made things
>> more confusing than they should have been, sorry!
>>
>
> https://github.com/WICG/file-system-access/pull/344 doesn't seem to
> have moved in the last ~2 weeks, and I don't see a new PR against the
> WHATWG spec. What's y'all's timeline for finishing the specification of
> this feature?
>
> Have you tried running STP against the WPT test suite? That could be
>>> reassuring interop-wise
>>>
>>
>> Thanks for the suggestion. After running the WPTs, there seems to be
>> some divergence with the proposed spec. The most substantial one (beyond
>> some issues around the type of error thrown) is that the implementation 
>> of
>> createSyncAccessHandle in Safari TP does not take an options parameter.
>>
>> The options parameter is there to (eventually) allow using access
>> handles on other filesystems (i.e., from outside OPFS, in particular on
>> files hosted in the local file system). This feature has been requested 
>> by
>> developers on various occasions, and would make the File System Access 
>> API
>> more flexible. In our implementation, the options parameter is required 
>> (as
>> in, has to be provided when calling createSyncAccessHandle) to avoid
>> setting the default behavior of access handles to the particular