Alex Christensen, Vivek Sekhar, Nicolás Peña, Ryosuke Niwa, Benjamin de Kosnik, Steven Bougon, Gilles Dubusc, Philippe Le Hegaret, Ilya Grigorik, Yoav Weiss, Subrata Ashe
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
Yoav: there are fundamental issues with TAO.
… One of them is related to nextHopProtocol: see issue. And then there are other issues related to the fact that nextHopProtocol is not TAO protected at all.
… Pending PR 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.
... 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.