Add UI for setting the encryption passphrase....

Add UI for setting the encryption passphrase.

-Tabbed version of configure page which offers both data type selection and passphrase selection
-New passphrase page which doubles for creation and entry.
-New common loading page which contains the spinny.
-Backend changes.

BUG=48706
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=62249

[tim (not reviewing), 2010-10-11 18:24:09]

http://codereview.chromium.org/3655004/diff/19001/20001
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/3655004/diff/19001/20001#newcode7812
chrome/app/generated_resources.grd:7812: <ph
name="PRODUCT_NAME">$1<ex>Chrome</ex></ph> always encrypts your data when it's
tramsmitted to Google.  Additionally, passwords and credit card details are
stored encrypted on Google servers.
we don't sync credit cards, so we shouldn't mention it here.

http://codereview.chromium.org/3655004/diff/19001/20004
File chrome/browser/sync/profile_sync_service.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20004#newcode938
chrome/browser/sync/profile_sync_service.cc:938:
UpdateAuthErrorState(GoogleServiceAuthError(
do we really want to do this UpdateAuthErrorState in all cases?  It doesn't seem
like a true error if we just have to unlock?

http://codereview.chromium.org/3655004/diff/19001/20011
File chrome/browser/sync/sync_setup_flow.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20011#newcode640
chrome/browser/sync/sync_setup_flow.cc:640: // TODO(johnnyg): else clear the
passphrase and revert to password
We discussed offline just disabling unchecking this checkbox, and adding a
warning that once you've selected a secondary passphrase, your only recourse to
'go back' to gaia is to clear your data and start again.

We could optimize by coming up with a way to step-back to GAIA_LOGIN, collect
the password, verify it as usual, and then (and only then) unset the sec.
passphrase preference, and generate a key based off of the gaia password.  I'm
not sure how easy that will be or if we will run into other problems.  I think
we can live with the first approach for today.

http://codereview.chromium.org/3655004/diff/19001/20012
File chrome/browser/sync/sync_setup_flow.h (right):

http://codereview.chromium.org/3655004/diff/19001/20012#newcode25
chrome/browser/sync/sync_setup_flow.h:25: struct SyncConfiguration {
struct comment would be helpful.

http://codereview.chromium.org/3655004/diff/19001/20012#newcode28
chrome/browser/sync/sync_setup_flow.h:28: bool encrypt_everything;
this isn't used anywhere.

[John Gregg, 2010-10-11 21:03:39]

http://codereview.chromium.org/3655004/diff/19001/20001
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/3655004/diff/19001/20001#newcode7812
chrome/app/generated_resources.grd:7812: <ph
name="PRODUCT_NAME">$1<ex>Chrome</ex></ph> always encrypts your data when it's
tramsmitted to Google.  Additionally, passwords and credit card details are
stored encrypted on Google servers.
On 2010/10/11 18:24:09, timsteele wrote:
> we don't sync credit cards, so we shouldn't mention it here.

Done.

http://codereview.chromium.org/3655004/diff/19001/20004
File chrome/browser/sync/profile_sync_service.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20004#newcode938
chrome/browser/sync/profile_sync_service.cc:938:
UpdateAuthErrorState(GoogleServiceAuthError(
On 2010/10/11 18:24:09, timsteele wrote:
> do we really want to do this UpdateAuthErrorState in all cases?  It doesn't
seem
> like a true error if we just have to unlock?

if the user doesn't follow through on the wizard don't we want to be able to
show some persistent UI indicating a problem.  We could create a different
error, but it doesn't really fit into the GoogleServiceAuthError model.

How about I only set the error if the wizard is not visible (as we discussed
this would be a rare case).  Any other suggestions?

http://codereview.chromium.org/3655004/diff/19001/20011
File chrome/browser/sync/sync_setup_flow.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20011#newcode640
chrome/browser/sync/sync_setup_flow.cc:640: // TODO(johnnyg): else clear the
passphrase and revert to password
On 2010/10/11 18:24:09, timsteele wrote:
> We discussed offline just disabling unchecking this checkbox, and adding a
> warning that once you've selected a secondary passphrase, your only recourse
to
> 'go back' to gaia is to clear your data and start again.
> 
> We could optimize by coming up with a way to step-back to GAIA_LOGIN, collect
> the password, verify it as usual, and then (and only then) unset the sec.
> passphrase preference, and generate a key based off of the gaia password.  I'm
> not sure how easy that will be or if we will run into other problems.  I think
> we can live with the first approach for today.

I'm disabling the box.

http://codereview.chromium.org/3655004/diff/19001/20012
File chrome/browser/sync/sync_setup_flow.h (right):

http://codereview.chromium.org/3655004/diff/19001/20012#newcode25
chrome/browser/sync/sync_setup_flow.h:25: struct SyncConfiguration {
On 2010/10/11 18:24:09, timsteele wrote:
> struct comment would be helpful.

Done.

http://codereview.chromium.org/3655004/diff/19001/20012#newcode28
chrome/browser/sync/sync_setup_flow.h:28: bool encrypt_everything;
On 2010/10/11 18:24:09, timsteele wrote:
> this isn't used anywhere.

Done.

[tim (not reviewing), 2010-10-11 21:06:46]

http://codereview.chromium.org/3655004/diff/19001/20013
File chrome/browser/sync/sync_setup_wizard.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20013#newcode156
chrome/browser/sync/sync_setup_wizard.cc:156: AddString(dict,
"enterPassphraseTitle", IDS_SYNC_ENTER_PASSPHRASE_TITLE);
shouldn't part of these be conditional on whether we're using the secondary
passphrase or not? (So we show the 'Google password' version instead?)

[tim (not reviewing), 2010-10-11 21:08:14]

http://codereview.chromium.org/3655004/diff/19001/20004
File chrome/browser/sync/profile_sync_service.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20004#newcode938
chrome/browser/sync/profile_sync_service.cc:938:
UpdateAuthErrorState(GoogleServiceAuthError(
On 2010/10/11 21:03:39, John Gregg wrote:
> On 2010/10/11 18:24:09, timsteele wrote:
> > do we really want to do this UpdateAuthErrorState in all cases?  It doesn't
> seem
> > like a true error if we just have to unlock?
> 
> if the user doesn't follow through on the wizard don't we want to be able to
> show some persistent UI indicating a problem.  We could create a different
> error, but it doesn't really fit into the GoogleServiceAuthError model.
> 
> How about I only set the error if the wizard is not visible (as we discussed
> this would be a rare case).  Any other suggestions?

OK; but use SetupInProgress vs WizardIsVisible for the condition.

[John Gregg, 2010-10-11 23:38:53]

http://codereview.chromium.org/3655004/diff/19001/20004
File chrome/browser/sync/profile_sync_service.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20004#newcode938
chrome/browser/sync/profile_sync_service.cc:938:
UpdateAuthErrorState(GoogleServiceAuthError(
On 2010/10/11 21:08:14, timsteele wrote:
> On 2010/10/11 21:03:39, John Gregg wrote:
> > On 2010/10/11 18:24:09, timsteele wrote:
> > > do we really want to do this UpdateAuthErrorState in all cases?  It
doesn't
> > seem
> > > like a true error if we just have to unlock?
> > 
> > if the user doesn't follow through on the wizard don't we want to be able to
> > show some persistent UI indicating a problem.  We could create a different
> > error, but it doesn't really fit into the GoogleServiceAuthError model.
> > 
> > How about I only set the error if the wizard is not visible (as we discussed
> > this would be a rare case).  Any other suggestions?
> 
> OK; but use SetupInProgress vs WizardIsVisible for the condition.

Done.

http://codereview.chromium.org/3655004/diff/19001/20013
File chrome/browser/sync/sync_setup_wizard.cc (right):

http://codereview.chromium.org/3655004/diff/19001/20013#newcode156
chrome/browser/sync/sync_setup_wizard.cc:156: AddString(dict,
"enterPassphraseTitle", IDS_SYNC_ENTER_PASSPHRASE_TITLE);
On 2010/10/11 21:06:47, timsteele wrote:
> shouldn't part of these be conditional on whether we're using the secondary
> passphrase or not? (So we show the 'Google password' version instead?)

Done.

[tim (not reviewing), 2010-10-11 23:44:20]

On 2010/10/11 23:38:53, John Gregg wrote:
> http://codereview.chromium.org/3655004/diff/19001/20004
> File chrome/browser/sync/profile_sync_service.cc (right):
> 
> http://codereview.chromium.org/3655004/diff/19001/20004#newcode938
> chrome/browser/sync/profile_sync_service.cc:938:
> UpdateAuthErrorState(GoogleServiceAuthError(
> On 2010/10/11 21:08:14, timsteele wrote:
> > On 2010/10/11 21:03:39, John Gregg wrote:
> > > On 2010/10/11 18:24:09, timsteele wrote:
> > > > do we really want to do this UpdateAuthErrorState in all cases?  It
> doesn't
> > > seem
> > > > like a true error if we just have to unlock?
> > > 
> > > if the user doesn't follow through on the wizard don't we want to be able
to
> > > show some persistent UI indicating a problem.  We could create a different
> > > error, but it doesn't really fit into the GoogleServiceAuthError model.
> > > 
> > > How about I only set the error if the wizard is not visible (as we
discussed
> > > this would be a rare case).  Any other suggestions?
> > 
> > OK; but use SetupInProgress vs WizardIsVisible for the condition.
> 
> Done.
> 
> http://codereview.chromium.org/3655004/diff/19001/20013
> File chrome/browser/sync/sync_setup_wizard.cc (right):
> 
> http://codereview.chromium.org/3655004/diff/19001/20013#newcode156
> chrome/browser/sync/sync_setup_wizard.cc:156: AddString(dict,
> "enterPassphraseTitle", IDS_SYNC_ENTER_PASSPHRASE_TITLE);
> On 2010/10/11 21:06:47, timsteele wrote:
> > shouldn't part of these be conditional on whether we're using the secondary
> > passphrase or not? (So we show the 'Google password' version instead?)
> 
> Done.

LGTM