Consider removing wildcard option of the Timing-Allow-Origin header to prevent browser history leakage · Issue #222 · w3c/resource-timing (original) (raw)
We crawled 50,000 websites and found that 95% of 1.1M third party requests using the 'Timing-Allow-Origin' header were using a wildcard. Wide usage of wildcard combined with the amount of detailed information that this API exposes about third party requests creates multiple opportunities for leaking user's browsing history.
- Extracting DNS cache information
domainLookupStart/domainLookupEnd properties (introduced in level 1) allow any website to extract some information from browser's DNS cache. In particular this can be used to detect a new private session (by checking if domainLookupStart !== domainLookupEnd for some popular services like google-analytics.com).
- Extracting HSTS information
redirectEnd - redirectStart !== 0 (level 1) may leak information about user visiting given website in the past through browser's enforcement of HSTS (HSTS redirects being instant compared to the regular 30X redirects).
- Extracting reused connections
secureConnectionStart === 0 (level 1) can reveal information about a connection being reused suggesting that user recently visited given website.
- Extracting information about cookies being set
Many applications are set up in a way that new users are getting 'set-cookie' header on response while users with cookies set are not getting that header. By observing size of the headers (transferSize - encodedBodySize) website can learn if cookies were sent with a given third-party request or not.
It's worth noting that issues 1 and 3 can be mitigated by the user agent by double-keying of the caches. However, since this technique is not a W3C standard it doesn't address our concerns. Similarly, issue 4 can be mitigated by blocking third party cookies, but it's not a standard behavior.
To mitigate above risks we suggest dropping wildcard functionality in the Timing-Allow-Origin header. This will force developers to list actual domains that they want to share this information with and greatly reduce amount of domains that can be scanned, using above techniques. If there are cases where wildcard is required developers will still be able to simulate it by setting timing-allow-origin value based on the value of the request's referer header.
The other possible mitigation is to introduce randomness to the values returned by the API. As we understand those values are meant to be processed in bulk by website owners to uncover performance trends, there seems to be no need for those values to be always accurate or as precise as they are now.