canmove, Confirmed users
640
edits
Services/Sync/NextGen: Difference between revisions
no edit summary
No edit summary |
|||
| Line 37: | Line 37: | ||
== Identification == | == Identification == | ||
The implementation of the next generation Sync feature will be | 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. | ||
== Service Authentication == | == Service Authentication == | ||
| Line 53: | Line 53: | ||
* Are we still planning to ship old and new Sync products in parallel, or are we doing migration on upgrade? (Asa) | * Are we still planning to ship old and new Sync products in parallel, or are we doing migration on upgrade? (Asa) | ||
** mconnor: This has a non-zero cost, and we're talking about 0.5% of Firefox users. We can do it, but it adds difficult-to-scope time/complexity. | ** mconnor: This has a non-zero cost, and we're talking about 0.5% of Firefox users. We can do it, but it adds difficult-to-scope time/complexity. | ||
** For how long? | |||
** Assumption: even if shipping in parallel, not simultaneously functional. This would be an undue development and testing burden. | |||
* J-PAKE as an option for users? (Asa) | * J-PAKE as an option for users? (Asa) | ||
| Line 62: | Line 64: | ||
* What degree of durability is required for data stored on the service? (Asa, mconnor) | * What degree of durability is required for data stored on the service? (Asa, mconnor) | ||
** mconnor: This is going to be a budget question. It needs a cost/benefit tradeoff from mmayo's team. From prior discussions, more than 99.9999999% will be much more expensive, but 1 in a billion feels pretty okay. | ** mconnor: This is going to be a budget question. It needs a cost/benefit tradeoff from mmayo's team. From prior discussions, more than 99.9999999% will be much more expensive, but 1 in a billion feels pretty okay. | ||
* What is the user expectation for data availability, above and beyond "the bits in the cloud don't go away"? That is, a user doesn't give a fig about that most of the time; they want to get back their bookmarks after they accidentally deleted them all. To what extent should backup etc. feature in our roadmap? | |||
* Is there a per-user uptime requirement? (Asa, mconnor) | * Is there a per-user uptime requirement? (Asa, mconnor) | ||
** mconnor: I would propose 99.9% for any given user's data access, at the high end. This is the high end of what is viable with a single datacenter, and multi-datacenter would be prohibitively expensive. | ** mconnor: I would propose 99.9% for any given user's data access, at the high end. This is the high end of what is viable with a single datacenter, and multi-datacenter would be prohibitively expensive. | ||
** How would you define uptime requirement? A see many options. At any time N% of users have Sync working for them. Sync is working for any user N% of the time. Sync is available to a particular user N% of the time they attempt to connect to it. etc. | ** How would you define uptime requirement? A see many options. At any time N% of users have Sync working for them. Sync is working for any user N% of the time. Sync is available to a particular user N% of the time they attempt to connect to it. etc. | ||
* How should migration be messaged? Is it sufficient to have a note on the newly set-up device saying that your other devices need to be upgraded? A non-fatal notice on the old devices (requires work now)? A fatal error on the old devices? | |||
== Technical Questions == | == Technical Questions == | ||
| Line 76: | Line 82: | ||
* Are there any further changes required to the v6 storage format? (gps) | * Are there any further changes required to the v6 storage format? (gps) | ||
* How does the account/PIdP login work on the client -- is this a general feature for the browser, or a Sync-specific feature? | |||
More details are in [[Services/Sync/NextGen/TechnicalPlan|the technical plan]]. | More details are in [[Services/Sync/NextGen/TechnicalPlan|the technical plan]]. | ||