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

98 views
Skip to first unread message

Nicolás Peña

unread,
Apr 19, 2021, 2:59:41 PMApr 19
to blink-dev

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

unread,
Apr 22, 2021, 11:59:55 AMApr 22
to Nicolás Peña, blink-dev

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

unread,
Apr 22, 2021, 2:46:40 PMApr 22
to Daniel Bratell, Nicolás Peña, blink-dev
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


Daniel Cheng

unread,
Apr 22, 2021, 3:03:20 PMApr 22
to Mike West, Daniel Bratell, Nicolás Peña, blink-dev
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

Chris Harrelson

unread,
Apr 22, 2021, 3:22:33 PMApr 22
to Daniel Cheng, Mike West, Daniel Bratell, Nicolás Peña, blink-dev
LGTM3

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

Daniel Cheng

unread,
Apr 22, 2021, 5:06:28 PMApr 22
to Chris Harrelson, Mike West, Daniel Bratell, Nicolás Peña, blink-dev
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

unread,
Apr 22, 2021, 5:53:14 PMApr 22
to blink-dev, Daniel Cheng, Mike West, Daniel Bratell, Nicolás Peña, blink-dev, Chris Harrelson
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.

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

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

--
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.
Reply all
Reply to author
Forward
0 new messages