RE: [minutes] 20110216 Web Performance WG

During today's conference call, we discussed the specific scenarios that the unloadEventStart and unloadEventEnd attributes should be zeroed out due to same-origin security concerns, specifically related to scenarios when a redirect is in the middle of the navigation.

For the sake of clarity, here are four scenarios:
A) Previous document and current document are the same origin: a.com -> a.com
B) Previous document and current document are different origin: a.com -> b.com
C) Previous document and current document are the same origin and a redirect is in the middle with the same origin: a.com -> a.com (301 redirect) -> a.com
D) Previous document and current document are the same origin and a redirect is in the middle with a different origin: a.com -> b.com (301 redirect) -> a.com

We have previously agreed that the unloadEvent* attributes are accessible in Scenarios A and C, and are zeroed out in Scenario B.

Recommendation
The question is what happens in Scenario D, since the unloadEvent* timings do not specifically convey information about the middle different-origin redirecting domain (b.com).  It is our recommendation to also zero out the unloadEvent* attributes for Scenario D for the sake of design simplicity and to be more conservative with respect to exposing the unload event timestamps.

The current NavigationTiming<https://dvcs.w3.org/hg/webperf/raw-file/03b9fc95eee9/specs/NavigationTiming/Overview.html> spec reads:
unloadEventStart attribute

If the previous document and the current document have the same origin<http://dev.w3.org/html5/spec/origin-0.html#origin>, this attribute must return the time immediately before the user agent starts the unload<http://dev.w3.org/html5/spec/history.html#unloading-documents> event of the previous document. If there is no previous document or the previous document has a different origin<http://dev.w3.org/html5/spec/origin-0.html#origin> than the current document, this attribute must return zero.

unloadEventEnd attribute

If the previous document and the current document have the same origin<http://dev.w3.org/html5/spec/origin-0.html#origin>, this attribute must return the time immediately after the user agent finishes the unload<http://dev.w3.org/html5/spec/history.html#unload-a-document> event of the previous document. If there is no previous document or the previous document has a different origin<http://dev.w3.org/html5/spec/origin-0.html#origin> than the current document or the unload is not yet completed, this attribute must return zero.

If there are HTTP redirects or equivalent<http://dev.w3.org/html5/spec/fetching-resources.html#concept-http-equivalent-codes> when navigating and not all the redirects or equivalent are from the same origin<http://dev.w3.org/html5/spec/origin-0.html#origin>, both unloadEventStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#nt-unload-start> and unloadEventEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#ut-unload-end> must return the zero.
The question on the conference call was whether or not zeroing out the unloadEventStart and unloadEventEnd attributes in Scenario D is necessary.  We wanted to ensure that, if we allowed unloadEventStart and unloadEventEnd in Scenario D, there would be no security or privacy concerns.  For example, if either of these timings are highly correlated with the redirectStart of the middle redirected resource (b.com in Scenario D), one might be able to infer the redirectStart timing even if that attribute is zeroed out due to our same-origin policy.

We investigated this from the perspective of IE's implementation, we do not believe that the unloadEvent timings can be correlated with timings of the redirected part of the navigation.  In IE, the unload event will occur around the time of responseStart for the final non-redirected navigation (aka the current document), and not during the redirection phase.

However, we also think there is some simplicity in keeping the NavigationTiming spec as it currently states: zeroing out the unloadEvent* attributes in the case that "not all the redirects or equivalent are from the same origin<http://dev.w3.org/html5/spec/origin-0.html#origin>".  This aligns with policy for the navigationStart and redirect* attributes.  If instead we change it to separate out Scenario D and allow access for the unloadEvent* attributes, the UA must keep track of more information than whether or not all pages in the navigation path were of the same origin.  If Scenario D is allowed, the UA must not only keep track of the same origin of the previous and current document for the unloadEventStart and unloadEventEnd attributes, but also keep separate track of the origin of the entire navigation path for purposes of securing the navigationStart, redirectStart, redirectEnd, and redirectCount attributes.  This leads to a more complex implementation and a potential point of confusion if one set of attributes cares about redirected origins and the other set does not.

The spec currently describes zeroing out the navigationStart, redirectStart, redirectEnd, redirectCount, unloadEventStart and unloadEventEnd attributes for Scenarios B and D.  We suggest leaving the spec as-is.

