1523275 - ResourceTiming duration should be non-0 for failed DNS, TCP, SSL

Status: NEW

(Core :: Performance, defect, P2)

Description

[Nic Jansma]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Load a resource that is aborted due to a network error such as DNS, TCP or SSL failure.

Fetch the resource from ResourceTiming.

Example: https://nicj.net/dev/resourcetiming/error-resources.html

Actual results:

For DNS lookup failures, TCP connection failures, SSL handshake failures, etc, I would expect the startTime and respondEnd to reflect the start and end of the attempted connection, and be different from each other.

Similarly, I would expect duration to be non-0 (reflect how long it took for DNS, TCP, SSL, etc to fail).

Instead, we see that startTime == responseEnd and duration == 0.

Expected results:

On getting, the responseEnd attribute MUST return as follows:
The time immediately after the user agent receives the last byte of the response or immediately before the transport connection is closed, whichever comes first. The resource here can be received either from relevant application caches, local resources, or from the server.
The time immediately before the user agent aborts the fetch due to a network error.

https://www.w3.org/TR/resource-timing-2/#dom-performanceresourcetiming-responseend

Comment 1

[Honza Bambas (:mayhemer)]

Valentin, can you confirm this?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:selenamarie, could you have a look please?

Comment 3

[Noam Rosenthal]

There is a security issue this bug creates. I will send to [e-mail].

Comment 4

[Noam Rosenthal]

This is covered by a new WPT PR: https://github.com/web-platform-tests/wpt/pull/30970

Comment 5

[Noam Rosenthal]

Security implication:
Documents can decipher the existence of restricted addresses, e.g. on a local network.
Example of a leak: a foreign site can try to fetch something from "intranet-host.my-company.org" - the fetch would of course fail, but if it has a duration greater than zero it would mean that that host is accessible to the user so they're probably in my-company intranet.

I opened a restricted security bug but was consulted to keep this open instead so added this comment.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

I've looked into this a little and it seems that the timings are already there, so it's just a matter of checking the channel status in PerformanceTimingData::SetPropertiesFromHttpChannel and dealing with it accordingly.
I haven't kept up with the resource timing spec lately, and it seems the new WPT are based on spec changes that haven't landed yet.
I'm happy to assist with necko-side changes if needed.

Comment 8

[Noam Rosenthal]

I haven't kept up with the resource timing spec lately, and it seems the new WPT are based on spec changes that haven't landed yet.
I'm happy to assist with necko-side changes if needed.

The relevant FETCH spec changes have landed a while ago, and they are more of a clarification of what was specified in prose before in the Resource Timing spec.