On Aug 12, 2013, at 5:05 AM, Andreas Gal <[email protected]> wrote:
> > > Ryan Kelly wrote: >> >> On 12/08/2013 11:38 AM, Andreas Gal wrote: >>> Ryan Kelly wrote: >>>> On 11/08/2013 4:36 PM, Andreas Gal wrote: >>>>> once we went >>>>> through one flag day and have the data stored in cleartext we can do >>>>> arbitrary storage format and wire protocol format changes. >>>>> >>>>> Worst case we have to operate two services against the same data store >>>>> (reving the wire format), or the same service against two data stores >>>>> that we cross replicate (reving the storage format). >>>> This seems to be implying cleartext storage of the data on our servers, >>>> which is fundamentally at odds with the user stories as written. >>> The user stories ask for recoverable passwords, which means Mozilla >>> stores encrypted data plus the actual keys, so we can get to the >>> cleartext data as needed to do arbitrary storage conversions. >> >> They also require that data can be opted-out of this recoverability; by >> default for passwords, and optionally for all data types if the user >> requests it. >> >> So I don't think we can depend on server-side decryption to get us out >> of trouble in the general case. > The number of users who will opt into client-side encryption will be tiny, > and those cases we can handle with client-driven migration. I think you don't fully understand the role of the password in the current design. It does two things: 1. restricts access to your "recoverable" (class a) data - because you need to know that password to get a decryption key for the data 2. allows encryption of your "non-recoverable" (class b or class C if you choose a very long machine generated password) data - because a key is derived from it So the key reason I think communication is failing here is because by current design, the password is not option, nor is end to end client side encryption (for passwords). I think the conclusion to require end to end encryption for passwords is right. If you agree, then it seems like client managed upgrade is the way to go here, and I don't understand why that would be so hard. lloyd > Andreas >> >> Ryan >> _______________________________________________ >> Sync-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/sync-dev > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
