Detect sealed docs via docket entry description

[mlissner]

There's no easy way I know of to prevent sealed docs from occasionally getting uploaded into RECAP, but one thing we can do is look for the word "sealed" in document descriptions and avoid uploading such documents automatically. For example, we could provide an opt in that pops up for such documents, or simply show an error saying we can't upload the document because we detected it was sealed.

To the extent documents are labeled as sealed, which definitely happens some of the time, this would help.

[johnhawkinson]

I think there are many docket text entries that contain the word "sealed" that are not and should not be sealed. In fact, those that contain the word "sealed" are probably more likely to be properly not sealed than they are sealed (properly or improperly restricted). Another common case is when they are initially sealed and later unsealed.

So I would be wary of this, and strongly opposed to an error in such cases.

Do you have an example, perhaps with the names changed to protect the innocent?

[mlissner]

Nice use of the rare thumbsdown emoji.

Here's an example that came up today: https://www.courtlistener.com/docket/6863381/158/ohio-a-philip-randolph-institute-v-kasich/

That got uploaded into RECAP by somebody that had access even though it was sealed.

I think hitting false positives here could be OK, if it, for example, popped up a warning before doing an upload:

"This item has the word 'sealed' in its description. Are you sure you want to upload it?"

Something like that.

[johnhawkinson]

That got uploaded into RECAP by somebody that had access even though it was sealed.

How does that happen at all? Did they get an interstitial clickthrough and have the extension upload it anyhow? One of these deals?:

If so, then the proper behavior is for the extension to heed that. I have code that does this in my branch that deals with free looks, though it could easily be brought into the mainline.

Otherwise, I'd like to better understand what's going on. Also, don't people read the warnings about RECAP and sealed documents?

In your link, you have "This item is Sealed." What is that supposed to mean? Remember, docket text can be sealed, documents can be sealed, or both. The text should be clear about what is meant (or a mouseover), and it is not now. Hopefully the data model is clear?

[johnhawkinson]

Also, a somewhat different case is *SEALED* as opposed to SEALED. I'm still not sure it's a good idea to trigger on, but seems safer. In my data corpus, it only appears in a historical NEF displayed after a sealed case was unsealed.

[mlissner]

the proper behavior is for the extension to heed that.

OK, that's even better. I've never seen that HTML before, so yeah, much better to use that.

Remember, docket text can be sealed, documents can be sealed, or both. The text should be clear about what is meant (or a mouseover), and it is not now. Hopefully the data model is clear?

The data model allows documents to be sealed at this point. When it comes to docket entries, we haven't had any issues about those yet. Dockets occasionally are sealed, but we've never gotten one of those, so it kind of works out.

Suppose a mouseover or something could be used here to do better.

a somewhat different case is SEALED as opposed to SEALED

Good point. Sounds like if we can use the above warning though, this kind of sniffing won't be needed — Good.

[mlissner]

Here's a (pixelated, alas) screenshot the user sent me (names blurred):

I'm working on getting the HTML if they can figure it out (they're not a coder from what I can tell).

[johnhawkinson]

Well, OK, that's pretty clear. The short answer is yes, they got a warning box. Great.

[johnhawkinson]

My current code takes a belt-and-suspenders approach, triggering on any of:

• Warning! text in the first <td> of a table.
• /document is restricted/ in any boldface text in the document.

So in keeping with that belt-and-suspenders approach, we should add

• /SEALED/
• /do not allow it to be seen/ to the strings in boldface that trigger do-not-upload.

I'll try to pull this out of my branch late tonight.

[mlissner]

Fantastic! Looks like no HTML for us (they're uncomfortable; fair enough), but sounds like the above should work nicely regardless.

[johnhawkinson]

So, what exactly should the extension do in this case? My current code does

  if (restrictedDoc) {
    alert("Restricted document detected. Skipping RECAP upload.");
    // xxx can't call chrome.browserAction.setIcon() here. Need to
    // send a message to the background script? ughhhh. xxx
  }

...

        if (this.restricted) {
          alert("Yeah we did the check before uploadpdf.");
        }

That's fine for development but probably not correct for production code.

One answer is to just be silent.

Another is to modify the page to add an element making it clear that RECAP is not going to upload the document.

Another is to modify the icon; though my comments suggest that's harder.

[mlissner]

Easiest is just to log to console. It'd be nice to show the disabled icon though, with a mouseover on it explaining why RECAP is currently disabled.

So I guess it's about friction. If we just log to console that'd be a meaningful improvement worth landing in my opinion. If doing icon junk too makes life difficult, then let's not let that stop this improvement.

[johnhawkinson]

Why would we not mark up the page?

[mlissner]

Could do so, but it's not usually our practice to say what we're not doing. I could also see people seeing such a marker and having it make them more concerned than if there was nothing at all. I'm ±1 on it, though it also seemed like more work to get it right.

[johnhawkinson]

I think it's very important to let people know that RECAP is not taking action, and page-visible markup may be the best way. Certainly it's better than a modal pop-up or a console log message, and very likely better than changing the icon alone.

Also, because the past behavior of the extension was to do this horrible thing that should never ever ever ever happen, what the AOUSC and others have been warning about for years, we need to be extra extra clear that it is not happening and that the extension's behavior has changed. A simple note in the README or page load upon upgrade is not sufficient. It needs to be visible to users who are affected.

Perhaps there is a PR issue to raise here, too. It's ironic that after all the angsting about this is #232, and whether or not to do free looks because of this potential pitfall, it turns out the pitfall was with us all along.

[mlissner]

I think it's very important to let people know that RECAP is not taking action, and page-visible markup may be the best way. Certainly it's better than a modal pop-up or a console log message, and very likely better than changing the icon alone.

Great. +1 in that case.

Also, because the past behavior of the extension was to do this horrible thing that should never ever ever ever happen, what the AOUSC and others have been warning about for years, we need to be extra extra clear that it is not happening and that the extension's behavior has changed. A simple note in the README or page load upon upgrade is not sufficient. It needs to be visible to users who are affected.

What do you have in mind here?