Bug 185870 – Enable Server-Timing by default

• Component: New Bugs
• Status: RESOLVED DUPLICATE

Enable Server-Timing by default

Created attachment 340985 [details]
Patch

[EWS Watchlist]

Comment on attachment 340985 [details]
Patch

Attachment 340985 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/7768389

New failing tests:
http/tests/security/contentSecurityPolicy/video-with-https-url-allowed-by-csp-media-src-star.html

[EWS Watchlist]

Created attachment 341025 [details]
Archive of layout-test-results from ews204 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews204  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Alexey Proskuryakov]

Comment on attachment 340985 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340985&action=review

> Source/WebKit/ChangeLog:3
> +        Enable Server-Timing by default

Why?

[youenn fablet]

Comment on attachment 340985 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340985&action=review

>> Source/WebKit/ChangeLog:3
>> +        Enable Server-Timing by default
> 
> Why?

IIANM, Server-Timing WebCore implementation is finished though WebInspector could further leverage this information.
Having it enabled in STP by default might make sense.
cvazac, can you tell us what the implementation/shipping status is in other browsers?

(In reply to youenn fablet from comment #5)
> Comment on attachment 340985 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=340985&action=review
> 
> >> Source/WebKit/ChangeLog:3
> >> +        Enable Server-Timing by default
> > 
> > Why?
> 
> IIANM, Server-Timing WebCore implementation is finished though WebInspector
> could further leverage this information.
> Having it enabled in STP by default might make sense.
> cvazac, can you tell us what the implementation/shipping status is in other
> browsers?

On by default since Chrome 65, Opera 52: https://www.chromestatus.com/features/5695708376072192.

Firefox is code complete with an intent to ship: https://groups.google.com/forum/#!msg/mozilla.dev.platform/MSzaY7_4mvg/hGpUlTzxAgAJ.

[Ryosuke Niwa]

Does our implementation pass all web platform tests?

(In reply to Ryosuke Niwa from comment #7)
> Does our implementation pass all web platform tests?

Outside of tests that validate server-timing entries on the PerformanceNavigationTiming instance (which we don't yet support), they all pass.

[Ryosuke Niwa]

(In reply to cvazac from comment #8)
> (In reply to Ryosuke Niwa from comment #7)
> > Does our implementation pass all web platform tests?
> 
> Outside of tests that validate server-timing entries on the
> PerformanceNavigationTiming instance (which we don't yet support), they all
> pass.

Why are we enabling this feature before adding the support for it?

Presumably, you're talking about
https://w3c.github.io/server-timing/#extension-to-the-a-performanceresourcetiming-a-interface

It seems important that our implementation is complete.

> Why are we enabling this feature before adding the support for it?
> 
> Presumably, you're talking about
> https://w3c.github.io/server-timing/#extension-to-the-a-
> performanceresourcetiming-a-interface
> 
> It seems important that our implementation is complete.

(Sorry for the delay)
I'm talking about this: https://www.w3.org/TR/navigation-timing-2/#sec-PerformanceNavigationTiming

Best I can tell, Webkit doesn't yet support performance entries of type "navigation".

[Radar WebKit Bug Importer]

<rdar://problem/40654914>

[Jakub G (dailymotion)]

Current status of compat:

- shipped in Chrome 65
- shipped in Edge 79
- shipped in Firefox 61
- Safari is the last major engine remaining

Note that this API can be useful beyond strictly performance monitoring.

Sometimes it's useful and handy to pass some piece of information to the page via an HTTP header, and Server-Timing can be (ab)used to pass arbitrary key-value string pairs (apart from performance numeric data), and read them back on JavaScript side:

https://stackoverflow.com/a/66211531/245966

I don't know any other header *which is JS-readable* and can be used to pass arbitrary data in that way.

[Alex Christensen]

Created attachment 437114 [details]
Patch

[Ryosuke Niwa]

In the past, we had several privacy concerns about this API. I'm not certain that all of them have been addressed.

[Ryosuke Niwa]

(In reply to Jakub G (dailymotion) from comment #12)
>
> https://stackoverflow.com/a/66211531/245966
> 
> I don't know any other header *which is JS-readable* and can be used to pass
> arbitrary data in that way.

That is precisely the issue here. It can open up side channels for trackers.

[Robin Berjon]

(In reply to Ryosuke Niwa from comment #15)
> (In reply to Jakub G (dailymotion) from comment #12)
> > https://stackoverflow.com/a/66211531/245966
> > 
> > I don't know any other header *which is JS-readable* and can be used to pass
> > arbitrary data in that way.
> 
> That is precisely the issue here. It can open up side channels for trackers.

As far as I can tell, the side-channel issue has been resolved (see https://github.com/w3c/server-timing/issues/89, and the change landed in the spec last year).

[Anne van Kesteren]

*** This bug has been marked as a duplicate of bug 245744 ***