Clarify security context for PerformanceNavigationTiming

[fred-wang]

Skimming over the spec, I see

• No [Secure Context] attribute on https://w3c.github.io/navigation-timing/#the-performancenavigation-interface
• Some mention on when attributes are exposed https://w3c.github.io/navigation-timing/#security

Note that Chromium's implementation does not expose the attribute values if the window url is not "secure" but I can't find where this is specified:

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance_navigation_timing.cc;l=61;drc=1ee40bf9f690377193ee2cc94e5b030ba1ed8b07

Additionally, note that Chromium's SecurityOrigin::IsSecure does not correspond to any spec definition. One option would be to rely on https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url or similar instead. However, It seems reviewer's preference is just to check whether the scheme corresponds to secure transport ( see https://chromium-review.googlesource.com/c/chromium/src/+/2831294 ).

Note that a [Secure Context] IDL attribute would correspond to potentially trustworthy (see https://html.spec.whatwg.org/multipage/webappapis.html#secure-context and https://heycam.github.io/webidl/#SecureContext ).

See also https://github.com/w3c/server-timing/issues/79 for the related PerformanceResourceTiming.

[npm1]

I think @noamr recently touched this and it is defined in https://fetch.spec.whatwg.org/#record-connection-timing-info where it just says "if a secure transport is used". Is that clear enough or do we need to be more specific about what that means?

[fred-wang]

How do you know the transport? and whether it's secure?

For https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy this is covered by checking whether scheme is "https" or "wss" ; or "one which the user agent considers to be authenticated". For Chromium, secure schemes include https://source.chromium.org/chromium/chromium/src/+/master:url/url_util.cc;l=65

To be honest, I wonder whether it would just be better to rely on https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy or https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy for consistency with other "secure" defintions.

[noamr]

I think we need to clarify what "immediately before starting the handshake process to secure connection" means. Is that, for example, right before sending the ClientHello? https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2

IMO, It doesn't matter in the timing context whether the connection is actually secure, what matters is that time was spent on some handshake protocol, and it's important to know exactly which point in the security flow is marked.

[fred-wang]

Just to explain a bit more about the "potentially trustworthy url/origin" thing, note that for historical reason Chromium's current implementation for timing APIs uses a security check that is a subset of https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy ; essentially it follows that definition but does not treat localhost / loopback addresses / local files trustworthy. But for example, it already includes the case "8. If origin has been configured as a trustworthy origin" to provide some allow list for the enterprise policy, even for http.

Many other specifications (at least I checked protocol handlers, payment API, CSP, CookieStore, Credential Management, WebAuth, CacheStorage, Mixed Content) rely either on [SecurityContext] IDL attribute (which corresponds to exposing thing only in potentially trustworthy url) or on some potentially trustworthy url/origin check, or both. In particular, these definitions cover the case of "localhost / loopback addresses / local files" for the sake of facilitating local testing. That's why I'm saying that personally (and as someone who does not know the detail of the timing specs) I feel for consistency it would be better if timing APIs follow the same approach as other specifications.

[yoavweiss]

@noamr - Can you take a look at this?

[noamr]

I'm closing for now. Secure context et al are a Chromium implementation detail. Spec-wise, this is clear: https://fetch.spec.whatwg.org/#record-connection-timing-info only records the secure connection start time only if the connection is secure. Please provide more context if something is missing in the spec.