1003473 - [meta] Support protocol signaling to indicate remote account deletion in expiry scenarios

Status: RESOLVED WORKSFORME

(Firefox :: Sync, defect)

Description

[Toby Elliott [:telliott]]

There's a stack of users who used sync in the early days on a single client, and then abandoned it. If they reenable sync now, it's going to default over to old-sync and that's not the best experience.

We'd like to start purging those folks (say, inactive for 3 months and single client) so that their experience with 29 is better. We could certainly return different codes for incorrect login/no account. If a user gets the latter code, it prompts the user to set up new sync.

Something we could sneak into an upcoming build?

Comment 1

[Richard Newman [:rnewman]]

To clarify: this set of users must have

* Set up Sync in Firefox
* Stopped using Firefox for a long time, such that their account was deleted on the server
* Started Firefox 29 without Reset Firefox discarding their Sync credentials (does it?)

These people will also have a bad experience if they aren't using 29, so there's an implicit assumption that they're starting to use Firefox again because of 29.


The risk here is that we'll delete a user's sync account and they won't set up a new one, or they'll say "I could have sworn I set up Sync; man, Firefox must really suck".

See also Bug 999198.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

How many users have we deleted, and how many do we think we can delete?

Comment 3

[Toby Elliott [:telliott]]

To be clear, we have not deleted anyone yet. We are proposing that we should accelerate efforts to get people who are clearly not benefiting from current sync over to 1.5. A subset of users for whom this would  seem to be the case is long-unchanging users who had a single client.

Deletion is merely one way of getting the users over, and possibly the simplest. I'm open to other ways to get these people (and, agreed, the vast, vast majority will not be setting up a new one) migrated.

I don't have exact numbers of users this would apply to, but it's large, probably over a million. Clearing their data would be a nice side benefit.

Oooh, I just had a thought. We could migrate all those users over to a specific nodename and put something in the client that recognized that nodename as a signal to prompt a user to upgrade to 1.5. We'd have that old node exist, so a user who did trigger this in <29 would still work correctly.

Comment 4

[Ryan Kelly [:rfkelly]]

It feels like there's something good here, but I'm not clear on what the client flow would look like.  What does "and then abandoned it" entail in this case - they set up sync, decided to abandon it and/or firefox entirely for a while, and are now coming back to switch sync back on in their existing, previously-sync-enabled profile?

If they explicitly abandoned sync (e.g. via "disconnect this device") but have otherwise continued using firefox, will re-enabling sync trigger the old-sync or new-sync setup flow?  It's my understanding that there's no way to trigger the old-sync setup flow in FF29, but I could easily be mistaken.

> If they reenable sync now, it's going to default over to old-sync and that's
> not the best experience.

I agree this is suboptimal, but what precisely are we worried about here?

If it defaults over to old-sync and then just keeps working like it did before, that doesn't seem so bad to me.  They're not getting the new shiny but sync will appear to work.  We'll catch them we when do the more general "encourage single-device old-sync users to migrate" step.

Or will they end up in some sort of broken state where they can't sync or are terribly confused about whether they're syncing?

> Oooh, I just had a thought. We could migrate all those users over to a specific nodename
> and put something in the client that recognized that nodename as a signal to prompt a user
> to upgrade to 1.5.

Heh:  "if (clusterURL == 'https://purgatory.sync.services.mozilla.com') { alert('create a firefox account!') }"


> We'd have that old node exist, so a user who did trigger this in <29 would still work correctly.

If we wanted to get clever, we could make this node be a bit special.  Rather than serving data itself, if it receives a sync request, it could interally trigger a migration of that user back to a regular old sync1.1 storage node.  So users get automatically bounced out of this state if they actually sync something.

Comment 5

[Toby Elliott [:telliott]]

(In reply to Ryan Kelly [:rfkelly] from comment #4)
> I agree this is suboptimal, but what precisely are we worried about here?

"Hey, I see FF has finally fixed their sync problems. I should check out FF29"

If you have an account on the old system, actually getting to 1.5 is not a simple process.

Comment 6

[James Bonacci [:jbonacci]]

No, it is not, especially for users with 1+ desktop and 1+ Android... as we have discovered again this morning in #fxa.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to Toby Elliott [:telliott] from comment #5)
> (In reply to Ryan Kelly [:rfkelly] from comment #4)
> > I agree this is suboptimal, but what precisely are we worried about here?
> 
> "Hey, I see FF has finally fixed their sync problems. I should check out
> FF29"
> 
> If you have an account on the old system, actually getting to 1.5 is not a
> simple process.

This is a problem we're going to address separately by designing an "upgrade" process that moves all users to 1.5. Seems like we should just do that, without this extra intermediate step.

Comment 8

[Julie McCracken (:julie)]

Did a formal migration a couple years ago.