Intent to implement and ship: tainted origin flag in Timing Allow Origin

[Nicolás Peña]

Contact emails

n...@chromium.org

Explainer

The tainted origin flag is set when a request has gone through two origin crosses, via redirects. For example, if an initiator in origin A requests a resource in origin B which redirects to C, then the tainted origin flag is set. When the flag is set, serializing a request origin returns ‘null’. This is used in the CORS check so that when this happens, the only way to pass the check is by having ‘*’ in the  “Access-Control-Allow-Origin” header. This is done for enhanced security/privacy of the CORS check.

In https://github.com/whatwg/fetch/pull/955 we aligned the TAO check to behave similarly when the tainted origin flag is set. In this case, we use the “Timing-Allow-Origin” header. The TAO check is used in Resource Timing to determine whether to expose detailed timing information about a resource used in the page. We also added a use counter to determine how many pages would start failing the TAO check due to this change. About 0.26% of pages would be affected, but this would not break the pages, just make the timing data they receive from some of the resources less granular. We intend to move ahead with this change to align with the spec and with CORS.

Specification

https://fetch.spec.whatwg.org/#tao-check

Summary

Accounts for the tainted origin flag when computing whether a fetched resource passes the timing allow origin check. The Timing Allow Origin check is used in Resource Timing to determine whether the page has the right to receive detailed timing information about a resource used in the page. The tainted origin flag impacts this check in cases where there are multiple redirects that cross origins. In those cases, the header should be '*', i.e. can no longer be a specific origin.

Blink component

Blink>PerformanceAPIs>ResourceTiming

TAG review

No TAG review required: no new API surface, and the change in behavior is standardized in the Fetch spec and also better aligns TAO with CORS.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change will result in some sites losing detailed performance data from some of the resources via Resource Timing. We added a precise UseCounter to track this https://chromestatus.com/metrics/feature/timeline/popularity/3091

Currently, this affects 0.26% of page loads.

Gecko: Shipped/Shipping

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-April/031788.html)

Web developers: No signals

Debuggability

ResourceTiming is available via the console for local debugging. In addition, developers will know when the Timing Allow Origin check has failed since a bunch of attributes will be zeroed out in this case.

Is this feature fully tested by web-platform-tests?

Yes https://wpt.fyi/results/resource-timing/tao-origin-SO-XO-SO-redirect-chain.https.html?label=master&label=experimental&aligned

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1128402

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5665918254317568

This intent message was generated by Chrome Platform Status.

[Daniel Bratell]

LGTM1

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAATDi%3DyErqixsOE7_say2FKQhTma%2BzOQ8f8riRKUcFGCz545A%40mail.gmail.com.

[Mike West]

LGTM2.

Respecting the server's TAO assertion as being origin-bound seems quite reasonable and expected. As Gecko is shipping this behavior already, I don't think we need to block on a TAG review.

I do wonder about the developer experience here; is there an issue flagged in devtools to surface this mismatch in a way developers could act upon?

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a767333-9272-c869-6a08-c7c51d6fe3ce%40gmail.com.

[Daniel Cheng]

I've been looking at Timing-Allow-Origin a lot more than I expected recently.

I actually noticed that we have a version of the TAO check defined in CorsURLLoader. It would be good not to have two different versions (some Blink code already relies on the network service TAO check). Rather than potentially changing twice, can we update the metrics to track with a bit more precision:

• what would be allowed with the Blink TAO check but denied with the network service TAO check
• what would be denied with the Blink TAO check but allowed with the network service TAO check

Assuming the numbers aren't substantially different (once https://bugs.chromium.org/p/chromium/issues/detail?id=1201767 is fixed), I hope we can converge on the network service TAO check.

Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdX5px9ZRpdLOoC0bZjfRcHjSbxkXAVR0DjAf1w8hbrkA%40mail.gmail.com.

[Chris Harrelson]

LGTM3

Daniel Cheng: I think your comment was just about the implementation, right? And not whether to ship this feature? Just checking.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF3XrKr6NSL-h5qw%3DNZiths%3DfHRFACYTk2B%2BDhE0srXy5%3D3ZOQ%40mail.gmail.com.

[Daniel Cheng]

Correct, my comment is about the implementation, and not whether or not ship the feature. The main thing is the metrics we currently have aren't exactly capturing the metrics we'd need to demonstrate the feasibility of converging implementations. How long / how much data would we need to establish safety of any updated approach?

Daniel

[Nicolás Peña]

Thanks! Mike: I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1201835 to discuss ways to surface when TAO check fails.

Daniel: yes agreed, it would be nice to have only one implementation. I can try to dig into some of the failing tests to see which one is correct and what the problem may be. In any case, this intent is one of the required steps to converge in behavior. Regarding how much data is needed, I think it really depends on what the problem is. Let's continue the investigation in the bug you filed.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAATDi%3DyErqixsOE7_say2FKQhTma%2BzOQ8f8riRKUcFGCz545A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a767333-9272-c869-6a08-c7c51d6fe3ce%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdX5px9ZRpdLOoC0bZjfRcHjSbxkXAVR0DjAf1w8hbrkA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.