HTTP response status code in Resource Timing

[abinpaul1]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: HTTP response status code in Resource Timing
• Specification or proposal URL: https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-responsestatus
  • Explainer: https://github.com/abinpaul1/resource-timing/blob/explainer-resource-response-status/Explainers/Response_Status_Code.md
  • Spec PR : Add response status code to PerfomanceResourceTiming w3c/resource-timing#335
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @bdekoz @sefeng211

Other information

Link to entry on the Chrome Platform Status: https://chromestatus.com/feature/5163838794629120

[yoavweiss]

^^ @sefeng211 @bdekoz

[martinthomson]

Just speaking about the security aspects here, the feature itself seems broadly reasonable in terms of making reports more usable. More data = more good, right?

Mostly. I think that TAO¹ is the wrong choice for protecting the status code. TAO exists for the narrow purpose of providing sites some measure of control over who gets access to timing information specifically. If there are timing side-channels in the resource serving, this gives them a cheap way to block casual attempts to exploit those side-channels.

This is not a timing side-channel. TAO exists and is deployed by sites already under the existing definition, which creates an expectation that the new data violates. Sites that allow timing information might not be prepared to leak this information. The status code needs to be treated as data, not metadata, and in this context it could be cross-origin information. For that, we currently use ACAO (i.e., CORS). So this should too. A new attribute on TAO might achieve the same goal as long as it were clear that this wasn't an agreement to expose timing information being (mis)interpreted as consent to expose status data.

Footnotes

1. Timing-Allow-Origin; please remember when writing an explainer that an explainer exists to inform people who aren't domain experts and you sometimes need to expand acronyms, provide references and so forth. ↩

[bgrins]

Thanks Martin! I see the upstream PR has incorporated your feedback (w3c/resource-timing#335 (comment)). If you're happy with the change there I would consider this worth-prototyping based on feedback from the perf team.

[martinthomson]

Thanks for the prompt Brian, I added a label, but I don't see any reason to put this on the dashboard.

[bdekoz]

Agree with worth-prototyping, put into bugzilla