THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Purpose

This page documents our current understanding of work items required to deliver the next generation of Sync.

Client development

Shared

Dependencies

• PIdP with key wrapping and REST API.
  • Mobile will involve implementing PIdP client.
  • Desktop depends on Firefox PIdP client.
• Server availability. Deployment, load testing; various phases.
• New crypto impl (ddahl/bsmith).

Risks

• Durability demands.
• Client interop with desktop.
• UX portions are blocked on Product/UX coherency.
• Inadequate time for sec review.

Desktop Firefox

Point of contact

gps

Status

• Part of preliminary refactoring complete.

High-level approach

• Refactor existing code base to support multiple sync instances
• Create a new implementation of Sync client speaking protocol 2.0 and storage format 6
• Dependency: setup UI for new system
• Hook up UI for new client
• Integrate, test, migrate TPS, write QA plan, load test.

Firefox for Mobile

Point of contact

rnewman

High-level approach

• Build a pure-Java Android Account and authenticator that interact with a PIdP to offer Persona services and key wrapping to our applications.
  • Including UX.
• Implement the Sync 2.0 protocol and Storage Format 6 in the Android Sync codebase.
• Link the two.

Likely we'll implement the 2.0 protocol with SF5 and fake auth, then swap in live auth, and finally rev the storage format.

Work Breakdown and Open Questions

This falls into three main parts: setup UX, request authentication, and key handling.

Request authentication

• Build new assertion-based authentication mechanism for HTTP requests.
  • Extend/abstract CredentialsSource, BaseResource, SyncAdapter, ….
  • Automated tests.

Key and credentials handling

• Implement a Persona authenticator service to return assertions instead of credentials.
  • Consider impact on design of possibly providing system-wide Persona accounts.
    • We need to consider carefully who is responsible for storing keys. Having the Persona authenticator store service keys probably means system-wide Persona accounts are too risky, since the risk of providing a service key to a malicious App is high and there is no way to revoke access.
  • Consider impact of supporting multiple Firefox versions.
    • if we package Persona with Firefox AND store secret data on the Account object, then sharedUserId history ties us to the current 2/2/1 account type scheme.
  • The authenticator will now make HTTP requests….
    • This is expressly part of the Android Account architecture.
• Implement key wrapping and Sync Key fetching functionality.
  • What to do if one of the keys appears to be wrong?
  • Do we need to do anything if a user changes their Persona password?
  • User-input key, as well as key wrapping…
• Credentials migration.
  • Does Android Sync have to wrap and upload your key if it gets there first?!
• Privacy and sec review.
• Thorough tests.

UX

• Alter icons and strings.
• Implement PIdP login screens, error handling UI, help links.
  • Fallback to non-key-storage version: soliciting a key.
  • J-PAKE integration for people who don't like typing.
• Write setup and support docs for SUMO.
• QA scripts.

Risks and dependencies

• Existing massive Android Sync work backlog, along with Aurora and Beta support.

Tentative target timeline

• Code reading and design: 2 weeks. Will revise subsequent estimates.
• HTTP layer changes: 3 weeks.
• Firefox Account authenticator: 5 weeks. (Hazy. Depends on PIdP design and impl.)
• Key fetching and unwrapping: 3 weeks.
• Dual-version integration overhead: ~6 weeks. (Hazy.)
• Setup and management UI:
  • Design iteration: 4 weeks
  • Implementation: 6 weeks or more.
• Storage format changes: 4 weeks.
• Robustness, testing, baking: as long as we have.

Firefox OS

Not targeted for v1/Basecamp.

Third-party clients

Will address messaging in Q4.

Server development

The majority of server-side work for Sync 2.0 is already complete. Still outstanding:

• Finalize any remaining tweaks to the specification (bug 720964)
  • Version numbers vs timestamps (bug 787870)
  • Bulk-update of TTLs (bug 784599)
  • Add an "upgrade required" response (bug 785045)
  • Details of error-response format (bug 784592)
• Load testing
• Client integration testing
• Packaging and docs for people who want to run their own server.
• Deployment (see Ops, below)

We also need to decide on one or more strategies for people who want to run/host their own servers. Some possibilities:

• Run their own syncserver and tokenserver, but use Preferred IdP provided by Moz
• Run syncserver, tokenserver and Preferred IdP without involving Moz at all

Operational constraints

Question out to bobm/ckolos to figure out deployment schedules.

Ballpark: once FTE resources are available, estimate about 3 months from PO to lights on. Operations is understaffed.

Dependency: colo space.

Identity

• PIdP design, implementation, security review.
• …

Callouts

Work items above and beyond mentions in the above:

• Capacity planning
• SUMO article rewrites
• Overall system qualifications, load tests
• QA plans
• Developer documentation for add-on authors and third-party clients