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

Request for position : HTTP response status code in Resource Timing #665

Closed
abinpaul1 opened this issue Jul 13, 2022 · 5 comments
Closed

Comments

@abinpaul1
Copy link

Request for Mozilla Position on an Emerging Web Specification

Other information

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

@yoavweiss
Copy link

^^ @sefeng211 @bdekoz

@martinthomson
Copy link
Member

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 TAO1 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
Copy link
Member

bgrins commented Jul 29, 2022

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
Copy link
Member

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

@bdekoz
Copy link

bdekoz commented Jan 19, 2023

Agree with worth-prototyping, put into bugzilla

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants