RE: Resource Timing

Hi Bryan,

Thanks for your thoughtful reply. I agree that much of the Resource Timing information such as the time taken to retrieve and load a resource can be easily determined and thus figuring out whether or not the resource was cached can be easily discovered with script today.

However, it has been brought to our attention that we should not allow make this an capability of new platform interfaces such as Resource Timing.  We are actively brainstorming solutions to mitigate this privacy attack. In fact, I'd love to hear some of your thoughts on approaches to mitigate this issue.

We also want the interface to be easy to use. One of our aspirations is to be able to arrive at a solution where we can have Resource Timing on by default for all downloaded resources, however, not at the cost of impeding performance of the user-agent. This is an area where we will need technical investigations and prototypes.
 
The goals for Resource Timing we have in mind are:
* ease of store and access to the resource timings
* negligibly impacting the user-agent's performance
* efficient lifetime management of the resource timing objects
* end-user security and privacy conscious 

Best Regards,
Anderson Quach
IE Program Manager

-----Original Message-----
From: Bryan McQuade [mailto:bmcquade@google.com] 
Sent: Tuesday, August 31, 2010 8:56 AM
To: Anderson Quach
Cc: Jason Sobel; Zhiheng Wang; public-web-perf@w3.org
Subject: Re: Resource Timing

Hi Anderson and Zhiheng,

I wanted to follow up on this and share more of my thoughts now that I've had more time to think about it.

I do not know the background on the security decisions for resource timing. Zhiheng said: "In the example here, you can look into the DNS time and TCP time of the resource fetched from otherdomain.com and figure if the user has recently (or even currently) visit otherdomain.com."

This kind of information is already leaked by the browser and it is relatively easy to ascertain whether a user has visited a site recently due to the shared nature of the browser cache. You are right that for resource timing it will be very clear (dns/tcp times of zero) but it's easy enough to embed the URL of a resource known to be on some other page in your own page, and then time the onload for that resource. If it's short (under 10-15ms) it's likely from cache, indicating that the user has visited the site. If you look at resource expirations from a site you can even infer how recently the user visited that site. So the shared browser cache leaks more information today than the resource timing information would.

I raise this issue because I do not expect we will see widespread adoption of this header-based opt-in approach, and the real value of resource timing hinges on web site operators being able to see how much latency is added by third party content. You will see adoption of the opt-in headers for the big players like google, facebook, and ms, where they have the size to force their content providers to enable these headers (or in some cases where they run all the services and can just enable these headers themselves). But small hosters will not be able to force third party providers to enable these headers, and they will be locked out of this valuable data by default.

Further, adding new headers increases the weight of each response, which works against goals of making the web faster.

I hope you will consider providing this data by default. Resource timing is going to be very useful and will empower web site owners to understand what's slowing their sites down, and allow them to put pressure on the slow third party content providers. But this can happen only if the site providers have access to the data they need, which is why I am advocating to make it available by default.

-Bryan

