"timing allow check" is not well defined in the context of NavTiming

[bzbarsky]

https://w3c.github.io/navigation-timing/#dom-performancenavigationtiming-unloadeventstart says:

If the previous document, and all HTTP redirects when navigating, pass the timing allow check algorithm...

But "timing allow check" as defined at https://w3c.github.io/resource-timing/#dfn-timing-allow-check is something that operates on "resources" (which are not really a defined concept, as far as I can tell). In any case, it assumes that a "resource" has a Request attached to it, which a document may well not have at all.

It's really not clear to me what behavior is supposed to be implemented here and why it doesn't lead to security bugs depending on what people decide to do with Timing-Allow-Origin headers in this nonsensical case...

[yoavweiss]

Thanks for pointing this out!

I think we have 2 cases where Navigation Timing references TAO:

• For the previous document, it's not clear which response needs to provide TAO, and what origin will this TAO be tested against. Since exposing the information exposes something about the previous document, it's logical that it's the response to the previous document that should have provided TAO headers, and that they are evaluated against the origin of the current document.
• For redirects, it's not clear which origin they should be evaluated against. Since exposing the information exposes something about the redirected hosts to the current document, it's logical that they will be evaluated against the origin of the current document.

Both these cases are not something we took into account when revising the timing allow check in resource timing. If folks agree that this is what that algorithm should do in those contexts, I'll figure out revisions to it. We'd also need to add tests.

[annevk]

There's also the case of there not being a previous document, but maybe there are redirects. (When the user initiates navigation.)

You'll need to change HTML's navigate algorithm basically to record the TAO header of the final response (that creates a document) somehow. And when navigating is initiated you need to create a log where you put the recorded header of the "source" document, if any, and of any redirects. And then when you create a new document (where you also record the final TAO header) you also do a check on the TAO header log to determine whether you have access (presumably whether the origin of the newly created document is listed in those logged TAO headers in some fashion).

And then you need to deal with various edge cases such as redirecting to blob or data URLs, or initiating navigation from those.

[igrigorik]

Based on discussion at the f2f..

• Current text was introduced in Clarify TAO check for unloadEventStart|End #53
• Previous text did not rely on TAO and scoped unloadEvent{Start,End} and redirect timing and counts to same-origin only. Further, we believe the previous behavior was correct, TAO is not the right mechanism here.

Actions:

• Revert Clarify TAO check for unloadEventStart|End #53 spec text and limit above attributes to same-origin
• Update the tests (e.g. [Navigation timing] Make sure unloadEvent is only exposed when all redirects pass TAO web-platform-tests/wpt#15746) to capture right behavior
• Verify current tests in WPT, file implementation bugs if necessary

[annevk]

Well, this will still need integration with HTML. You can't monkey patch navigation forever.