Services/Sync/Push to device

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

The value proposition of Sync for a mobile user is "Get up and go." Push to device is specific to the user sending a particular link to a device.

2. Users & use cases

• Send a link from desktop Firefox to mobile Firefox
  • Bob has Sync set up on his desktop and mobile device.
  • Bob is reading a New York Times article on his desktop and has to leave, but wants to keep reading his train ride home.
  • Through Firefox Desktop, Bob sends the link to the page he is on to his mobile device
  • When Bob opens up his phone the page he just sent pops up.
  • NOTE: Is this the use case?

• Send a link from mobile Firefox to desktop Firefox
  • Bob has Sync set up on his desktop and mobile device.
  • Bob is reading a New York Times article on his phone during his morning commute.
  • He reaches the office and wants to keep reading on his desktop.
  • Through Firefox Mobile, Bob sends the link to the page he is on to his desktop
  • When Bob startups up Firefox (or goes to Firefox) the page he just sent pops up.
  • NOTE: Is this the use case?

3. Dependencies

• bug 507471 - Send tab to device
• bug 677372 - Send tab to device: UX Design
• bug 676375 - Send tab to device: Core API
• bug 686704 - Send tab to device: support tab state

4. Requirements

The following data is sent across devices:

• Session cookies
• Form fields
• Page position (element, not pixel position - to avoid form factor mismatch)

Non-goals

• Need better clarity on use cases before filling this out

Stage 2: Design

5. Functional specification

`

6. User experience design

The following are needed from UX:

• How do we trigger the feature?
  • Context menu when cursor over link?
  • Context menu anywhere on page?
  • Context menu on tab in tab browser?
  • Other?
• Shortcut key(s) for above?
• Images (for mobile) for above
• What is the wording for above?
• What does the design of the above look like
  • Do we have sub-menu's listing target devices?
  • Do we have a modal window/pane?
  • Limited to sending to 1 device?
• What's the behavior if Sync is not configured?
• What's the behavior if multiple devices are not configured?
• This will likely be the first time device names are seen by most users (currently buried in Sync preferences). Will that cause any issues?
  • Poor device naming
  • Orphaned/unused devices
  • etc
• What happens when a browser receives a link?
  • Is new tab opened automatically?
    • Does it gain focus?
• What do we do if the receiver receives a HTTP redirect or URI change (via JavaScript)?
  • A user having sent form data between devices might be upset that the page redirected to a mobile or desktop version and lost the form data. This isn't technically Firefox's fault, but it may be perceived as that. Should the browser consider detecting this and informing the user as such? i.e. "we did what you wanted but the site didn't preserve all your (important) data."
• Anything else

Some questions may require separate answers for separate form factors.

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

The feature will be built on top of Sync and therefore Sync's data security model applies. Each tab sent between devices will result in a "tab state" record being uploaded to the Sync server. The ID of this record (the part that appears in the URI) is randomly generated. The payload of the record is encrypted on the client using the private Sync Key. The ID is transferred between clients by a modification to the client's record. This client record is also encrypted locally using the Sync Key. In other words, no data is readable without the Sync Key.

The Sync server does leak timing information when "send tab" records are uploaded. However, we currently have timing leaks from other data sources (e.g. history). By looking at the upload time of the "send tab" record and the modification time of a specific client record, it would be possible for a server operator or person with authentication credentials (but not the Sync Key) to glean when a tab is sent to a specific device. This is slightly worse than the current world, where the server only sees client record modification in rare events (e.g. wipe client requests) and the actual record modification may not be determinable. When a client receiving a tab downloads its client record, it will see the command to load a tab. The client will then download the tab state record and process it. On the next sync, the client record for that device will be replaced with one not containing the send tab command. Timing information could then be used to determine when a device was used. Again, this is similar to how existing commands work. The biggest difference is send tab commands are expected to be sent with a relatively higher frequency than existing commands.

The UX will live in tabbrowser on Firefox, the icon sidebar thing on mobile, and whatever that button grid is on tablets. The UX will call into Sync's code with an instance of a tab/browser to send. Sync will collect a tab's form data, session cookies (attached to the host belonging to the URI of the main "frame" only - at least for starters), and position in page. It will run with Chrome privileges, just like Sync. It likely calls into Session Store to perform some of these actions, but it may access low-level APIs as appropriate. Once data is collected, it is encrypted and uploaded to the server on the next sync.

The Sync engine will notify an nsIObserver upon receipt of a send tab command. The observer handler will live in browser/components/nsBrowserGlue.js on Firefox and browser.js (or similar) on Fennec (and whatever the Java equivalent is). The observer handler takes care of creating the new tab from the decoded record data. Currently, this is implemented as a function call into Sync. This all happens with Chrome privileges.

Privacy review

Since the feature is utilizing Sync, all data will be encrypted on the client side and stored on Mozilla's servers such that Mozilla cannot decrypt the data.

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

Questions from dev to Ops:

• A new server-side collection will be introduced, *sendtab*. Do we want to define the collection in the Sync Server/MySQL schema?
• There is a possibility records could be orphaned on the server for a while. What should the auto-expire TTL be?

Questions from Ops to dev:

• How much storage will the new records accumulate?
  • [gps] This will require guessing how often the feature is used and by how many people.

Stage 4: Development

9. Implementation

The clients engine will support a new command, "displayTab." This command takes as payload a URI and an optional record identifier.

The record identifier, if defined, points to a remote record stored in the "sendtab" collection on the server. The record identifier is, like other record IDs, randomly generated for security purposes. The payload is encrypted, just like other Sync records.

The remote record contains metadata to restore tab state on the receiving machine. This metadata includes:

• session cookies
• form data
• page position

Eventually, this metadata will include more of what's available inside the nsISessionStore.getTabState() object, including:

• Tab history
• Custom styles

When a client receives a *displayTab* command, it fetches the metadata record, if present. It generates an observable event containing all the data. An observer in the chrome thread handles this and reconstructs the tab on the receiving device.

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes