We need a way to get people off old versions of the extension

[mlissner]

We released the 1.x series of the extensions a couple weeks ago, and already people are using old versions that they should really upgrade. This is a pain because we changed the API between 1.1.7 and 1.1.8 to split off docket history reports and docket reports and the old clients are still doing the "wrong" thing.

I don't know why these people didn't get the auto-upgrade (perhaps they have upgrades turned off?), but we need a way to urge them to do the right thing so we can move the API forward.

Chrome has an API that will tell you if an extension has an update: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/RequestUpdateCheckStatus

Buuuut....Firefox doesn't support this API and it's probably not as granular as we want. I just asked on the FF mailing list why this API isn't supported. I'll report back if I learn anything.

Short of that API working, I guess what we can do is ship something that checks CourtListener to see what the minimum supported version is. This means (presumably) that we'd need to then keep CourtListener up to date with what it's compatible with, but that's not an insane thing to do anyway.

The other question is, how do we want to urge these people to upgrade once they're using an unsupported version? I'd favor making this system pretty aggressive. It wouldn't mean that everybody has to immediately upgrade every time, but it would mean that when we make breaking changes to the API, they would.

When we changed the API and the extension identified that it wasn't supported, the icon could turn red and RECAP could stop making any network requests. When you click the red icon, you'd get an explanation of how to upgrade.

[mlissner]

FWIW, Firefox has no intention of supporting this API, and they say that having an API that you can check to see the minimum supported version is the common practice. We'll just have to figure out the right way to handle that, I suppose.

[johnhawkinson]

