RE: Cross Origin and Resource Timing

The Resource Timing Privacy and Security section, https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#privacy-security, discusses statistical fingerprinting.

Thanks,
Jatinder

-----Original Message-----
From: timeless.bmo3@gmail.com [mailto:timeless.bmo3@gmail.com] On Behalf Of timeless
Sent: Wednesday, February 15, 2012 8:24 PM
To: public-web-perf@w3.org
Subject: Re: Cross Origin and Resource Timing

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/Resour

> ceTiming/Overview.html#redirect-start>,
> redirectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Resource

> Timing/Overview.html#redirect-end>,
> domainLookupStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Re

> sourceTiming/Overview.html#domainlookup-start>,
> domainLookupEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Reso

> urceTiming/Overview.html#domainlookup-end>,
> connectStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Resourc

> eTiming/Overview.html#connect-start>,
> connectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceT

> iming/Overview.html#connect-end>, 
> requestStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Resourc

> eTiming/Overview.html#request-start>,
> responseStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Resour

> ceTiming/Overview.html#response-start>,
> responseEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Resource

> Timing/Overview.html#response-end>,
> and
> duration<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTim

> ing/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/#redire

> ct-start>, 
> redirectEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#redirect

> -end>, 
> domainLookupStart<http://w3c-test.org/webperf/specs/ResourceTiming/#do

> mainlookup-start>, 
> domainLookupEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#doma

> inlookup-end>, 
> connectStart<http://w3c-test.org/webperf/specs/ResourceTiming/#connect

> -start>, 
> connectEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#connect-e

> nd>, 
> requestStart<http://w3c-test.org/webperf/specs/ResourceTiming/#request

> -start>, 
> responseStart<http://w3c-test.org/webperf/specs/ResourceTiming/#respon

> se-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 17:38:28 UTC