From ceda8f9ced15e78a104c7477ce7b48f8250ecbf3 Mon Sep 17 00:00:00 2001 From: Alex Christensen Date: Wed, 25 Jan 2023 20:29:54 -0800 Subject: [PATCH] Allow user agents to keep same-origin restrictions on PerformanceServerTiming even with the presence of TAO header fields. This resolves https://github.com/w3c/server-timing/issues/89 --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index a3b6ffa..ccfe148 100644 --- a/index.html +++ b/index.html @@ -221,7 +221,7 @@
## Privacy and Security - The interfaces defined in this specification expose potentially sensitive application and infrastructure information to any web page that has included a resource that advertises server timing metrics. For this reason the access to `PerformanceServerTiming` interface is restricted by the [=same origin=] policy by default. Resource providers can explicitly allow server timing information to be available by adding the `Timing-Allow-Origin` HTTP response header, as defined in [[RESOURCE-TIMING]], that specifies the domains that are allowed to access the server metrics. + The interfaces defined in this specification expose potentially sensitive application and infrastructure information to any web page that has included a resource that advertises server timing metrics. For this reason the access to `PerformanceServerTiming` interface is restricted by the [=same origin=] policy by default. Resource providers can explicitly allow server timing information to be available by adding the `Timing-Allow-Origin` HTTP response header, as defined in [[RESOURCE-TIMING]], that specifies the domains that may be allowed to access the server metrics, but the user agent MAY keep the [=same origin=] policy restriction. In addition to using the `Timing-Allow-Origin` HTTP response header, the server can also use relevant logic to control which metrics are returned, when, and to whom - e.g. the server may only provide certain metrics to correctly authenticated users and nothing at all to all others.