This meta bug covers providing some kind of parity with Sync 1.1's encryption mechanism -- that is, one that is entirely independent of credentials sent to the server. This is one of the pieces of feedback I've seen most often from a subset of technical, security-conscious users when they hear about the FxA-enabled rev of Sync (one blog post and a couple of users on IRC today alone). This should be no news to most of you. It's also, I contend, one of the blockers to a full GA release (along with self-hosting): even if we're confident in the security model of a password-derived encryption scheme -- as I'm sure we are, given that we're moving ahead with shipping it! -- we have a responsibility to offer a choice here that's at least in line with our competitors and our current offering, and the obvious consequence of ignoring that is a vocal response from the affected users. Given that this is a meta bug, we're not going to set tracking flags on it, but my assumption is that this is aiming at the 30/31 timeframe -- after we've addressed short-term needs, but before we plan to force existing Sync users to transition to new infrastructure. Note that I haven't proposed any concrete mechanism; it might be a pairing-based model, an optional Chrome-esque second password that's never typed into a web form, or something else altogether. I don't care what it is, only that we have a good answer for those users. Constructive discussion about options, target milestones, and work already done -- warner? ckarlof? -- most welcome. Really wild discussion please take to the mailing list!

Turns out this wasn't a blocker for GA release... Closing in favour of a similar bug that has more discussion in it.