Enable Server-Timing by default
Created attachment 340985 [details] Patch
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
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
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?
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.
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.
(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".
<rdar://problem/40654914>
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.
Created attachment 437114 [details] Patch
In the past, we had several privacy concerns about this API. I'm not certain that all of them have been addressed.
(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.
(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).
*** This bug has been marked as a duplicate of bug 245744 ***