Server-Timing header and opaque responses

[youennf]

As part of process separation, WebKit implementation is currently restricting the list of headers sent from the networking process to the web process where lives the web page that triggered the load.

Exposing Server-Timing values in the web process could help an attacker know things about a user.
It would be best to not expose it and one simple rule would be to not expose it to opaque responses.

AIUI, Server-Timing value is usually for dynamically generated content such as HTML or JSON. Opaque responses on the other hand are usually statically served content such as scripts or images.
There might be already little value in supporting server-timing for opaque responses.

Should we consider removing web page server-timing information access in case of opaque responses?

[yoavweiss]

There is certainly value is serving Server-Timing information for scripts or images. (One use case that has come up is reflecting the time it took to compress images on the server)

Currently Server-Timing is not exposed on third-party responses (opaque or non-opaque) without explicit server consent through the Timing-Allow-Origin headers.
Do you think this protection is not enough?

[youennf]

There is certainly value is serving Server-Timing information for scripts or images. (One use case that has come up is reflecting the time it took to compress images on the server)

I see.
Was it useful in devtools scenarios or in analytic scenarios where timing info is sent back to websites?
Only the latter would suffer from stripping Server-Timing information for opaque responses.

Currently Server-Timing is not exposed on third-party responses (opaque or non-opaque) without explicit server consent through the Timing-Allow-Origin headers.
Do you think this protection is not enough?

Timing-Allow-Origin gives indeed sufficient protection if the check is done in networking process, similarly to how WebKit is doing CORS checks nowadays.
Stripping the header for no-cors is simpler though, especially since no-cors is a mode that we want people to move away.

[yoavweiss]

Was it useful in devtools scenarios or in analytic scenarios where timing info is sent back to websites?
Only the latter would suffer from stripping Server-Timing information for opaque responses.

It is useful in analytics scenarios.

Timing-Allow-Origin gives indeed sufficient protection if the check is done in networking process, similarly to how WebKit is doing CORS checks nowadays.
Stripping the header for no-cors is simpler though, especially since no-cors is a mode that we want people to move away.

Currently most of the traffic is still no-cors by default, so I think moving people would require bigger carrots/sticks that just banning server-timing on such resources in a way that's not web compatible.

[igrigorik]

I'll second both of Yoav's points here. ST provides useful and important information to site owners about both performance own 1P resources, and 3P resources that the site may rely on. For 3P case, TAO provides the right and well understood opt-in mechanism — same enforcement, use cases, and logic as Resource Timing. CORS-related enforcement is orthogonal to all this.

[yoavweiss]

@youennf - one more thing. If I properly understand the reasoning for that process separation, you would need TAO parsing in the networking process anyway, in order to avoid passing along 3rd party timing and resource size information that will not be used by the rendering engine.

[yoavweiss]

@youennf - Closing this as this doesn't seem like there's any action needed on the spec side of things. Feel free to reopen or comment if that's not the case