Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add delivery type to PerformanceResourceTiming. #343

Merged
merged 4 commits into from Mar 13, 2023

Conversation

jeremyroman
Copy link
Contributor

@jeremyroman jeremyroman commented Aug 30, 2022

Addresses #332.

This defines a concept of "delivery type" which currently describes the difference between resources delivered from the HTTP cache and those not (currently only detectable via transferSize). It is expected to be extended to describe resources delivered from other stores, such as the consuming resources from the HTML preload buffer and navigational prefetches.


Preview | Diff

@jeremyroman
Copy link
Contributor Author

This is missing WPT tests at present. I understand if merging this is blocked on that, but would you mind having a look @noamr ? I expect the tests for this will be relatively straightforward (at least, once we have an implementation in Chromium to avoid test bugs).

index.html Outdated Show resolved Hide resolved
Copy link
Contributor

@yoavweiss yoavweiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I'd love to run this by the WG and see if there are any objections, as well as get tests in place before this lands.

index.html Outdated Show resolved Hide resolved
This defines a concept of "delivery type" which currently describes the
difference between resources delivered from the HTTP cache and those not
(currently only detectable via transferSize). It is expected to be
extended to describe resources delivered from other stores, such as the
consuming resources from the HTML preload buffer and navigational
prefetches.
@jeremyroman
Copy link
Contributor Author

LGTM, but I'd love to run this by the WG and see if there are any objections, as well as get tests in place before this lands.

Is TPAC a good venue for that? If so are there steps I should take to get it on the agenda?

@yoavweiss
Copy link
Contributor

Is TPAC a good venue for that? If so are there steps I should take to get it on the agenda?

We can probably cover this on today's call.

@nicjansma
Copy link
Contributor

Question: Would this attribute be gated by same-origin or TAO/CORS?

For the "cache" status: In RUM we like to know whether resources are cached or not. For same-origin/TAO we utilize transferSize=0 to know this, but for X-O resources we apply a heuristic of "< ~30ms must be cached" (this isn't perfect). If cache is not TAO protected this could give us a more precise knowledge of cache status, but I can understand if this would have to be TAO (or CORS) protected.

Other than that, the other states that this could have for e.g. nav prefetch seem useful.

@nicjansma
Copy link
Contributor

nicjansma commented Sep 1, 2022

Summary from 9/1 W3C WebPerf call:

  • Need to figure out cross-origin/TAO/CORS limitations
  • Possible objections from Safari, to be discussed further at TPAC in ~2 weeks

@yoavweiss
Copy link
Contributor

Thinking out loud regarding the need for restrictions here:
If we don't add any TAO restrictions to this, this doesn't reveal anything about the resource itself, but it can reveal some metadata about the resource. Specifically, it can reveal things about the resource's caching headers. It provides a bit on whether the resource is cachable or not (and potentially, for how long it is cacheable, through continous probing).

While not significant on its own, this could be sufficient to reveal user state in cases where the cachability of the resource varies between e.g. logged-in and non-logged-in users.

So, I think we want this to be TAO protected.

/cc @arturjanc and @mikewest to tell me if I'm being overly paranoid about this or overly optimistic about this not already being leaked through timing.

@jeremyroman
Copy link
Contributor Author

I think that tracks. I think the strongest counterarguments would be:

  1. The risk is substantially mitigated in browsers which partition the cache by at least top-level site (and some also use a secondary key). In such cases the cache state doesn't reveal anything about browsing activity on other top-level sites. I'm not certain but I believe this is now all major browsers.
  2. It is likely already deducible from timing heuristics (even without TAO-protected info) in most cases.

I'm not opposed to TAO protection, though, and presumably anyone gathering RUM is also serving their important cross-origin resources with a suitable TAO header.

If that is the resolution, the behavior I propose is that the if "cache" would have been the delivery type but the response's timing allow passed flag is unset, then it returns "" instead. This is probably slightly conservative since it would protect it if a redirect didn't pass the TAO check even if the final resource did, but similar concerns might apply to the destination of the redirect and there's value in being consistent with other TAO protected properties.

@jeremyroman
Copy link
Contributor Author

On further investigation, I think the current text in this PR already implies a TAO check in the following way:

Fetch says:

If response’s timing allow passed flag is not set, then set timingInfo to a the result of creating an opaque timing info for timingInfo, set bodyInfo to a new response body info, and set cacheState to the empty string.

This is then used to populate the cache mode and thus the default delivery type, so "setup the resource timing entry" won't see the "cache" delivery type if the timing allow passed flag wasn't set (i.e., the response didn't pass a TAO check).

@jeremyroman
Copy link
Contributor Author

Status update:

  • the question of the TAO is, I believe, resolved above
  • re. TPAC discussion, user agents which restrict access to certain properties beyond the specified TAO checks can, of course, apply similar restrictions to this property if applicable; if explicit verbiage to permit this lands in the specification then I think it will generalize naturally
  • slated to go to origin trial in Chrome 110 (including an extension for "navigational-prefetch", which is otherwise difficult to detect)
  • WPT coverage is landed as tentative (resource-timing/delivery-type.tentative.any.js)

I believe that covers the identified items. @yoavweiss what is the next step under the group's working mode?

@yoavweiss
Copy link
Contributor

^^ @achristensen07 @bdekoz

@jeremyroman
Copy link
Contributor Author

#369 seems to be general verbiage that I think covers any application it would have to this PR. I'd like to renew my request to know what the next step/milestone here is.

@noamr
Copy link
Contributor

noamr commented Mar 7, 2023

This is LGTM, @yoavweiss do you want to take another look?

Copy link
Contributor

@yoavweiss yoavweiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@yoavweiss yoavweiss merged commit c2f56ef into w3c:gh-pages Mar 13, 2023
2 checks passed
@jeremyroman jeremyroman deleted the resource-timing-delivery-type branch March 16, 2023 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants