Re: WebPerfWG call - September 6th @ 10am PT

Hey all,

Minutes
<https://docs.google.com/document/d/e/2PACX-1vRlYREbiNMpyS3JPRfzxi884LRqVhIxMOOkgMXQFcmigvQlQ1Rab4D33Rw7ABAdh9ZHFiCheQkEqKNL/pub>
and video <https://www.youtube.com/watch?v=yYzX1dNJkuw> from the call are
now available. Copying the minutes here for safe keeping:

WebPerfWG minutes - September 6th 2019

Participants:

Giles Dubuc, Todd Reifsteck, Ilya Grigorik, Yoav Weiss, Philippe Le
Hegaret, Steven Bougon, Vivek Sekhar, Ryosuke Niwa, Benjamin De Kosnick,
Thomas Kelly, Nate Schloss, Nic Jansma
Administrative

   - [Philippe]: Ralph tried to talk to Tim, a week ago, and Tim came with
   a proposal. Ralph will come to TPAC at the f2f Tuesday after the break, to
   talk about High Resolution 2 (HR2). Context: privacy folks had some
   feedback on this spec, which we closed, but they formally objected to move
   HR-2 to next steps. So, at this point, we don’t have a decision, but it’s
   moving :-)

Design

   - Signed Exchange, Bundles , Portals
   <https://www.google.com/url?q=https://docs.google.com/presentation/d/1UdeTNTqJmixnz_6mzGs5me4ypF5nRVxQ6gS7Xc7MLKw/edit%23slide%3Did.g5e764ecbda_2_56&sa=D&ust=1568020426238000>,
   what it means for WebPerf.
   - [yoav] wanted to talk about it at F2F. Anyway, Chrome wants to ship
   some APIs regarding this, though there is no consensus from other UA. here,
   we will talk about how it relates to perf.


   - Signed exchange: goal is to decouple the “where it comes from” from
   “where it’s serves”. One issue is that it does not provide confidentiality (
   b.com knows that something from a.com was served). The browser treats it
   like an internal redirect.
   - Use case:


   - Privacy preserving prefetch: SXG allows services to prefetch without
   the origin to know about it
   - Offline PWA installs: enables various offline caches (but problem with
   sign discovery).


   - Regarding Perf and SXG: additional steps: the browser needs to
   download and verify the certificate chain (extra hop). Do we want to expose
   that the content came from SXG ? Can we expose the distributor ?


   - [todd] The issue is against NavTiming. I assume it also applies to
   Resource Timing
   - [yoav] We mainly talk about SXGs in the context of navigation
   responses, because of how they are used today, but theoretically can also
   apply to stand-alone resources. (e.g. for some CDN use cases)
   - [Ilya] Nothing stops you from using SXG on a subresource, it’s just
   not a use-case we’ve seen tried.
   - [todd] Feels it should be fixed in resource Timing not in navigation
   timing.
   - [yoav] Probably a L3 issue, where we are planning to merge both specs,
   so it won’t matter much. But you’re right.
   - [Ilya] Issue 107 . The non-controversial bit is exposing that
   something was served from an SXG. Exposing a validation timestamp would
   give us that.
   - The bit we still need to figure out is how much we can expose about a
   specific distributor.
   - [Ilya] content was distributed by X distributors. How do we know the
   perf of each distributor? We’re still working out details and what would be
   the privacy and security implications of that. But as a first step, we
   should define validation start (though clearly L3 work).
   - [benjamin] Re 107: is it paused till WebPackaging folks figure out
   next step?
   - [Ilya] More or less, but we should break down the issues (some
   controversial and some not)
   - [benjamin] Do we just need to provide validation timing?
   - [Ilya] we would add a step for validation which will let you know that
   you loading from the SXG, and how long the validation step took.
   - [benjamin] Exposing certification validation time in SXG seems
   essential.
   - [benjamin] Chrome devtools have this concept of internal redirect.
   Would love to see internal redirect defined as a new type of redirects.
   - [Ilya] true, we call it “Internal redirect” though not currently spec’d
   - [benjamin] Need to be spec’d. Bring it on at TPAC ?
   - [Ilya] First use case for “Internal redirect” in Chromium is HSTS
   - [benjamin] yeah, let’s talk about “Internal redirect” to make it a
   standard.
   - [Ilya] Also, we’ve seen cases where internal redirects take a lot of
   time, so need to be measured
   - [benjamin] yeah, same here for cert validation
   - [ryosuke] We are implementing HSTS in the CFNetwork library, but SXG
   will not be implemented there. So if they are both using the same
   mechanism, that may cause implementation challenges.
   - [benjamin] The terms transport origin and certificate origins seem to
   be new terminology, where are they defined ?
   - [yoav] Defined in the WebPackaging WICG repo
   <https://www.google.com/url?q=https://github.com/WICG/webpackage&sa=D&ust=1568020426240000>.
   Discussions on creating an IETF WG for that
   - [benjamin] Seems of great importance to properly define these new
   concepts
   - [benjamin] One more question - why do we want to hide resource fetches
   from the origin?
   - [yoav] Resource prefetch. Prefetching resource before user has shown
   interest (eg: site a.com have links to b.com, c.com. Site a.com wants to
   prefetch these links. Prefetching might leak some intent that the user
   hasn’t expressed yet). For example, google search result might want to
   prefetch sites without the sites knowing it.
   - [benjamin] The user didn’t ask for those prefetches, so that’s not a
   user problem we’re solving.
   - [yoav] Performance is the user’s problem. Cross-origin prefetch solves
   a real performance problem, and doing it privately requires something like
   SXG as a primitive.
   - [benjamin] can a user turn off prefetching?
   - [Ilya] really good (product) question. Let’s defer that to the SXG
   people (who will be in TPAC)
   - [todd] It’s possible from fetch to do CO requests. It’s not a new
   privacy leak
   - [yoav] not new. SXG makes cross-origin requests less privacy invasive


   - Bundles Exchange


   - Bundled exchange is a concept that used to be with SXG, but now is
   split. It’s very similar to multi-part resource bundle, but it’s not awful.
   Various use case:


   - Prefetch for sub-resources
   - More performant for ES module
   - PWA in app store: still from origin, but delivered by the app store


   - Resource Timing:


   - We will know if it served from a bundle or not
   - Bundles are progressively parsed. We are introducing the parsing
   over-head of bundles as something that will impact individual resource’s
   start and end times


   - [todd] are you talking about client side parsing or server-side +
   range requests? can range requests work with bundles?
   - [yoav] I’m speaking of client side parsing. Range requests can work
   but once you compress the bundle as a single resource, but then all bets
   are off for range requests.
   - [yoav] The scenario to consider is navigation for foo.html (containing
   foo.js, etc). Browser receives the bundle. See that it gets foo.html, mark
   the timestamp, and only then gets foo.js, even though the overall bundle
   may still continue loading. So we are mixing download and parsing time.
   - [todd] but if I ask for a subset of the bundle ?
   - [yoav] not sure if a portion of a bundle can be parsed out of context.
   Jeffrey Yasskin is the person to talk to for details on that.
   - [todd] If it downloads the whole bundle, and we get foo.html, and at
   that point mark that resource’s start time. Doesn’t quite fit the model we
   have today
   - [yoav] Yeah, at least if we want to be getting the granularity we have
   today.
   - [todd] so if we just expose the bundle start and end time, it will
   hide subresource timing, and potential slowness if the bundles are built in
   a streaming server. Is that information needed?
   - [yoav] Format doesn’t support building on-the-fly, only on-the-fly
   subsetting. Otherwise, if we don’t expose start and end time, then we have
   a monolith bundle and we will hide all the internal bundle, so we will
   never know why a JS did not start the parsing on time. In the extreme, a
   site delivered over a single bundle will have the same start and end times
   for all subresources.
   - [todd] it’s like inlining JS, you don’t have the information
   - [yoav] correct. But not ideal
   - [todd] Sure, but how urgent is it?
   - [nic] our customers would like to know which resource is large, small,
   came with the bundle
   - [todd] today, we don’t know parse time. It can start any time. With
   bundle, we will lose information. But trying to see if timing here is
   really needed.
   - [yoav] yes, in-bundle timing is needed as much as resource timing is
   needed. If a bundle is bloated or mis-ordered the bundle, you’d want to
   know. Needs more thought.
   - [todd] Should we talk about exposing parse time in general?
   - Here, we should talk about exposing the parse time of the bundle, for
   resource discovery (not the JS itself).
   - [nic] would there be info about bundle content not used by the page
   - [yoav] in today’s model, resources in the bundle but not on the page
   won’t be exposed
   - [todd] Would a resource in a bundle also have an RT entry?
   - [yoav] it should be

