w3c / server-timing

Server Timing
http://w3c.github.io/server-timing/
Other
75 stars 20 forks source link

Clarify security context for PerformanceResourceTiming #79

Closed fred-wang closed 2 years ago

fred-wang commented 3 years ago

Chromium relies on whether the resource timing info's response url is "secure" here:

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance.cc;l=553;drc=cc68781020815770d5e56cf555c858681ab6d002

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 ).

noamr commented 2 years ago

Seems like this should be a Chromium issue rather than a spec issue, since (as you said) is_secure_context is found in the chromium source code and is not a standard.

fred-wang commented 2 years ago

This issue is about clarifying the security restriction in the spec, while a Chromium issue would typically be to align implementation with the spec.

noamr commented 2 years ago

This issue is about clarifying the security restriction in the spec, while a Chromium issue would typically be to align implementation with the spec.

OK. Currently FETCH defines how the same-origin policy affects resource timing entries in detail. (see here) and also in the Resource TIming spec.

This seems unrelated to is_secure_context, which seems like something Chromium is doing regardless of spec.

What do you believe is missing?

yoavweiss commented 2 years ago

@fred-wang - Friendly ping on @noamr's question :)

Also, Is this issue related to Server Timing? It seems like all the links point to Resource Timing.

fred-wang commented 2 years ago

@yoavweiss Thanks for the reminder. Yes, it seems this is about resource timing (but I guess things are defined over misc specs...). Anyway, checking again I believe Chromium & the spec are aligned. Please check the details below and confirm:

Chromium

Since my initial report, progress has been made in Chromium. It's now only checking is_securetransport:

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance.cc;l=585;drc=e5a38eddbdf45d7563a00d019debd11b803af1bb

That is essentially doing https://url.spec.whatwg.org/#concept-url-origin to parse origin of the final response's URL and check whether scheme one of

(note: it also allows quic-transport: but this was an experimental thing that should be removed https://groups.google.com/a/chromium.org/g/blink-dev/c/YD_fiUqNggo/m/a0MC4cNRBgAJ)

If is_securetransport is true then secureConnectionStart will return 0.0 immediately here:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_resource_timing.cc;l=332;drc=842acb33ce629f4d1c4459a2c0067e9043184672

Spec

The default value of secure connection start is zero. It can be set to a different value if a secure transport is used:

https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-secureconnectionstart https://fetch.spec.whatwg.org/#connection-timing-info-secure-connection-start-time https://fetch.spec.whatwg.org/#record-connection-timing-info

yoavweiss commented 2 years ago

If is_securetransport is true

I think you meant false :)

yoavweiss commented 2 years ago

Sounds good! Glad things are well defined and implemented now! :)