Personal tools

Services/AndroidSyncFP

From MozillaWiki

Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Status

Firefox Sync for Android
Stage Draft
Status In progress
Release target Fennec Native
Health OK
Status note `

Team

Product manager Jennifer Arguello
Directly Responsible Individual Mike Connor
Lead engineer Richard Newman
Security lead Ian Melven
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead Madhava Enros
Product marketing lead `
Operations lead `
Additional members Chenxia Liu, Jason Voll

Open issues/risks

  • Where do we store passwords?
  • What are the privacy etc. implications of using the system data stores?
  • Will the mobile team decide to switch data stores?
  • How do we do distribution? If it's linked to Fennec, how do we handle uninstallation, clearing data, etc.?

Stage 1: Definition

1. Feature overview

Sync for Android will run as a background service (bundled with Fennec, probably also available separately). This will provide background syncing, just as do other data sources on Android (weather, Twitter, stocks, Google contacts…).

Setup will be accessible from "Accounts & Sync" in the system preferences pane.

Synced data will be fully interoperable with Firefox on the desktop, and backwards compatible with previous versions of Fennec.

Setup will support the new flows implemented in Firefox 10 for Desktop and Mobile [1] to maximize user uptake.

[1] allFlows-i2.png

2. Users & use cases

Sync to and from your Android device for (in priority order):

  • Bookmarks
  • History
  • Passwords (Q1? Still waiting for feature definition to firm up.)
  • Tabs (Q1)
  • Form Data (Q1)
  • Prefs (Q1)

3. Dependencies

  • Exposed + stable (and ideally async) APIs to local storage for synced data types as enumerated above.

4. Requirements

  • Sync must run as a background service, respecting the system sync prefs (e.g., not syncing while roaming).
  • This implementation must be fully compatible with current Sync/Firefox implementations.
  • When you get to the end of this setup flow, we want you to be able to hit "back" and actually end up back in Firefox.

Non-goals

  • Any sort of revised security/setup scheme that would break compatibility with other clients.
  • Any additional features beyond those currently supported on Fennec.

Stage 2: Design

5. Functional specification

`

6. User experience design

Here is a diagram/mockups of the Android-side setup and prefs flows: http://www.flickr.com/photos/madhava_work/6360153407/sizes/o/in/photostream/ (caution - large image)

Stage 3: Planning

7. Implementation plan

Estimated attack sequence

 liuche:   -- UI ---------------------- ...
 rnewman:  -- Cryp. Rev. -- Network --- ... 
 jvoll:    -- Repositories ------------ ...

Justification:

  • UI is a big work item, and has lots of possible pitfalls, so get started now. Need an 'owner' for this. That's liuche.
  • Repositories are standalone, follow an existing design, and have possible pitfalls. Let's get started on these, with tests if we can. jvoll is on that.
  • The existing crypto code needs review and analysis from a broader perspective. That should happen before, e.g., J-PAKE tries to use it.
  • After that, start working through the bits that need to be built, starting at the edge and working back.
  • After some development experience, we can nail down the rest of the plan.

8. Reviews

Security review

  • Sec review Nov 18th.

Privacy review

  • None scheduled.

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

Components, in approximate independent chunks

  • Network: talking to Sync server.
    • Interacts with credentials storage for username/password for Basic Auth.
    • Generates and consumes records via crypto middleware (or not, for non-encrypted records).
    • Extend record formats in https://github.com/mozilla-services/android-sync.
    • Raises protocol-level exceptions: 401, 503 with Retry-After/X-Weave-Backoff, .... Consumed by service equivalent.
  • Crypto. Consumes encrypted or decrypted records, produces the other.
    • Must be heavily tested. Expect this to get detailed security review at some point.
    • Raises crypto exceptions to be consumed by service.
    • Interacts with credentials storage to obtain Sync Key to decrypt key bundle.
      • Likely via some orchestrating component to eliminate an external dependency.
  • UI: pref pane, setup wizard.
    • Implement full J-PAKE flow.
    • Interacts with credentials storage, of course.
    • Also: triggered by service on processing of credentials errors (e.g., 401)...
    • Preferences a la Google account for individual engines.
  • Repository implementations for:
    • Bookmarks
    • History
    • Passwords
      • Will involve substantial new storage work.
    • ...

Stage 5: Release

10. Landing criteria

`


Feature details

Priority P1
Rank 999
Theme / Goal `
Roadmap Firefox Mobile
Secondary roadmap Sync
Feature list Mobile
Project `
Engineering team Services

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-complete 2011-11-18 Notes
Privacy priv-review-needed `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `