Re: WebPerfWG call - Thursday February 27th @ 2020

Minutes
<https://docs.google.com/document/d/e/2PACX-1vTzcPIBF1ZbjuE1bq2ScuUKhbV0YDjUWGaa5220_1DrgbnUFymaIx2yOYlgZIVCOzDN3z4gnZL46eXo/pub>
and video <https://www.youtube.com/watch?v=C3XTcGqHX00&feature=youtu.be>
from the call are now available. Copying the minutes here for safe keeping:
WebPerfWG call - Feb 27 2020
Participants

Alex Christensen, Vivek Sekhar, Nicolas Pena, Ryosuke Niwa, Benjamin de
Kosnik, Steven Bougon, Gilles Dubusc, Philippe Le Hegaret, Ilya Grigorik,
Yoav Weiss, Subrata Ashe

F2F

   - Corona is a risk
   - Investigate online alternatives
   - Remote participation
   - Monitor the situation
   - PLH: working on online alternative to F2F


   - Smaller chunks of time rather than full days

Ablation experiments
<https://www.google.com/url?q=https://github.com/vsekhar/browser-ablation&sa=D&ust=1583848966736000>

Vivek: Motivation is justifying investment in performance

… Some sites are sensitive for FCP, others are more sensitive to FID and CLS

… Understanding the motivation for an individual property to invest in
performance is critical

… The mechanism in the browser is focused on getting ablation -
artificially inserted delays - to . see the impact of that delay.

… Better than performing those same delays in JS

… The mechanism is to provide what delays are needed and when

… But the idea is for an analytics provider to be able to inject ablation
to measure how sensitive would the site’s business metrics be to
performance impact

Ryosuke: So ability to add artificial delay to the metrics measured?

Vivek: delaying the UX, reflected in metrics

Ryosuke: So actually making things slower?

Vivek: yeah, artificially making things slower to a small group of users to
measure impact

Ryosuke: Why can’t that be done in script?

Vivek: some can be done in script, but some can’t. (e.g. delay the initial
JS load). Otherwise, some of those metrics are hard to effect directly, and
that can reduce their statistical value

Benjamin: can this be used for memory footprint?

Vivek: we’ve done that internally. No details right now.

Ben: interested in details on that. Let me know if you can share

Vivek: Important to understand which aspects of performance are made
possible by this. Can add those to the proposal.

Benjamin: Would you be interested in separating browser memory from JS
memory? When I envision it used at Mozilla, this is how I’d use it.

Steven: For salesforce it won’t be a useful API, because we don’t have
conversion metrics. Delaying the UX won’t help much. Nic Jansma commented
online that this will be useful for Akamai.

Gilles: It sounds interesting. For us it can be useful even for synthetic
testing. Definitely something we would play with. This will make it easier
to try out ablation. Thumbs up from me.

Steven: For Wikipedia’s case, you’d add a delay to 10% of your population -
what will you look at? Drop in visits and session length?

Gilles: yeah

Steven: how would it help you to improve your site?

Gilles: If we can apply it to many different metrics, it can tell us which
metrics are more important than others. E.g. FID is a new metric and we
don’t know if it’s important or not.

… Currently hard to say which metric matters most, and this will help
prioritize. We have engineers pushing features, and we need to make tough
choices about metrics we care about. This can help on that front.

… With anecdata we can get some of it, but this can help us explore extreme
scenarios which may not happen naturally in the field.

… Example: someone came up with metric that measures the amount of times
things changed. … Does avoiding many paints matter? With something like
this we could explore something like that. Would help to make sense of the
weights of steps in UX and how it impacts engagement.

Steven: thank you.

Vivek: So as part of a multi-step flow, apply delay on different steps and
see which step matters

Gilles: Also about unrelated metrics, see which one matters. Easy to focus
on loading pages faster, but not sure it’s the right thing.

… Should we improve the median or should we focus on the extreme scenario?
By definition the extreme doesn’t happen often so hard to gather data

This can shift the focus towards higher percentiles
Resource Timing and Timing Allow Origin

Yoav: there are fundamental issues with TAO.

… One of them is related to nextHopProtocol: see issue
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/221&sa=D&ust=1583848966740000>.
And then there are other issues related to the fact that nextHopProtocol is
not TAO protected at all.

… Pending PR
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/224&sa=D&ust=1583848966741000>
for
partially protecting it for iframe resources, but perhaps the right
approach is to fully protect it. Besides that, TAO is not necessarily the
right opt-in for some of the things that are currently exposed under
Resource Timing.

… CORP could be the gate to allow memory measurement. Exposing transfer
sizes has similar characteristics to the information that, for example,
memory measurement can expose. So it seems that we would need to modify
some of the opt-ins.

