16:57:54 RRSAgent has joined #webperf 16:57:54 logging to http://www.w3.org/2011/03/09-webperf-irc 16:57:56 RRSAgent, make logs world 16:57:57 Zakim has joined #webperf 16:57:58 Zakim, this will be 16:57:58 I don't understand 'this will be', trackbot 16:57:59 Meeting: Web Performance Working Group Teleconference 16:57:59 Date: 09 March 2011 16:58:04 zakim, list conferences? 16:58:08 I don't understand your question, plh. 16:58:44 zakim, list conference? 16:58:44 I don't understand your question, plh. 16:58:47 zakim, list conference 16:58:47 I don't understand 'list conference', plh 16:58:48 zakim, list conferences 16:58:49 I see IA_XForms()11:00AM, Team_(PSIG)11:00AM, SW_RDFWG()11:00AM, WAI_PF()12:00PM, Team_(wai)15:30Z active 16:58:51 also scheduled at this time are Style_CSS FP()12:00PM, VB_VBWG(SCXML)12:00PM, XML_XMLCore()11:30AM, RWC_web-per(WPWG)12:00PM, SW_HCLS(LODD)11:00AM, WAI_EOWG(BAD TF)11:00AM, 16:58:54 ... T&S_EGOV(UseWebTech)12:00PM, RWC_(EVENT)11:00AM 17:01:04 Jatinder has joined #webperf 17:01:09 zakim, this is perf 17:01:10 sorry, plh, I do not see a conference named 'perf' in progress or scheduled at this time 17:01:14 tonyg has joined #webperf 17:01:30 zakim, this is web-per 17:01:30 ok, plh; that matches RWC_web-per(WPWG)12:00PM 17:02:26 rrsagent, set logs world-visible 17:02:37 Meeting: Web Perf WG 17:04:50 zhiheng has joined #webperf 17:05:26 Scribe+ Jatinder Mann 17:05:55 Present: Philippe Le Hegaret 17:06:02 Present: Arvind Jain 17:06:13 Present: Tonyg 17:06:14 W has joined #webperf 17:06:19 Present: Zhiheng 17:06:27 Present: Jatinder Mann 17:06:40 Present: Nic Jansma 17:06:48 Present: KarenAnd 17:07:11 W has left #webperf 17:08:45 Philip: Charter is on schedule. 17:09:13 Zhiheng: Do we have editors in place for all the specs? 17:09:27 W has joined #webperf 17:09:41 AndersonQuach has joined #webperf 17:09:49 s/Philip/Philippe/ 17:10:48 Zhiheng: We may want to organize another face to face meeting. 17:11:27 Arvind: Agree that we need a face to face to decide the format. 17:12:03 Anderson: That is a fantastic idea. Do one relatively soon, with video conferencing so Cameron can also join. 17:12:22 Anderson: We are definitely open to hosting the face to face in Redmond, since the last one we had was in Google. 17:12:49 Tony: There is a lot of forward momentum on these and we should discuss the high level overlaps before we get down too far. 17:13:05 Arvind: Let me take an action item to determine the location and time of the face to face meeting. 17:13:29 Philippe: Are we going to send email to the group? To kick off the discussion. 17:13:32 Arvind: Yes. 17:13:56 Philippe: In the email we should also ask if we want a new teleconference time. 17:14:26 Arvind: I will both send an email to decide the time for the face to face and determine the new teleconference time. 17:14:43 Arvind: I think sometime around 1pm PST would be good for teleconference time. 17:15:13 Arvind: That takes care of agenda #1. 17:15:50 Anderson: I will coordinate with Jason to organize the face to face 17:15:56 Move to agenda 2 17:16:12 Topic: Tests for Navigation Timing to review 17:16:51 Anderson: I will batch all the submissions up after this meeting and will move it over to the approved folder. 17:16:59 Anderson: Are there any additional tests? 17:18:40 http://w3c-test.org/webperf/tests/submission/Google/NavigationTiming/test_document_open.htm 17:19:11 Nic: We're looking at it right now. 17:19:29 Anderson: Where does it throw access is denied? 17:20:32 zakim, mute ??p3 17:20:32 sorry, plh, I do not know which phone connection belongs to ??p3 17:20:37 zakim, mute p3 17:20:37 sorry, plh, I do not know which phone connection belongs to p3 17:20:46 zakim, mute ??p3 17:20:46 sorry, plh, I do not know which phone connection belongs to ??p3 17:22:17 Anderson: We will look at this after the call. 17:22:27 Anderson: Let's move on to Agenda 3. 17:22:56 Philippe: Regarding Navigation timing, I sent email asking about dependencies. Is there any clarification on that? 17:23:30 Anderson: From my knowledge, as long as we have a conforming IDL and we're also using the readystate from HTML document. Those are the only two that come to mind 17:24:03 Phillipe: For WebIDL, I'm not sure there is a solution. 17:24:15 Zhiheng: I don't see much problem on this one for now. 17:24:38 Anderson: So we're on track for the 11th to publish? 17:24:52 Phillipe: No. I will do my best to try to be on track. 17:25:22 Anderson: Let's get started with Resource Timing (Agenda 3) 17:25:28 AndersonQuach_ has joined #webperf 17:25:37 http://test.w3.org/webperf/specs/ResourceTiming/ 17:25:55 Anderson: Please walk us through the deltas. 17:26:09 Zhiheng: One of the most important one is that we removed the resource timing connector. 17:26:55 Anderson: One thing we wanted to discuss, the behavior of enabled vs. disabled 17:27:06 Zhiheng: Those would go into the privacy issue. 17:27:26 W has left #webperf 17:27:36 Zhiheng: getResourceTimeByLocation - I think ByType would be more useful. 17:28:28 Anderson: The ability to access an element by all its different monikers. Elements on a page are not unique (multiple img elements with the same id). We wanted to come up with the most flexible way to access a resource. 17:28:50 Zhiheng: We can just edit to getResourceTimeByType. 17:29:05 Anderson: The diff looks good. Are we ready to discuss the details of the timing per element? 17:29:15 Zhiheng: I think for the interfaces we can start discussing them. 17:29:39 Anderson: The model we had discussed last time was safe by default. 17:30:25 Zhiheng: My main question is how do we cross domain as a control 17:30:31 Anderson: Still major issue to deal with. 17:30:52 Zhiheng: In terms of interfaces, do you have any suggestions or ideas? 17:31:00 Tony: I don't understand allowedDomains 17:32:15 Tony: Let's say a resource is used multiple times by the same or different elements - would there be multiple copies? 17:32:43 Nic: I would say it's unique for resource fetched from the network. 17:33:29 Zhiheng: In terms of the privacy, if we don't allow the cross-domain access, we only provide the start and ending timing. That is already available today. 17:33:41 Nic: We would be reporting resources from the cache. 17:33:55 Nic: How would that be exposed? For the first resource that asked for it? 17:34:28 Nic: Is it reported for each element or is it only reported once? 17:34:44 Zhiheng: The first one is from the network, the last one is from the cache. 17:34:51 Zhiheng: That's a good point though. 17:35:12 Nic: I think it can be kind of tricky. Browsers today if the same resources are used from the page, we don't go get it from the network. 17:35:32 Tony: If there is a 1x1 pixel gif. If I use it a 100 times on the page, do I have it a 100 times? 17:35:44 Karen: This is where getElementByID is useful. 17:36:05 Nic: In the list of all the things downloaded from the page would we show it multiple times? 17:36:13 Zhiheng: Thats what the current job is assuming. 17:37:01 Karen: Pretend like we have a 100 times and we are JSONing them all back, it becomes interesting to know how the DOM starts getting downloaded. Imagine parsers being different per user agents. Several variations. 17:37:30 Nic: Taking a step back, the goal for resource timing is to try to get something like the Network Inspectors. Do we agree that that is kind of the goal? 17:37:41 Tony: That is what I've had in mind here. 17:38:06 Nic: The browsers would not display the img element over and over again if it was displayed. 17:38:19 Nic: We should probably be more explict about which resources should be in the list. 17:39:08 Anderson: It's a valid question: the latency between fetching from the cache and displaying the retroactive waterfall display in the network inspector. 17:39:27 Anderson: It's interesting to consider how we would normalize cache access. 17:39:49 Zhiheng: If we consider each element a subdocument, I'm trying to make it consistent with the navigation timing. 17:40:12 Zhiheng: Like we found in navigation timing, it's not always possible to get the exact timing of the resource going to the wire. 17:40:50 Nic: As soon as we start exposing the fact that we get from the cache, we are exposing the user's browsing history. 17:41:05 Nic: We don'tw ant to make it easier for an attacker to determine which resources have already been loaded. 17:42:27 Anderson: We store the timings for only those that we have downloaded. This allows inline defining for images. If we start thinking about accessing resources locally, we would need to bring in the ability of accessing inline resources. That goes beyong what we had initialy thought about. That would reduce a lot of the traffic - minimize the noisyness of having using a resource 100 times. 17:42:47 Anderson: Simplicity, privacy, and consistency would be the goal. 17:42:57 Zhiheng: Not sure how this would add to the privacy concern here. 17:43:09 Zhiheng: Everything that can be done by this API can already be done by the webpage. 17:43:34 Nic: You are right in the fact that a page could determine this. One of the concerns could be to not explicitly expose we are getting this from the cache. 17:43:58 Nic: As long as expose the same level of granularity. It can be deduced that a resource was downloaded from the cache. 17:44:37 Nic: Goal would be to not give any higher precision whether something was in the cache or not. In the case of going to a page and looking at the resources, if anything is downloadable resource, we would put it in there. 17:45:11 Nic: Not sure how to precisely describe this in the spec. 17:45:53 Zhiheng: I understand. This kind of filtering may be confusing to the user. 17:46:45 Nic: In the case of 1x1 gif used a 100 times case, the browser would use a in memory cache to reuse this. I don't suggest that all several 100 be included in the cache, only the initial request? 17:47:29 Anderson: Tony, James, any comments on the approach that we capture timing for the downloadable? Anything that was in memory cache, we don't necessarily have timing information for. 17:47:51 Tony: The difference between the memory cache and the disk cache would be confusing for the user. 17:48:09 Tony: We should think about here is what the page downloaded rather than downloadable. 17:48:26 Anderson: Downloaded instead of downloadable? 17:48:59 Tony: Perhaps. Reduces confusion about memory and disk cache. 17:49:19 Nic: The worry here is that it gives higher precision to if resources weren't in the cache. 17:49:29 Tony: I forgot what the privacy concern was. 17:49:43 Nic: For example, you can build an attacker page that includes a bank logo. 17:49:54 Tony: We want to report anything that is cross origin. 17:51:02 Nic: We wouldn't be providing anything we just saying fetchStart and loadEnd. Not including it from the list would say for sure it was. Not sure how important this is. 17:51:05 Tony: I see, makes sense. 17:51:41 Zhiheng: Example is there is a page, and I want to see if the user has visited a bank page. I can still get that information. If I don't see the timing in the resource timing interface, I can assume that this is the cache. 17:51:50 Nic: Correct, if we didn't include things into the cache. 17:52:03 Zhiheng: They can still guess if a user ever visited a page. 17:52:43 Nic: They can get that today. There is a higher precision if we're saying that if its not cached, we'll put it in the cache. I know its not a huge difference, but its a stronger indication that its in the cache. 17:53:10 Zhiheng: If you posted a request but you don't see a timing in the buffer, you can see this also. 17:53:18 Anderson: Good point. 17:53:38 Tony: Maybe we should only expose timing for same origin. 17:54:04 Anderson: I know this is where Jason would step in and say he would like cross domain origin. 17:54:42 Tony: I think he's interested in the additional details. 17:55:16 Anderson: Certainly, adds more pressure for us to come up with a solution for cross domain access. 17:56:09 Karen: Even same origin, this issue is important. The tracking of a user's browsing history is important privacy concern. Say on a banking site, you put a resources for checking, saving account - one could deduce what kind of user is on the page. Now you're dealing with a tracking of a user. 17:56:24 Nic: If you own the domain, you own everything on it. You own the server technology. 17:56:50 Karen: You could theoritically do this through sessions, but now you know through the JSON session, you know it's one user. 17:57:16 Tony: Sounds like the big homework for this week will be figuring out when things should go into the event log. 17:57:23 Zhiheng: Yes, agree. 17:57:58 Anderson: Alright then, let's follow up with the various proposals of accessing resources and where we would log. The when and where question. 17:58:12 Anderson: Hard stop at 10? 17:58:19 Zhiheng: I can stay. 17:58:29 Arvind: I will leave. 17:58:38 regrets: Arvind 17:58:43 regret: Arvind 17:59:14 Anderson: Let's move to User Timing 17:59:15 http://test.w3.org/webperf/specs/UserTiming/ 17:59:29 Anderson: Some points I wanted to raise. Let's first go over deltas. 17:59:55 First set of changes was that the marks were added and three additional measure apis were added. 18:00:43 Anderson: One thing I wanted to note was that the difference between the user timing and resource timing, is that the marks/data is not generated by the UA, but rather developed by the developer. 18:00:46 Tony: Right. 18:01:10 Anderson: I should add that you can measure from a user agent mark. Like a navigation start. 18:01:15 Zhiheng: Sounds good. 18:01:35 Tony: We are getting kicked out from our room. 18:02:25 Zhiheng: Navigation start lives in a different namespace. 18:02:55 Anderson: If a UA supplied mark name, we recommend throwing an exception - make it read only and don't store the time stamp. 18:03:35 Anderson: How's the weather in mountain view? 18:04:07 Zhiheng: Great! 18:06:05 The bridge won't let us back in... "the conference is restricted at this time" 18:07:04 Anderson: Let's adjourn. 18:07:36 Zhiheng: If you want another meeting this week, I'm open. 18:07:40 Okay, we'll do some homework and talk to you next week 18:07:45 Anderson: I love progress! 18:10:33 set logs world-visible 18:11:00 rrsagent, set logs world-visible 18:11:17 rrsagent, generate minutes 18:11:17 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html Jatinder 18:11:45 rrsagent, set logs world-visible 18:11:56 rrsagent, generate minutes 18:11:56 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html Jatinder 18:17:38 Present+ Jatinder Mann 18:17:46 Present+ Nic Jansma 18:17:56 Present+ Anderson 18:19:00 Present+ Tonyg 18:47:13 plh has left #webperf 19:04:33 RWC_web-per(WPWG)12:00PM has ended 19:04:35 Attendees were 19:19:34 rrsagent, generate minutes 19:19:34 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html AndersonQuach 19:20:00 Regrets- Arvind 19:20:04 Present+ Arvind 19:20:08 chair+ Arvind 19:20:21 present+ JamesSimonsen 19:20:25 present+ JasonWeber 19:20:33 present+ plh 19:20:40 present+ Zhiheng 19:20:44 rrsagent, generate minutes 19:20:44 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html AndersonQuach 19:21:36 Chair:Arvind 19:21:46 rrsagent, generate minutes 19:21:46 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html AndersonQuach 19:23:44 Zakim has left #webperf 19:24:04 Zakim has joined #webperf 19:46:07 present- Mann 19:46:12 rrsagent, generate minutes 19:46:12 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html AndersonQuach 19:47:14 present- Jansma 19:47:35 rrsagent, generate minutes 19:47:35 I have made the request to generate http://www.w3.org/2011/03/09-webperf-minutes.html AndersonQuach 19:50:27 Restarting in 2 minutes to recover bridge caller information. Please poke #sysreq if that is unacceptable to you 19:51:29 Restarting bot only -- won't affect callers