Bug 185870 - Enable Server-Timing by default
Summary: Enable Server-Timing by default
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-22 09:05 PDT by cvazac
Modified: 2021-10-04 08:14 PDT (History)
13 users (show)

See Also:


Attachments
Patch (1.16 KB, patch)
2018-05-22 09:07 PDT, cvazac
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews204 for win-future (12.73 MB, application/zip)
2018-05-22 14:22 PDT, EWS Watchlist
no flags Details
Patch (1.78 KB, patch)
2021-09-01 22:13 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description cvazac 2018-05-22 09:05:47 PDT
Enable Server-Timing by default
Comment 1 cvazac 2018-05-22 09:07:13 PDT
Created attachment 340985 [details]
Patch
Comment 2 EWS Watchlist 2018-05-22 14:22:37 PDT
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
Comment 3 EWS Watchlist 2018-05-22 14:22:48 PDT
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 4 Alexey Proskuryakov 2018-05-22 19:00:35 PDT
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 5 youenn fablet 2018-05-22 21:18:08 PDT
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?
Comment 6 cvazac 2018-05-22 21:26:50 PDT
(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.
Comment 7 Ryosuke Niwa 2018-05-24 21:14:54 PDT
Does our implementation pass all web platform tests?
Comment 8 cvazac 2018-05-25 07:27:36 PDT
(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.
Comment 9 Ryosuke Niwa 2018-05-25 19:46:57 PDT
(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.
Comment 10 cvazac 2018-05-30 10:32:43 PDT
> 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".
Comment 11 Radar WebKit Bug Importer 2018-05-30 10:44:46 PDT
<rdar://problem/40654914>
Comment 12 Jakub G (dailymotion) 2021-06-14 06:14:33 PDT
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.
Comment 13 Alex Christensen 2021-09-01 22:13:54 PDT
Created attachment 437114 [details]
Patch
Comment 14 Ryosuke Niwa 2021-09-02 01:23:56 PDT
In the past, we had several privacy concerns about this API. I'm not certain that all of them have been addressed.
Comment 15 Ryosuke Niwa 2021-09-02 01:24:54 PDT
(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.