<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><ul><li>Can Sync encryption be re-engineered so that data survives a reset?</li><li>If yes, what UX changes would be required besides copy changes?</li></ul></div></div></blockquote><div><br></div><div>In theory, yes, in two ways.</div><div><br></div><div>To clarify: the issue with Sync is not that data is lost, it's that without kB it's inaccessible.</div><div><br></div><div>FxA exposes two encryption keys: kA and kB. kA is preserved across password resets. kB is not.</div><div><br></div><div>The obvious option is to use kA instead of kB. We decided not to do this for Sync 1.5, because it was a big change.</div><div><div><br class="">Simply using kA is probably not a good idea: IIRC it means Mozilla or an attacker would transparently have the ongoing ability to decrypt your data, no matter what you did. It cuts in some painful ways across the assumptions users have about passwords — that changing their password preserves their data, yes, but also that it will exclude an attacker in some way. That's only true in some respects if we used kA.</div><div><br></div><div>Using kA would be a relatively small change to each deployed Sync client, but it would be a breaking change, locking out older clients.</div></div><div><br></div><div>Another option is to build a key escrow service, similar to the one Apple hosts for FileVault encryption keys.</div><div><br></div><div>A key escrow service would instead wrap a copy of kB with additional crypto — print-and-save keys, a long series of questions:</div><div><br></div><div>
<div class="" title="Page 9">
<div class="">
</div>
</div><img src="cid:ii_is6kb6wl0_156b42ea5dbe6212" width="562" height="480"></div><div><br></div><div>This makes the process explicit, and doesn't touch core crypto; this is an addition with a hook into recovery.</div><div><br></div><div>FileVault is a great example: it's exactly the same as Sync. Crypto wrapping a pile of data that might or might not be valuable, might or might not be sensitive, and users care about a lot.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><ul><li>If it can’t be, is their consensus among users about which datatypes should be by default encrypted (e.g. passwords) and unencypted (e.g. bookmarks)?</li></ul></div></div></blockquote><div><br></div><div>There's risk here.</div><div><br></div><div>For instance, if I can write to your add-ons but not read your passwords, I can remotely execute code on your machine. If you're a doctor, your browsing history is likely HIPAA-sensitive. Your bookmarks might contain credentials.</div><div><br></div><div>Similarly, from a value perspective, some users don't care at all about saving passwords, but their history or bookmarks or form history is very important.</div><div><br></div><div>That it's difficult to say "this data is sensitive" or "this data is not" is one reason why we didn't use kA in the end.</div><div><br></div><div>I suspect it's impossible to make generalizations here…</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><ul><li>If there’s not consensus, would users prefer to choose what’s encrypted?</li></ul></div></div></blockquote><div><br></div><div>… and, furthermore, I think it's not a good choice for users to make potentially months or years before the decision affects them. Do you want safety or freedom? Both!</div><div><br></div><div>My personal feeling is that if we approach data recovery, we'll have the best chance of meeting varying user needs if we do it through FileVault-esque key escrow, not by using a more stable key.</div></div></div></div>