Add finalResponseHeadersStart to resource timing

[noamr]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Add finalResponseHeadersStart to resource timing
• Specification or proposal URL (if available): https://w3c.github.io/resource-timing/
• Explainer URL (if available):
• Proposal author(s) (@-mention GitHub accounts): @noamr @tunetheweb
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @sefeng211, Bas Schouten (not sure re the github handle?)
• WebKit standards-position:

Other information

This was resolved in the WebPerfWG meeting, see minutes.

[tunetheweb]

Bas Schouten (not sure re the github handle?)

I think it's @Bas-moz

[sefeng211]

finalResponseHeadersStart is the timing when the last response came. This is useful to see the timing differences for cases like early-hints where we have the first response which isn't the real response of the request.

We have no objection on this, it should be a positive for us.

[zcorpan]

@bvandersloot-mozilla can you review the privacy implications for this? Thanks.

[bvandersloot-mozilla]

RE Privacy: network caches are already partitioned, so there is no increased risk for cache fingerprinting of 3p tracking. The privacy considerations are correct in that respect. Further, gating on Timing-Allow-Origin gives us a guarantee that no third-party is being probed via this, even in storage-access granted states.

The remaining question is, should we be worried about the increased fidelity on resource timing from a first party? This may give a clearer network latency measurement from the client to the server, but I don't believe this is anything they couldn't piece together from existing data available to them, and is probably weaker than other networking fingerprints. My verdict is that this is r+ on the privacy side.