TAO check and child frame navigations

[zetafunction]

The steps for performing a TAO check are defined here:
https://fetch.spec.whatwg.org/#tao-check

1. If request’s timing allow failed flag is set, then return failure.
2. If request’s response tainting is "basic", then return success.
3. Let values be the result of getting, decoding, and splitting Timing-Allow-Origin from response’s header list.
4. If values contains "*", then return success.
5. If values contains the result of serializing a request origin with request, then return success.
6. Return failure.

If I interpret https://fetch.spec.whatwg.org/#ref-for-concept-request-response-tainting%E2%91%A4 correctly, response tainting is always "basic" for navigate requests.

Does this imply the TAO check would always pass when reporting the resource for a child frame navigation to the parent frame, even if cross-origin?

A separate question would be if the TAO check needs to separately account for the fact that the parent frame's origin may not be the same as the request's origin. Reading https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object and https://w3c.github.io/navigation-timing/#dfn-create-the-navigation-timing-entry, I don't see where the behavior of reporting navigation timing to the parent Document is defined.

[zetafunction]

@npm1 @domfarolino @yoavweiss

[annevk]

Yeah, the navigate algorithm needs to perform the relevant TAO checks itself. It also follows redirects manually so I don't think Fetch can meaningfully account for it, but maybe? (I haven't followed the recent timing changes to HTML, I guess I should review those.)

cc @noamr @domenic

[noamr]

Yeah, the navigate algorithm needs to perform the relevant TAO checks itself. It also follows redirects manually so I don't think Fetch can meaningfully account for it, but maybe? (I haven't followed the recent timing changes to HTML, I guess I should review those.)

cc @noamr @domenic

Navigation entries are not (currently) reported to the parent document, so they don't need a TAO check.
IFRAME navigation is reported to the parent as a regular resource timing entry with a TAO check, though that reporting is yet to be specified (it's in the TODO list for HTML element reporting).

[zetafunction]

IFRAME navigation is reported to the parent as a regular resource timing entry with a TAO check, though that reporting is yet to be specified (it's in the TODO list for HTML element reporting).

How should response tainting be calculated for this separate TAO check?

[annevk]

Can someone, maybe @yoavweiss, explain the "reporting to parent" case in more detail? Presumably it covers A embedding B. But what if B navigates to C? Or B redirects to C? (Is it limited to iframe or does it also cover frame? embed and object?)

[noamr]

Judging from Chromium code, navigation timing saves a redirect list and the TAO check is done based on the list upon reporting (document load event).

[zetafunction]

Chrome implements the TAO check in two places:
https://source.chromium.org/chromium/chromium/src/+/master:services/network/cors/cors_url_loader.cc;l=666;drc=cc68781020815770d5e56cf555c858681ab6d002, which follows the fetch spec, as far as I can tell.

Then there's also https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/timing/performance.cc;l=451;drc=9bd90f9e5aa1524e928b4619e4574441b020d153. This sort of follows the fetch spec, but calculates response tainting its own way, and adapted to handle the reporting to parent case as well. This version operates on the saved redirect responses (for unfortunate reasons, there's actually another copy of this logic elsewhere, but it's supposed to be identical).

As for reporting to parent, I think Chrome attempts to only report it for the first HTTP load in a frame: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/loader/document_loader.cc;l=944;drc=221e331b49dfefadbc6fa40b0c68e6f97606d0b3

I believe the theory is it's OK to report the initial load, because the src was presumably specified by the parent.

I'm not sure that the Chrome logic is 100% sound though:

• if Chrome loads a non-HTTP response, and then navigates to a HTTP response, it seems like it might incorrectly report the response timing
• if the page is navigated elsewhere before the first navigation completes, it seems like it might incorrectly report the response timing

But I'm not familiar with the background here, so my reasoning of why things are/aren't OK may very well be wrong.

[yoavweiss]

Presumably it covers A embedding B. But what if B navigates to C? Or B redirects to C? (Is it limited to iframe or does it also cover frame? embed and object?)

Embedded documents are reported to the parent for the A embedding B case, but C should not be visible on neither navigations nor redirects. It's not limited to iframes.

I'm not sure that the Chrome logic is 100% sound though:

• if Chrome loads a non-HTTP response, and then navigates to a HTTP response, it seems like it might incorrectly report the response timing
• if the page is navigated elsewhere before the first navigation completes, it seems like it might incorrectly report the response timing

Those sound like bugs...

[annevk]

So if A embeds B but B is a redirect to B2/C you do not get timings? Any kind of redirect should stop it? That doesn't seem right. The HTML Standard doesn't really have a concept of initial navigation currently so this would definitely require some work to get right. I guess we should only report for the document that ends up replacing the initial about:blank document and only if that document was fetched over HTTP.

[yoavweiss]

So if A embeds B but B is a redirect to B2/C you do not get timings?

If B server-side redirects to C, we get the timing, but not get neither C's URL nor any intermediate timings.

[yoavweiss]

I guess we should only report for the document that ends up replacing the initial about:blank document and only if that document was fetched over HTTP.

For the old processing model, we landed on aborting the reporting when the request wasn't triggered by "process the {i,}frame attributes". We can probably do something similar on the reporting side in HTML.

[annevk]

I see, that might be better and would also cover setting the src attribute at a later point. (That would not address embed/object though.)

(It's still not quite clear to me how the redirect scenarios work and how TAO plays into it, but I guess we'll get to it as part of the HTML PRs.)

[yoavweiss]

(That would not address embed/object though.)

Maybe there are similar points for them, or maybe we can drop them altogether... (hopefully it's not a major use case)

[zetafunction]

Is there already an issue for speccing this out in the HTML spec?

[noamr]

Is there already an issue for speccing this out in the HTML spec?

There is a master issue:
whatwg/html#6542

[npm1]

So if A embeds B but B is a redirect to B2/C you do not get timings?

If B server-side redirects to C, we get the timing, but not get neither C's URL nor any intermediate timings.

Wouldn't getting redirect values depend on whether the TAO check passes or not? That is, if the redirect in B has A or * in as TAO header and C has * then it should report the detailed timing information.

[yoavweiss]

Wouldn't getting redirect values depend on whether the TAO check passes or not?

Yeah, that's what I meant (but didn't actually write...)

[noamr]

See related discussion here.

[noamr]

whatwg/html#7531 is merged, so now iframe RT is reported.
#1422 performs an additional TAO check when reporting a resource, by checking for TAO between the response and the origin of the global object receiving the report - which is mostly the original global object, but in this case, the iframe's container.