Services/Sync/NextGen: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 5: Line 5:
= Overview =
= Overview =


Sync is a highly useful feature, but has so far failed to achieve widespread adoption.  We believe Sync to be an important piece of the Firefox experience, and our goal is to deliver a much more attractive product to support continued Firefox growth.  We are tentatively targeting Firefox 20 as the GA for this new version of the service.
Sync is a very useful feature, but has so far failed to achieve widespread adoption.  We believe Sync to be an important piece of the Firefox experience, and our goal is to deliver a much more attractive product to support continued Firefox growth.  We are tentatively targeting Firefox 20 as the GA for this new version of the service.


= Use Cases =
= Use Cases =
Line 38: Line 38:
== Identification ==
== Identification ==


The implementation of the next generation Sync feature will be centered around Persona. The Identity team will work to define and deploy a special type of IdP, which I'll refer to as a "Preferred IdP" or PIdP for short. This IdP will support an auth protocol designed to prevent disclosure of the user's Persona passphrase to the server, as well as enabling non-browser clients to directly authenticate without a browser context. In addition to a secure authentication protocol, a PIdP will also expose an API to obtain a wrapped encryption key (known as the User Key, or UK). This key will be encrypted and decrypted on the client, using a key derived from the Persona passphrase. The User Key will not be exposed to consumers, but will be used by the Persona client to encrypt and decrypt a per-service encryption key (known as a Service Key or SK) on request.
The implementation of the next generation Sync feature will be centered around Persona. The Identity team will work to define and deploy a special type of IdP, to which we'll refer as a "Preferred IdP" or PIdP for short. This IdP will support an auth protocol designed to prevent disclosure of the user's Persona passphrase to the server, as well as enabling non-browser clients to directly authenticate without a browser context. In addition to a secure authentication protocol, a PIdP will also expose an API to obtain a wrapped encryption key (known as the User Key, or UK). This key will be encrypted and decrypted on the client, using a key derived from the Persona passphrase. The User Key will not be exposed to consumers, but will be used by the Persona client to encrypt and decrypt a per-service encryption key (known as a Service Key or SK) on request.


== Service Authentication ==
== Service Authentication ==
Line 54: Line 54:
|[[image:Sync 2.0.png|none|thumb|471px]]
|[[image:Sync 2.0.png|none|thumb|471px]]
|}
|}
= High-level roadmap =
(rnewman writing now)
More details are in [[Services/Sync/NextGen/TechnicalPlan|the technical plan]].


= Open Questions =
= Open Questions =
Line 63: Line 69:
** For how long?
** For how long?
** Assumption: even if shipping in parallel, not simultaneously functional. This would be an undue development and testing burden.
** Assumption: even if shipping in parallel, not simultaneously functional. This would be an undue development and testing burden.
*** We're going to ship in parallel until we reduce the users of previous generation sync to some minimal level at which point we'll EOL the previous version. - A
*** We're going to ship in parallel until we reduce the users of previous generation Sync to some minimal level at which point we'll EOL the previous version. - A


* J-PAKE as an option for users? (Asa)
* J-PAKE as an option for users? (Asa)
Line 80: Line 86:
* What is the user expectation for data availability, above and beyond "the bits in the cloud don't go away"? Durability would mean we don't lose your bookmarks if you do nothing, but beyond that users might want to get back their bookmarks after they accidentally deleted them all. To what extent should backup/versioning etc. feature in our roadmap?
* What is the user expectation for data availability, above and beyond "the bits in the cloud don't go away"? Durability would mean we don't lose your bookmarks if you do nothing, but beyond that users might want to get back their bookmarks after they accidentally deleted them all. To what extent should backup/versioning etc. feature in our roadmap?
*** I hadn't considered versioning so this is just 'off the top of my head'. If we could do a "dated profile backup" every so often, plus before a Firefox upgrade, like a Windows Restore point, that would be pretty swell. - A
*** I hadn't considered versioning so this is just 'off the top of my head'. If we could do a "dated profile backup" every so often, plus before a Firefox upgrade, like a Windows Restore point, that would be pretty swell. - A
*** Options discussed: local snapshot of profile directory (because Sync doesn't sync per-machine stuff); snapshots to DropBox; snapshots to a Mozilla service. These are nice because it reduces the cost to the synchronization service.


* Is there a per-user uptime requirement? (Asa, mconnor)
* Is there a per-user uptime requirement? (Asa, mconnor)
Line 95: Line 102:
** This requires thought for technical delivery on mobile, too.
** This requires thought for technical delivery on mobile, too.
*** I'm not sure I understand this question. Tell me if this answer fits that question. We want users to create a Firefox account. If when they're creating that account, we see they're entering an existing Persona ID, we should prompt them to "upgrade" that ID (adding the Firefox Sync/Backup capability to that Persona ID) by re-typing their Persona password. Similarly, if at a later time the user encounters a site that utilizes Persona ID for logins, and the user starts typing in their Firefox ID, we can offer to "upgrade" their Firefox account to a Persona ID credential.  On the backend they're the same thing just with one bit set for Firefox enabled and one bit set for Persona ID enabled. Thunder has this all sorted out -- assuming I'm answering the question you've asked. - A
*** I'm not sure I understand this question. Tell me if this answer fits that question. We want users to create a Firefox account. If when they're creating that account, we see they're entering an existing Persona ID, we should prompt them to "upgrade" that ID (adding the Firefox Sync/Backup capability to that Persona ID) by re-typing their Persona password. Similarly, if at a later time the user encounters a site that utilizes Persona ID for logins, and the user starts typing in their Firefox ID, we can offer to "upgrade" their Firefox account to a Persona ID credential.  On the backend they're the same thing just with one bit set for Firefox enabled and one bit set for Persona ID enabled. Thunder has this all sorted out -- assuming I'm answering the question you've asked. - A
*** Discussion result: PIdP will be a top-level entity; essentially a standalone product/project. A Firefox Account will be surfaced within, say, the Firefox menu. Sync functionality is essentially a checkbox: "oh, now you have a Firefox Account, which browser data do you want to be synchronized?". Need to discuss this with Fx leads.


== Technical Questions ==
== Technical Questions ==
Line 107: Line 115:


* How does the account/PIdP login work on the client -- is this a general feature for the browser, or a Sync-specific feature?
* How does the account/PIdP login work on the client -- is this a general feature for the browser, or a Sync-specific feature?
 
** Answered: general feature.
More details are in [[Services/Sync/NextGen/TechnicalPlan|the technical plan]].
canmove, Confirmed users
640

edits

Navigation menu