I disagree with the basic premise that forcing client-side upgrades is reasonable (because I'm a strong believer in user autonomy and in my experience user fear of upgrade problems is more than justified), but:

I think the way to accomplish this is to have the client send its version to the server when doing queries, and add a mechanism for the server to send a message in response to the client that is displayed to the user if it deems an upgrade is appropriate.

E.g. client uploads a docket, server accepts (or rejects) the docket and says "By the way, tell your user to upgrade."

[mlissner]

Yeah, that seems like a pretty logical approach. We could even make it a very basic field on the response, like a boolean called, client_upgrade_required. Shouldn't be too hard to do on the API side.

[johnhawkinson]

I would favor a free-form text message.

I'd much rather tell users their client will stop working on Jan. 18, 2018 than have them find out on Jan. 18 that it just doesn't work anymore.

[audiodude]

Wouldn't any mechanism for getting old clients to update only apply to versions in the future? We still have no way of getting 1.1.7 clients to upgrade, correct?

[mlissner]

Yep. The only stick I've come up with is to give them nasty URLs like this one instead of the links to PDFs that they expect:

https://free.law/recap/deprecated/?url=https://ia601505.us.archive.org/0/items/gov.uscourts.dcd.178502/gov.uscourts.dcd.178502.docket.html

That URL used to provide a click through in the warning so people could still get the item in the URL param, but I removed that recently too to make it as serious as possible.

On Wed, Jan 17, 2018 at 2:59 PM Travis Briggs notifications@github.com wrote:

Wouldn't any mechanism for getting old clients to update only apply to versions in the future? We still have no way of getting 1.1.7 clients to upgrade, correct?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/freelawproject/recap/issues/217#issuecomment-358478240, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOdql2gWKN0HPQbskFQdhEEyabnfMxrks5tLntKgaJpZM4QvXt0 .

-- Mike Lissner Executive Director Free Law Project @freelawproject https://free.law/donate/

[mlissner]

Hm, this hasn't proven to be much of a problem, and my thinking these days is that if people use old versions of our software, they can live with whatever breakage that brings. Just about everything is updated all the time now and I don't see us developing UX and APIs to cajole people on old broken versions to move forward. They can stick with old versions, and when those versions break, that'll cajole them.

[mlissner]

I'm opening this old issue because old versions of the extension are causing performance issues on the server. Therefore, it's time to do this work.

The way to do this will be:

1. Two new variables in CourtListener:

   • RECAP_EXTENSION_MIN_VERSION will say the lowest version of the extension that is supported at all. Versions lower than this will no longer work.
   • RECAP_EXTENSION_DEP_WARNING_VERSION will say the highest version that works without a warning. Versions lower than this but higher than RECAP_EXTENSION_MIN_VERSION will get a warning.

   This leads to the following imaginary breakdown:

   RECAP_EXTENSION_MIN_VERSION = `1.0.0`
   RECAP_EXTENSION_DEP_WARNING_VERSION = `1.1.0`
   if version < RECAP_EXTENSION_MIN_VERSION:
       block_usage()
   elif RECAP_EXTENSION_MIN_VERSION < version < RECAP_EXTENSION_DEP_WARNING:
       warn_user()
   else:
       work_normally()

   Note that we'll need a version parsing library of some kind (maybe we already have one?).

2. The extension will start sending the version to the server with every API request. This can be done as a header or parameter, whatever makes the most sense.

3. CourtListener's document pages get two new GET parameters:

   • If recap_deprecation_warning=true is on the URL, we pop up a modal telling the person that their version of RECAP is deprecated, and encouraging them to upgrade. The modal has a button "Upgrade now" that leads to free.law/recap/, and it has a × button so they can close the modal and get their doc.
   • If recap_deprecated=true is on the URL, we pop up the same modal with slightly different text telling the user to upgrade now. The modal no longer has an X to dismiss it and if it's not too much work, clicking to the side of the modal and the esc key shouldn't close it either. We're now playing hardball. For the user to proceed, they need to either tweak the URL to remove the parameter, or upgrade, darn it.

4. The API gets tweaked so that when the extension asks for a document, it no longer returns URLs to storage.courtlistener.com. Now it returns URLs to the RECAP document page on CL, and those pages have either the recap_deprecation_warning or the recap_deprecated parameter in the URL.

The net of these changes is that documents are less useful and kind of annoying in old versions of RECAP, and are useless in deprecated versions. The former is irritating and the latter is enough to make you either upgrade or uninstall. At that point, either is fine with us. The goal of fully deprecating a version of RECAP is to allow us to move forward when we need to.

[mlissner]

One other thought: What about the folks that aren't sending their extension version with each request? I guess we could do a version of the API now that just gives them the warning modal, and do another version in a few weeks that locks them out, but I'm not sure there's a point. It's not like people need time to migrate. They just need to upgrade.

Also: we can't distinguish between all the old versions people are using, and some have real problems like creating jumbled cases and hitting our DB too hard.

I think that means if the version isn't sent with a request, the response is to block, tweaking our earlier aglo to something like:

RECAP_EXTENSION_MIN_VERSION = `1.0.0`
RECAP_EXTENSION_DEP_WARNING_VERSION = `1.1.0`
if version is None or version < RECAP_EXTENSION_MIN_VERSION:
    block_usage()
elif RECAP_EXTENSION_MIN_VERSION < version < RECAP_EXTENSION_DEP_WARNING:
    warn_user()
else:
    work_normally()

And, sorry, one more thing. We will need to roll this out with some buffer time. First we upgrade the extension to start sending the version number. Then we wait a week for people to upgrade. Finally, we roll out the API upgrade. If we don't do this, we'll start blocking everybody that has the n - 1 version of the extension (i.e. the current version) until their browser upgrades them, and that would be bad.

[audiodude]

Googler here. You might be aware that Chrome extensions are forcing a Manifest v3 upgrade soon. As part of that, I got a notification for a company internal extension I worked on. They suggested that if the extension is no longer used, you should delete it. But how do you delete an extension if it's already installed on everyone's computer? Apparently there's a way to get an extension to uninstall itself. So if you want to nuke all versions of the extension before 1.X.Y, you can release 1.X.Y+1 that nukes itself, and then the user will have to manually install 1.X.Y+2.

Just a thought. Obviously if people have auto updates on and they're getting new versions automatically, this wouldn't be necessary. And if they don't have auto updates on it wouldn't work. So I guess I'm not sure how useful this is but just wanted to add some information.

[mlissner]

Thanks Travis. I'm not sure how we'll put that into action, but it's interesting. I'm surprised browsers don't have a way of yanking a version of an extension, but as far as I can tell, they don't, at least not that's publicly findable.