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 Tuesday, 31 August 2010 15:56:56 UTC