… We need to clarify which characteristics of each of the metrics fits
which opt-ins.

… Timing allow check would be implied by CORS opt-ins, and should also be
implied by CORS opt-ins. But some of the information we expose by TAO
doesn’t fit the risk model of timing very well.

Ryosuke: where are these concrete concerns?

Yoav: issue 221 regarding nextHopProtocol. It can tell things about the
user. If a user is in a network that has an MITN terminator or antivirus,
there are cases where this value could reveal details about the user’s
network.

Ryosuke: that’s not a cross-origin issue.

Yoav: that one is not, though there are some cross-origin issues around
service workers.

Ryosuke: what are those concerns?

Yoav: whether service worker is installed or not can be inspected by
creating an iframe and inspecting the nextHopProtocol of that.

Ryosuke: a.com loads b.com and can deduce if it has a service worker. Only
an issue without double key caching?

Yoav: yea, partitioning makes that specific concern go away.

Ryosuke: if a.com has a random image, it won’t use service worker.

Yoav: if it’s a subresource, it goes through a.com’s service worker. If
it’s within iframe, then it will use b.com’s service worker.

Ryosuke: You could still detect if a site has a SW if registration happened
in iframe, but there’s no information leak there. I guess that if a client
certificate authenticates a website, and the SW is only installed in the
authenticated case that could be detectable across origins.

Yoav: not something websites would do. You could detect if a website has
sw, but that’s not sensitive information.

Ryosuke: unless the presence is predicated on some user login. If we have a
resource inside an iframe, we do not report that resource. So only iframe
itself could expose the presence. Did we lock load events for iframes in
cross origin cases?

Yoav: if you can successfully block that, some people will be very happy.
But it does fire at the moment. And I expect compat issues if it stopped
firing.

… Ok, so there’s nextHopProtocol, and the general history leaks described
by the PING.

… They have multiple scenarios, most of which go away with partitioning,
except for one of them, which is extracting information about cookies being
sent: issue 222
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/222&sa=D&ust=1583848966743000>
.

... Exposing transfer sizes for credentialed resources means that length of
cookies can be deduced, and various things can be concluded from that.

… The PING folks suggested blocking wildcard from TAO, which doesn’t make
sense and doesn’t solve the issue.

… Perhaps we can modify transfer sizes to exclude cookies. Alternatively,
we’d gate those on something like CORP.

… One complaint is that new stuff (not just timing but other dimensions)
was added between L1 and L2, but the opt-in remained the same.

npm: do people agree that getting rid of TAO * is the wrong solution there?

Ilya: yea, those are orthogonal issues.

Ryosuke: for transferSize, sure, but there’s also a couple of other issues.
I don’t think.

Yoav: three solved by partitioning, the last is the cookie one. Blocking
TAO * won’t solve any of those problems.

Ryosuke: So you claim the only issue we should look at is the cookie issue?

Yoav: everything else will be resolved by partitioning in all modern
browsers very soon. I’m assuming it includes DNS and network connection.
That’s the plan for Chrome, but worthwhile to verify this is the case in
Safari and Firefox.

Ryosuke: I don’t know.

Yoav: assuming we have agreement on TAO * being the wrong solution, do we
have agreement on making sure that excluding cookies is the right solution?
Or other opt-ins? Is this something you need to take some time to review?

Ryosuke: the DNS cache is an issue: we don’t want that information to be
exposed. Same thing with HSTS, and reused connection. There’s a privacy
aspect of this being used as a tracking vector. Removing TAO * won’t help
though.

Yoav: could you look into the proposed mitigation, which is to eliminate
cookie sizes from the response?

Ryosuke: we don’t implement transferSize due to that security issue.

Yoav: Is that the only blocker?

Ryosuke: I don’t know, I think there’s a couple others.

Yoav: can you document those concerns?

Ryosuke: at some point, yes.


On Wed, Feb 26, 2020 at 10:34 PM Yoav Weiss <yoav@yoav.ws> wrote:

> And the title should've said "@10am PST"...
>
> On Wed, Feb 26, 2020 at 10:32 PM Yoav Weiss <yoav@yoav.ws> wrote:
>
>> Hey folks,
>>
>> Let's meet <https://meet.google.com/agz-fbji-spp> tomorrow to talk about
>> web performance!
>> On the agenda
>> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.3id4winelwz1>
>> we have a proposal for an ablation API
>> <https://github.com/vsekhar/browser-ablation>, as well as a discussion
>> about various TAO related issues. If you have other items you'd like to
>> discuss, feel free to add them to the agenda, and we'll try to squeeze them
>> in.
>>
>> As always, the call will be recorded and posted online.
>>
>> See y'all tomorrow!
>>
>> Cheers :)
>> Yoav
>>
>