Consider removing wildcard option of the `Timing-Allow-Origin` header to prevent accidental application state leakage

[kdzwinel]

Wide usage of Timing-Allow-Origin: * (as discussed in #222) combined with the amount of detailed information that this API exposes about third party requests creates multiple opportunities for web applications to leak their state (e.g. if user is logged in).

We believe that having detailed information about the response body size, headers size (transferSize - encodedBodySize) and redirects being shared with third-party websites creates a lot of unwanted opportunity for web applications to accidentally leak information about their state. Additionally, all resources that where returning Timing-Allow-Origin: * header since level 1 of this API are getting seamlessly (w/o additional opt in) updated to level 2 which will expose much more information about them to third party websites. While developers that originally added those headers may have considered the risks of doing so, new data exposed in level 2 was probably not taken into account.

Mitigations that we proposed in #222 should also cover the above issue.

[npm1]

This looks like a duplicate of https://github.com/w3c/resource-timing/issues/222. Discussion is happening there, can we close this?

[kdzwinel]

Some parts of this issue did came up in the #222 discussion, but IMO those two are different. #222 focuses on browsing history leaks while this issue talks about application state leaks and pitfalls of seamlessly upgrading resources to higher Resource Timing API levels.