On Tue, Aug 24, 2010 at 7:52 PM, Anderson Quach <aquach@microsoft.com> wrote:
> We are still working to establish the criteria for the milestones. 
> Currently the working milestone dates are described on the Web 
> Performance Working Group charter [1], specifics about the 
> deliverables will certainly be flushed out. The working group 
> co-chairs are coordinating to kick-off public discussions soon.
>
>
>
> Right now, we're actively iterating to stabilize the Navigation Timing 
> interface.
>
>
>
> This is actually a great time to talk about Resource Timing [2] usage 
> scenarios so we can arrive at a solid design and interface.
>
>
>
> [1] http://www.w3.org/2010/08/webperf.html
>
> [2] http://dev.w3.org/2006/webapi/ResourceTiming/Overview.html
>
>
>
> Anderson Quach
>
> IE Program Manager
>
>
>
> From: Jason Sobel [mailto:jsobel@facebook.com]
> Sent: Tuesday, August 24, 2010 3:16 PM
> To: Anderson Quach; Zhiheng Wang; Bryan McQuade
> Cc: public-web-perf@w3.org
> Subject: RE: Resource Timing
>
>
>
> Thanks Anderson, I'm excited to see what you come up with! Any 
> particular timeframe you're shooting for?
>
>
>
>               --jason
>
>
>
> From: Anderson Quach [mailto:aquach@microsoft.com]
> Sent: Tuesday, August 24, 2010 2:03 PM
> To: Zhiheng Wang; Bryan McQuade
> Cc: Jason Sobel; public-web-perf@w3.org
> Subject: RE: Resource Timing
>
>
>
> The design and approach of ResourceTiming is still nascent. Some of 
> the key challenges we face are:
>
> i.                     Efficient resource management and lifetime of 
> the resource timing object, that is when to allocate and clean-up 
> resource timing objects.
>
> ii.                   Minimizing the performance degradation of 
> collecting timing about resources.
>
> iii.                  Privacy and security implications of 
> cross-domain requests for the timing information.
>
>
>
> We've been exploring various approaches like using the http header or 
> the meta element to allow for "opt-in" scenarios to gather timing information.
> Particularly for cross-domain access of resource timing information 
> we're also exploring various possibilities like CORS [1] and Web Messaging [2].
>
>
>
> We'll need to investigate and tackle these issues and be cognizant 
> about the trade-offs with each approach.
>
>
>
> Cheers,
>
> Anderson Quach
>
> IE Program Manager
>
>
>
> [1] http://www.w3.org/TR/cors/
>
> [2] http://dev.w3.org/html5/postmsg/
>
>
>
>
>
> From: public-web-perf-request@w3.org 
> [mailto:public-web-perf-request@w3.org]
> On Behalf Of Zhiheng Wang
> Sent: Tuesday, August 24, 2010 1:57 PM
> To: Bryan McQuade
> Cc: Jason Sobel; public-web-perf@w3.org
> Subject: Re: Resource Timing
>
>
>
>     In the example here, you can look into the DNS time and TCP time 
> of the resource fetched from
>
> otherdomain.com and figure if the user has recently (or even 
> currently) visit otherdomain.com. And
>
> we are saying that, this should happen only if otherdomain.com allows it.
>
>
>
> thanks,
>
> Zhiheng
>
> On Tue, Aug 24, 2010 at 1:50 PM, Bryan McQuade <bmcquade@google.com> wrote:
>
> This seems more restrictive than the same origin policy. IMO any 
> resource loaded by a document should be visible by that document by 
> default, regardless of where that resource came from.
>
> If I have an HTML document at http://example.com/ that looks like:
>
> <html>
> <body>
> <src src="http://otherdomain.com/foo.js"></script>
> </body>
> </html>
>
> It seems unnecessary to hide the timing information about 
> http://otherdomain.com/foo.js from my page. I know full well that my 
> page is trying to load this resource, as it's explicitly declared in 
> my HTML. This goes for any resource loaded into my document.
>
> Why do you think it is necessary to require the header for resources 
> loaded in the same document?
>
> On Tue, Aug 24, 2010 at 4:36 PM, Zhiheng Wang <zhihengw@google.com> wrote:
>>    I actually did mean "HTML header". :-) HTTP header requires 
>> changes to the http server configure, which is not always feasible 
>> for developers.
>> thanks,
>> Zhiheng
>>
>> On Tue, Aug 24, 2010 at 1:25 PM, Jason Sobel <jsobel@facebook.com> wrote:
>>>
>>> I assume you mean an HTTP header? If so, that sounds totally reasonable.
>>>
>>> Thanks!
>>>
>>>
>>>
>>>               --jason
>>>
>>>
>>>
>>> From: Zhiheng Wang [mailto:zhihengw@google.com]
>>> Sent: Tuesday, August 24, 2010 1:21 PM
>>> To: Jason Sobel
>>> Cc: Bryan McQuade; public-web-perf@w3.org
>>> Subject: Re: Resource Timing
>>>
>>>
>>>
>>>    fbcdn.net can set its html header, say "allow-timing-access", to 
>>> allow facebook.com to access timing information on those resources
>>>
>>> served from it. That should answer your question?
>>>
>>>
>>>
>>> cheers,
>>>
>>> Zhiheng
>>>
>>> On Tue, Aug 24, 2010 at 12:37 PM, Jason Sobel <jsobel@facebook.com>
>>> wrote:
>>>
>>> The case I'm mostly worried about is where we (facebook.com) host 
>>> our static resources on a different domain (fbcdn.net). I'd like 
>>> some way to allow fbcdn.net to "opt in" to giving timing information to facebook.com.
>>> At
>>> one point CORS (http://www.w3.org/TR/cors/) was mentioned as a 
>>> possible solution.
>>>
>>> I look forward to seeing what you come up with Zhiheng. Thanks!
>>>
>>>              --jason
>>>
>>> -----Original Message-----
>>> From: Bryan McQuade [mailto:bmcquade@google.com]
>>> Sent: Tuesday, August 24, 2010 12:32 PM
>>> To: Zhiheng Wang
>>> Cc: Jason Sobel; public-web-perf@w3.org
>>> Subject: Re: Resource Timing
>>>
>>> Interesting. Can you expand on the meta header approach?
>>>
>>> I assume you are referring to a case where a child iframe is on a 
>>> different origin. In that case it would not be appropriate to leak 
>>> the timing info for the frame up to the parent. But it sounds like 
>>> this meta header might allow the child frame to give permission to 
>>> leak the info to the parent?
>>>
>>> On Tue, Aug 24, 2010 at 12:49 PM, Zhiheng Wang <zhihengw@google.com>
>>> wrote:
>>> >     The immediate questions for ResourceTiming is how to maintain 
>>> > privacy while exposing those timing information.
>>> > So far using meta header on top of the same origin policy seems to 
>>> > be the way to start. An update should be available later this 
>>> > week.
>>> > cheers,
>>> > Zhiheng
>>> >
>>> >
>>> > On Mon, Aug 23, 2010 at 12:41 PM, Jason Sobel 
>>> > <jsobel@facebook.com>
>>> > wrote:
>>> >>
>>> >> Hey all-
>>> >>
>>> >> Looks like you're making great progress on navigation timing -- 
>>> >> very exciting!
>>> >>
>>> >>
>>> >>
>>> >> Do you have any thoughts on polishing and implementing resource 
>>> >> timing?
>>> >> That data is very interesting to us at Facebook so I'm hoping it 
>>> >> will be available in all the major browsers sooner rather than 
>>> >> later.
>>> >>
>>> >>
>>> >>
>>> >> Thanks much!
>>> >>
>>> >>
>>> >>
>>> >>               --jason
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>
>

Received on Friday, 3 September 2010 02:22:39 UTC