TPAC

   - Agenda is here
   <https://www.google.com/url?q=https://docs.google.com/document/d/1-xMvUHAjqhQdegNqupxlqsLbfPHWq5MJ0iySg9Z1KBs/edit%23&sa=D&ust=1568020426243000>
   .
   - Monday for designs and Tuesday for issue discussion and progress
   - [benjamin] LCP implementation experience session?
   - [steven] metrics for SPA?
   - [yoav] We should block a couple of hours for that. Also, a related
   discussion about resetting the history API which may be related.
   - [Ilya] Also - CompressStream. Exposing an api to compress the data on
   the client. Incubated in Japan team in Chrome. We should try to schedule
   - [nate] planning to join that effort. Andrew was hoping to talk about
   that
   - [nate] isInputPending: is there a consensus to go from WICG -> WebPerf?
   - [yoav] so admin discussion
   - [todd] Is there something about isRenderingPending?
   - [yoav] I can check with Stefan Zager
   - [todd] Also for Frame Timing, let’s schedule it late so Noam can join
   - [yoav] Maybe we can do 1½ day for Design, ½ day for issue, if not a
   lot of issues to discuss.
   - [todd] people may want to some in-person work/spec reviews
   - [yoav] sure, but that doesn’t require the entire group
   - [benjamin] makes sense to prioritize design where we’d be getting a
   large amount of cross-section collaboration



On Thu, Sep 5, 2019 at 7:16 PM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Join us tomorrow for a mixed call - we'll talk some design and then TPAC
> planning. Originally we talked about having a 2 hour meeting, but since we
> don't have a lot on the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.rsdo5zbg5uq0>
> at the moment, it seems like 1 hour may suffice to cover both.
>
> If you have any agenda items you want to discuss, feel free to add them.
>
> See y'all tomorrow! :)
> Yoav
>