- Nic

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Anderson Quach
Sent: Wednesday, February 16, 2011 12:43 PM
To: public-web-perf
Subject: [minutes] 20110216 Web Performance WG

Web Performance Working Group
16 Feb 2011

See also: IRC log<http://www.w3.org/2011/02/16-webperf-irc>

Minutes
http://www.w3.org/2011/02/16-webperf-minutes.html
Attendees
Present
+1.650.253.aaaa, [Microsoft], +1.650.214.aabb, +1.415.829.aacc, ArvindJain, JasonWeber, NicJansma, Zhiheng, TonyG, AndersonQuach, JamesSimonsen
Regrets
Chair
JasonWeber
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2011/02/16-webperf-minutes.html#agenda>
1.        Discuss feedback on the latest Navigation Timing" taken up<http://www.w3.org/2011/02/16-webperf-minutes.html#item01>
2.        Web Perf SIG/Charter: Visibility API<http://www.w3.org/2011/02/16-webperf-minutes.html#item02>
3.        Summary<http://www.w3.org/2011/02/16-webperf-minutes.html#item03>

         i.            Clarification on what to do with the unload timestamps when a non-same origin redirection is encountered. Nic will send out notes on the behavior from IE.

        ii.            The WG will review the proposed tests for Navigation Timing.

      iii.            On 2/15/2011 we'll expand the meeting to include a 1hr discussion on re-chartering to include APIs to help web-apps conserve battery and promote efficient painting. Followed by 10-11 to continue discussions on Navigation Timing and moving towards CR.

      iv.            On 2/15/2011 10-11A PST we'll continue discussions on User Timing and Resource Timing.



________________________________

move to agenda 6

<scribe> scribe: AndersonQuach
Discuss feedback on the latest Navigation Timing" taken up

Zhiheng: There's ambiguity in the spec with the current definition of same-origin wrt to navigationStart and fetchStart.

http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0068.html

Zhiheng: Want clarification on what to do with unload when the previous navigation is of a different from the current navigation.

TonyG: Are you making this more strict or less strict?

<zhihengw> page A ---> Page B ---> Page A

JamesSimonsen: The definition in 4.2 is clearer in terms of the normative behavior of unload.

NicJansma: Our concerns is exposing the unload events were correlated with the timestamp with the middle redirection in user-agents. I don't know if that's the case we can test this out with a network analyzer and in browsers like IE.
... Need to understand if unload events can be correlated to any time stamp that is zeroed out like redirects.
... We'll get back to the mailing list as to the behavior of unload later today.

move to agenda 8
Web Perf SIG/Charter: Visibility API

ArvindJain: I want to get a sense for the Visibility API for the Web Performance Working Group.

JasonWeber: We're supportive of adding this API to the Web Perf charter to standardize this.
... From our reserach, this is a larger problem and domain beyond Web Perf.
... We're seeing this related to CPU consumption of foreground and background tabs, as it relates to painting, animation and thread/application activity to conserve power.

ArvindJain: Sounds like a great idea.

JasonWeber: We should discuss what we want to include in that charter expansion and start the re-chartering.

ArvindJain: Makes sense, let's do that.
... We'll let folks to respond on the mailing thread and go from there.
... Can you invite other user-agents to discuss this area?

JasonWeber: I'll reach out.
... Do you want to schedule separate time to discuss the re-charter?

ArvindJain: I'm okay with extending the call from 9-10 for Nav Timing and 10-11 for the re-chartering.

JasonWeber: Let's do it the other way around, 9-10 for the re-chartering and 10-11 for Nav Timing.

TonyG: Do we want to cover efficient JavaScript animations like mozRequestAnimationFrame?

JasonWeber: Sounds good.

ArvindJain: Sounds good.

AndersonQuach: I'd love to work towards getting traction on approval of the test cases and go over the feedback on user timing.

NicJansma: We had User Timings prototyped in the Beta and early Platform Previews of IE9. We did see the values of having measures.
Summary

i. Clarification on what to do with the unload timestamps when a non-same origin redirection is encountered.

ii. The WG will review the proposed tests for Navigation Timing.

iii. On 2/15/2011 we'll expand the meeting to include a 1hr discussion on re-chartering to include APIs to help web-apps conserve battery and promote efficient painting. Followed by 10-11 to continue discussions on Navigation Timing and moving towards CR.

vi. On 2/15/2011 10-11A PST we'll continue discussions on User Timing and Resource Timing.