W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2012

Re: Cross Origin and Resource Timing

From: timeless <timeless@gmail.com>
Date: Wed, 15 Feb 2012 23:23:38 -0500
Message-ID: <CANAYn0EQ7sY5Ke9-3okK75MDrNYXQLnMAk_dE7iHh1qQWTEswA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 February 2012 04:24:10 GMT