- From: timeless <timeless@gmail.com>
- Date: Wed, 15 Feb 2012 23:23:38 -0500
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
I'm not monitoring this group, but one can determine something about a third party service based on how long it takes to process a request. If I'm not logged in, I might get a tiny page. If I'm logged in, I'll probably get a bigger and slower loading page. In cryptography, we've seen leakage of information due to timing... On 2/15/12, Jatinder Mann <jmann@microsoft.com> wrote: > Initially, I had thought that we had zero'd out the respondEnd attribute in > error in the cross-origin restrictions section and that our intention was to > give durations for even cross-origin resources. > > However, while looking at the Resource Timing Processing Model in more > detail, I see that we had added the following clause: > > If the last non-redirected > fetch<http://www.w3.org/TR/html5/fetching-resources.html#fetch> of the > resource is not the same origin as the current document and the > Timing-Allow-Origin<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#timing-allow-origin> > HTTP response header does not apply, the user agent must set > redirectStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#redirect-start>, > redirectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#redirect-end>, > domainLookupStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#domainlookup-start>, > domainLookupEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#domainlookup-end>, > connectStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#connect-start>, > connectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#connect-end>, > requestStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#request-start>, > responseStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#response-start>, > responseEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#response-end>, > and > duration<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#duration-attribute> > to zero and abort the remaining steps. > > Not only is the duration explicitly set to zero, but steps to include this > resource in the buffer are skipped. I believe the motivation here was that > cross-origin resources should be explicitly not included in the > PerformanceResourceTiming buffer. However, if someone were to look at the > entire performance timeline, they could deduce that the gap was due to a > cross-origin resource. > > An alternate proposal could be to provide the end to end time (fetchStart to > responseEnd), but zero out the individual attributes. > > Does the working group recall why we went with the former approach? > > Thanks, > Jatinder > > From: Alois Reitbauer [mailto:alois.reitbauer@dynatrace.com] > Sent: Wednesday, February 15, 2012 12:06 AM > To: public-web-perf@w3.org > Subject: Cross Origin and Resource Timing > > As far as I can remember the final decision was that for cross origin > resources which do not have the allow origin header set no detailed timings > but the total time to download the resources is shown. I checked again with > the latest version of the spec and it says > > , these attributes must be set to zero: > redirectStart<http://w3c-test.org/webperf/specs/ResourceTiming/#redirect-start>, > redirectEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#redirect-end>, > domainLookupStart<http://w3c-test.org/webperf/specs/ResourceTiming/#domainlookup-start>, > domainLookupEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#domainlookup-end>, > connectStart<http://w3c-test.org/webperf/specs/ResourceTiming/#connect-start>, > connectEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#connect-end>, > requestStart<http://w3c-test.org/webperf/specs/ResourceTiming/#request-start>, > responseStart<http://w3c-test.org/webperf/specs/ResourceTiming/#response-start>, > and > responseEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#response-end>. > > This would mean that one only gets the fetchStart time which means that we > only know when the download started but not when it is finished. > > Did I miss anything here? > > // Alois > -- Sent from my mobile device
Received on Thursday, 16 February 2012 04:24:09 UTC