- From: Zhiheng Wang <zhihengw@google.com>
- Date: Thu, 21 Oct 2010 12:05:26 -0700
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: Anderson Quach <aquach@microsoft.com>, public-web-perf <public-web-perf@w3.org>
- Message-ID: <AANLkTinGQQnVRnUVnekGjYXU4HAe+LtjdRgo9VaJDRe-@mail.gmail.com>
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 UTC