Features/Platform/NavigationTimingAPI

From MozillaWiki
< Features‎ | Platform
Revision as of 21:36, 9 November 2011 by Curtisk (talk | contribs)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Support for NavigationTiming interfaces
Stage Complete
Status Complete
Release target Firefox 7
Health OK
Status note Done.

{{#set:Feature name=Support for NavigationTiming interfaces

|Feature stage=Complete |Feature status=Complete |Feature version=Firefox 7 |Feature health=OK |Feature status note=Done. }}

Team

Product manager Chris Blizzard
Directly Responsible Individual Chris Blizzard
Lead engineer Christian Biesinger
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Chris Blizzard

|Feature feature manager=Chris Blizzard |Feature lead engineer=Christian Biesinger |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Implements part of the web timing interface, specifically http://www.w3.org/TR/navigation-timing/

2. Users & use cases

Implement W3C spec. Let web developers get detailed real-life timing information on their website so they know what they can do to speed it up.

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

https://bugzilla.mozilla.org/show_bug.cgi?id=554045

Has the full list of dependent bugs. We've got Navigation Timing done. Others are waiting on more specs.

8. Reviews

Security review

Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • for web pages to get timining info about page load
    • how long dns resolution took
    • how long connection setup took
    • transfer time took
    • Dates (like Date.now()), not durations
  • this is only about the html page
    • other timing interfaces in a different api (ResourceTiming)
    • doesn't expose URLs
  • web performance working group at W3C has the spec for this

What solutions/approaches were considered other than the proposed solution?

  • spec compliance

Why was this solution chosen?

  • spec compliance / feature parity
  • IE and Chrome also have this

Any security threats already considered in the design and why?=

  • Spec mentions: detecting proxy servers, ..., avoid exposing URLs
  • spec mentions using same origin policy (editors draft; CR)

Threat Brainstorming (30-40 minutes)

  • [privacy] Precise, broken-down timing information as a side channel for information leaks
  • [privacy] Fingerprinting users (or groups of users!!!) by performance characteristics
  • Redirect count is pinned to 0 if any of the redirects were third-party. So if you know the last piece was a same-host redirect, the 0 tells you it went through another party :/

Conclusions / Action Items (10-20 minutes)

  • [dveditz] Point the Tor folks at the pref for disabling this feature (dom.enable_performance)
  • [curtisk] talk to Sid about privacy
  • why is the IE implementation partial? did they have a problem with something, or were those properties simply not interest

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=Implements part of the web timing interface, specifically http://www.w3.org/TR/navigation-timing/ |Feature users and use cases=Implement W3C spec. Let web developers get detailed real-life timing information on their website so they know what they can do to speed it up. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=https://bugzilla.mozilla.org/show_bug.cgi?id=554045

Has the full list of dependent bugs. We've got Navigation Timing done. Others are waiting on more specs. |Feature security review=* W3C Spec: http://www.w3.org/TR/2011/CR-navigation-timing-20110315/

Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • for web pages to get timining info about page load
    • how long dns resolution took
    • how long connection setup took
    • transfer time took
    • Dates (like Date.now()), not durations
  • this is only about the html page
    • other timing interfaces in a different api (ResourceTiming)
    • doesn't expose URLs
  • web performance working group at W3C has the spec for this

What solutions/approaches were considered other than the proposed solution?

  • spec compliance

Why was this solution chosen?

  • spec compliance / feature parity
  • IE and Chrome also have this

Any security threats already considered in the design and why?=

  • Spec mentions: detecting proxy servers, ..., avoid exposing URLs
  • spec mentions using same origin policy (editors draft; CR)

Threat Brainstorming (30-40 minutes)

  • [privacy] Precise, broken-down timing information as a side channel for information leaks
  • [privacy] Fingerprinting users (or groups of users!!!) by performance characteristics
  • Redirect count is pinned to 0 if any of the redirects were third-party. So if you know the last piece was a same-host redirect, the 0 tells you it went through another party :/

Conclusions / Action Items (10-20 minutes)

  • [dveditz] Point the Tor folks at the pref for disabling this feature (dom.enable_performance)
  • [curtisk] talk to Sid about privacy
  • why is the IE implementation partial? did they have a problem with something, or were those properties simply not interest

|Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority P2
Rank 999
Theme / Goal `
Roadmap Platform
Secondary roadmap `
Feature list Platform
Project Responsiveness
Engineering team Networking

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=` |Feature roadmap=Platform |Feature secondary roadmap=` |Feature list=Platform |Feature project=Responsiveness |Feature engineering team=Networking }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-complete 2011.10.17: sid recommends a full review on this one Sched: 2011.11.09
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-complete |Feature security health=` |Feature security notes=2011.10.17: sid recommends a full review on this one Sched: 2011.11.09 |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}