895518 - [meta] Support protocol and storage deprecation and upgrade indicators

Status: RESOLVED INCOMPLETE

(Firefox :: Sync, defect)

Description

[Richard Newman [:rnewman]]

We'll need to notify users of partitioning when they upgrade Sync to Sync.next.

16 months ago I started a discussion around this. Here's a fragment of my email.

---
* landing strings to report a protocol upgrade
* changing wording to be aware of two different setup processes for "Firefox Sync" and "Foxfire BIDSink", which will unfortunately have exactly the same name. (We can't assume that a user will have Firefox 16 on all of their devices.)
* implementing detection code by...
** extending or using the meta/global storage version logic to allow the new client to leave a 'marker' in the 1.1/v5 account;
** setting some other record in 'meta';
** annotating some client record field with a protocol version;
** allowing an account to be marked as obsolete post-upgrade, with a server response that Firefox 14 clients can use to detect their obsolescence.
---

Comment 1

[Richard Newman [:rnewman]]

I see multiple layers/releases here:

0. Some kind of rudimentary indicator that will at least do *something* for old clients.

1. Protocol response: this service/protocol is deprecated; visit this URL to find out more. Hard shutdown, dated.
  1.(b) An extension to the user API to tell the account to enter that state?

2. Storage handling: this storage system is not just a version ahead of you, the account has been superseded, and you need to explicitly opt in to continuing to use it (e.g., if you just downgraded). Visit this URL to find out more. This is likely to be a strict improvement over our current meta/global handling, which is to say "shucks" and sit on the curb, which screws up downgrading clients.

3. When we have a product/product marketing strategy and wording for exactly how we'll transition users between products, we can revise the interaction.
  3.(a) E.g., "You need to sign in with your Firefox Account to continue syncing. Click here."
  3.(b) Tailored for non-Mozilla servers...


Toby: input on (1), please.

Deb, input on the overall strategy, please.

Comment 2

[Richard Newman [:rnewman]]

Note that (0) is to figure out what we can do that existing clients can handle, if anything useful.

Note also that each stage requires a fair amount of QA. I can work with James on a testing plan for each as we progress.

Comment 3

[James Bonacci [:jbonacci]]

REMINDER for Deb, Tauni - 
we need to add this to our "user stories" Bugzilla dependency tree...

Comment 4

[James Bonacci [:jbonacci]]

+1 to Comment 2

Comment 5

[Toby Elliott [:telliott]]

There is an Upgrade Required (426) response. It's a bit of a stretch, and if purists get unhappy, we could use an arbitrary 500 code (513?).

We would only send this response to clients with a User-Agent known to support it - older clients would get a 503, and can document this. This will not work with any third-party client (since we won't know the User-Agent), though. Alternately, what would happen if we sent the current client a 426?

From an API perspective, adding an http response is a small violation that we'll document, but, given the minimal likely impact (due to lack of 3rd party candidates), I think it's an acceptable one.

Comment 6

[Richard Newman [:rnewman]]

To expand/clarify a little more:

A.
  1. This service is shutting down soon. Sent on success responses, triggers UI like "The old Firefox Sync service is shutting down soon. [Learn more]."

  2. This service is shutting down really soon. Sent as a failure response. Triggers UI like "The old Firefox Sync service is no longer available. To continue syncing you need to take action. [Learn more]."

B. Your account has been upgraded, and you're no longer syncing.
  3. … and you're on a pre-FxA device: "Your Firefox is no longer syncing. You might need to update your Firefox. [Learn more]."
  4. … and you're using a post-FxA device: "To continue syncing, [sign in with your Firefox Account]."


A is protocol-based; B is storage-based.

We can build 1-3 now.

Storage 'messages' will be added to meta/ to include reasons, the user's new FxA for pre-fill, new FxA server and service URLs, etc.

"Learn more" will explain why you got this message, what to do about it (upgrade, sign in with your Firefox Account), and what to do if you can't (Reset Sync-style operations to fix downgrade issues).

Comment 7

[Toby Elliott [:telliott]]

If we need multiple answers, we could arbitrarily define more 5xx codes. Alternately https://docs.services.mozilla.com/respcodes.html#respcodes specifies infrastructure-related codes (which are strings) that get returned with a 503, and adding to that would be relatively simple.

For #1, we'll need to define a header response that can be returned with a 200. That's pushing into the spec a little harder, but since it's just an informational message, I'm not worried about it.

Comment 8

[Toby Elliott [:telliott]]

For #1, I think the best answer would be a header:

Warning: 299 Sync "text goes here"

so the client just needs to look for a 299 code and then displays it. We can add strings if we want to mess with the language, or just point them to an html page with translations.

Comment 9

[Toby Elliott [:telliott]]

Another thing that occurred to me: could we use campaign manager for some of this?

Comment 10

[Richard Newman [:rnewman]]

(In reply to Toby Elliott [:telliott] from comment #9)
> Another thing that occurred to me: could we use campaign manager for some of
> this?

Not really:

* No control over whether a user sees a message if they have Sync set up.
* Android-only.

It would be nice to be able to proactively inform self-hosted users, but I don't think we can hit that target.

Comment 11

[Richard Newman [:rnewman]]

(In reply to Toby Elliott [:telliott] from comment #5)
> There is an Upgrade Required (426) response. It's a bit of a stretch, and if
> purists get unhappy, we could use an arbitrary 500 code (513?).

Agree that 426 doesn't fit. 500 and 503 don't either.

513 wfm, or even 404!

Comment 12

[Toby Elliott [:telliott]]

404 has previously established baggage, and will appear to clients as "go recheck your node then try again". I suppose we could then deassign them from a node with a 'null', but that would mean they recheck periodically, and probably fail without saying anything to the client. Hmmm.

I'm good with either. 513 probably gives us a little more flexibility without screwing with current behaviors.

Comment 13

[Ryan Kelly [:rfkelly]]

Hi Richard, AFAIK the work under this bug is as done as it's going to get.  Can you please confirm and close out the bug?  (Or just confirm and I'll do the legwork of closing things out)

Comment 14

[Richard Newman [:rnewman]]

Sadly so.