W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2010

Re: [minutes] 20101020 Web Performance

From: Zhiheng Wang <zhihengw@google.com>
Date: Thu, 21 Oct 2010 12:05:26 -0700
Message-ID: <AANLkTinGQQnVRnUVnekGjYXU4HAe+LtjdRgo9VaJDRe-@mail.gmail.com>
To: Philippe Le Hegaret <plh@w3.org>
Cc: Anderson Quach <aquach@microsoft.com>, public-web-perf <public-web-perf@w3.org>
   We agree to move forward to publish NavigationTiming as a working draft.
Per this <http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance>,
- Arvind/Jason need to record this decision, and
- The Director must announce the draft to other WGs and the public.
Philippe, whom should we reach to?

cheers,
Zhiheng

On Thu, Oct 21, 2010 at 11:45 AM, Philippe Le Hegaret <plh@w3.org> wrote:

> I don't read anything here about "Next steps to getting Navigation
> Timing to draft". What is holding us from publishing a snapshot of
> navigation timing?
>
> Philippe
>
>
> On Wed, 2010-10-20 at 18:32 +0000, Anderson Quach wrote:
> > Available at:
> >
> > http://www.w3.org/2010/10/20-webperf-minutes.html
> >
> >
> >
> > Web Performance Working Group Teleconference #06
> >
> > 20 Oct 2010
> >
> > See also: IRC Log
> >
> > http://www.w3.org/2010/10/20-webperf-irc
> >
> >
> >
> >
> > Attendees
> > Present
> >
> > Biesi, AndersonQuach, Zhiheng, NicJansma, Sigbjorn
> >
> > Regrets
> >
> > PLH, JasonWeber
> >
> > Chair
> >
> > ArvindJain, JasonWeber
> >
> > Scribe
> >
> > AndersonQuach
> >
> >
> > Contents
> > Topics
> >
> >          Feedback on Privacy Issue w/ Navigation Timing.
> >
> >          Next steps to getting Navigation Timing to draft.
> >
> >          Getting started with Resource Timing and User Timing.
> >
> >          Any other business.
> >
> >
> >
> >
> > ______________________________________________________________________
> >
> >
> >
> >
> > Zhiheng: TonyG has gone thru security review with the Chrome team,
> > suggestions include zero'ing out redirectCount in different origin
> > navigations in the timeline, and to provide a means to disable the
> > interface completely
> >
> > AndersonQuach: Sounds good, as long as the disable via UI is a
> > non-normative requirement.
> >
> > Sigborn: We must be safe by default. The timings that reveal
> > off-domain must not be available programmatically.
> >
> > <scribe> scribe: AndersonQuach
> >
> > AndersonQuach: It can be feasible to attack with the same origin and a
> > redirect service. We could remove redirectCount altogether.
> > ... And disable redirect and unloading timings for different origin.
> >
> > Zhiheng: We need to hear more feedback from user-agent and security
> > experts about the removal of redirectCount
> > ... where is navigationStart?
> >
> > Sigborn: What is same domain, same cookie domain?
> >
> > Zhiheng: Same host
> >
> > Sigborn: Cookie domain, sub domains of yahoo.com
> >
> > AndersonQuach: where did we land with navigationStart
> >
> > NicJansma: A->B->A->A, navigationStart should begin immediately prior
> > the second A
> > ... for same domain with different origin redirections
> >
> > Zhiheng: need to look to clarify navigationStart and redirectStart
> >
> > AndersonQuach: Zhiheng, can you capture your thoughts and we'll get
> > feedback from Jonas and TonyG?
> >
> > NicJansma: Anderson and I will follow-up with additional feedback from
> > our security review via mail and for the next meeting.
> >
> > Sigborn: Should make the same domain be the same as the cookie domain,
> > I will write it up.
> >
> > AndersonQuach: Let's move the spec to a working draft as all the
> > latest feedback has been incorporated.
> > ... Let's be explicit that this is not a user-agent benchmark.
> >
> > Sigborn: Let's say due to the non-normative phases, the individual
> > phases should not be used as a benchmark.
> >
> > AndersonQuach: Agreed.
> > ... Let's simplify the accessing of the ResourceTiming
> > ... Let's say have a fixed buffer of 1000, have the ability to clear
> > the buffer, and to expand the buffer to cater to WebApps.
> >
> > Zhiheng: We don't want developers to crawl the page.
> >
> > AndersonQuach: Agreed, we should have the timing centralized.
> >
> > Zhiheng: Yup, the object should be easily serialized into a JSON
> > object.
> > ... How can a developer get the timing about a specific image?
> >
> > NicJansma: Timing of a specific image?
> >
> > Zhiheng: Yes.
> >
> > NicJansma: ResourceTiming can have the URL and potentially the id and
> > provide a means to filter based on type and/or id.
> > ... Goal for ResourceTiming to get timing that is inaccessible to JS.
> > ... We should keep in mind to be able to get the timing for individual
> > elements and the collection.
> >
> > Zhiheng: Come up with a short summary proposal and review the
> > proposals.
> >
> > AndersonQuach: I can write that out.
> >
> > Zhiheng: ResourceTiming has privacy concern as well. To have an HTML
> > header to turn this on.
> > ... implement the allow policy in the http header.
> >
> > Sigborn: This is possible but difficult to implement as seen in other
> > W3C discussions.
> >
> > NicJansma: For different origin we can reduce the amount of details,
> > just having fetchStart -> loadEventEnd, not providing additional info
> > via JS. Provide total time to load the content.
> >
> > Sigborn: Expand definition of Same Origin to include Same Cookie
> > Domain + Sub Domain.
> >
> > AndersonQuach: 1. We agree to move spec to working draft.
> > ... 2. Discuss privacy offline, feedback from Tony and Jonas.
> > ... 3. Zhiheng will provide a proposal for navigationStart.
> > ... 4. Anderson will respond with the simplified resource timing
> > proposal.
> > ... Thanks everyone for meeting!
> >
> >
> >
> >
>
>
>
>
Received on Thursday, 21 October 2010 19:05:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:55 GMT