Closed Bug 727832 Opened 13 years ago Closed 12 years ago

No mention of recovery key in setup process leads to problems

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: verdi, Unassigned)

References

()

Details

In Firefox 10 we don't even mention the existence of a recovery key in the setup process. So a user, rightfully, won't look for one. Then when doing something like reformatting their hard drive they loose their sync data not because of their failure to save a copy of their recovery key but because we never told them that there was such a thing that they should save. Here's the issue in action: https://support.mozilla.org/en-US/questions/919557
Long and thorny issue continues to raise its ugly head. The root cause of all this, as we're all well aware, is that some users read "Firefox Sync" as "Firefox Backup" or "Firefox Dropbox", but neither the system nor the UI are designed for that. I think that our rename of Sync Key to Recovery Key is no longer accurate: what's the sense in a Recovery Key that you aren't told about, and in any case won't necessarily be enough to recover your data in an emergency? We renamed it when it still appeared in the wizard, and we told you to keep it in a safe place, and thus the name meant something. I still think that showing the Sync Key during setup is not a net win: research suggests that this scares and confuses users without resulting in any of them writing the damn thing down. (And, to belabor the point, even if they write it down we don't guarantee the durability or completeness of their data.) I *do* think it's worthwhile pretending that every screen says "Firefox Backup", and designing accordingly. An info box on one of the setup screens that says "just so you know, writing down your username and password isn't enough to recover your data. Here's a link to how to back up your Firefox profile". There's also the next stage of our UI redesign, which is to make it difficult to create an account without first pairing two devices (and thus having another device that has your credentials). The goal is to eliminate the single-device user base, because they clearly have expectations that we don't meet. Sync setup should *start* with pairing two devices, and result in either credentials exchange or an account being created. This user should not have been able to set up Sync on just this one machine. Addressing either or both of these should make it less likely for uneducated users (the kind who will place absolute trust in the integrity of their data in a feature that they don't understand) to take permanent destructive actions. But in the mean time, cases like this are just a consequence of having a setup UI that isn't user-hostile in other ways.
(In reply to Richard Newman [:rnewman] from comment #1) > Long and thorny issue continues to raise its ugly head. > > The root cause of all this, as we're all well aware, is that some users read > "Firefox Sync" as "Firefox Backup" or "Firefox Dropbox", but neither the > system nor the UI are designed for that. > I don't believe for a moment that this is the user's fault and we must stop saying that. If we continue that line of reasoning this problem will never be fixed. If you read about sync here: http://www.mozilla.org/en-US/mobile/sync/ or in Firefox, at no point do we mention that this isn't a backup or try to distinguish sync from backup. In fact, we say things like, "Your data is always protected" and "Seamlessly sync your Firefoxes." That can easily interpreted as we will hold your data and you can get it from anywhere. And even in this particular case you could argue that the user is using the service they way it was intended. He's trying to sync Firefox #1 (where he set up his account) with Firefox #2 (on the Firefox he installed on his new system) but because these happen to be the same computer after a HD wipe we penalize him. If this was the same computer but two different profiles or user accounts it wouldn't be an issue. And to add insult to injury we didn't explain the rules to begin with. Maybe this bug should be renamed to "The entire Sync feature, from setup to daily operation, does not afford the user an opportunity to learn how the service works or is intended to be used."
Richard I apologize for shooting the messenger. I appreciate that as you say "the system and the UI are not designed" for backup. My frustration is that we keep pushing this feature without explaining the limitation clearly and it puts us all in terrible positions with users.
(In reply to Richard Newman [:rnewman] from comment #1) > There's also the next stage of our UI redesign, which is to make it > difficult to create an account without first pairing two devices (and thus > having another device that has your credentials). Me likes! Don't start the syncing service 'til 2 devices are linked to the account. Single device state could be periodic pings to see if another device has been connected. In any case, a clear statement of what Sync does; data pruning included.
(In reply to Verdi from comment #3) > Richard I apologize for shooting the messenger. I appreciate that as you say > "the system and the UI are not designed" for backup. My frustration is that > we keep pushing this feature without explaining the limitation clearly and > it puts us all in terrible positions with users. Yup, quite agreed. Regardless of whether users are "right" to have their expectation (which evidence suggests is "my data lives in the cloud"), nobody is well served by failing to address it -- either by offering robust, versioned, recoverable backups, or by explicitly designing to set expectations. We do neither; for a bunch of reasons we haven't pivoted from the Weave mission, nor have we completely restructured the idea of signup, but we've also been very shy about making Sync setup any more hostile… and UX certainly views warnings, disclaimers, and additional information as hostile. Rock and a hard place :/
> Me likes! Don't start the syncing service 'til 2 devices are linked to the > account. Single device state could be periodic pings to see if another > device has been connected. Even further than that: *begin* the flow with Pair A Device, and don't even create an account until you have two devices talking. We support this from Fx10 onwards (click Pair on about:home), but the wizard still has a "Create an Account" button. That needs to go.
*nods* But we would need start up flow for those connecting far apart devices. We'd also have to consider how to deal with unlinking a device. But I like this thinking of requiring accounts to have connected devices to make the Sync Service function. Unless 2 or more devices are connected, Sync should not be active. No more single device (backup) support.
I'm sure you all have discussed this but why not make it a backup service (especially if from a user's perspective it sure seems like a backup service)?
(In reply to Verdi from comment #8) > I'm sure you all have discussed this but why not make it a backup service > (especially if from a user's perspective it sure seems like a backup > service)? Just making the leap to durability is expensive. But backups should also be versioned, dated, explorable, restorable, etc. Building a backup service not just a durable Sync service... tough. Sync is designed to be a secure whiteboard, and the client, protocol, and server would need a lot of work to make that happen. Again, it all comes down to meeting user expectations.
Verdi, Many of us have deeply desired to do what you ask, but it is a monumental, multiteam, and possibly multiyear task. (but we're working on it!) You may get many of your wishes in the coming months, but they far exceed the scope of one bug. I took mention of the key out in firefox 10 ui-overhaul project, at product & UX & UR behest. If you wish to talk about it, I would be happy to discuss. Please find me via irc, irl, or email. sync triage: bug is not worthwhile to upcoming persona-based auth & sync 2.0
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.