Keep a "History" section of things folks have interacted with

[mlissner]

A feature I use constantly on YouTube is the "History" page (don't judge me, this is a shared account):

I think something like this would be really useful to our users so they can find things they previously interacted with.

I think this makes a lot of sense and that we should put things into a new history page in the user's profile. It would include most of our stuff:

• Searches (we already save these)
• Case law (but only after somebody reads past 10%, say?)
• Oral arguments (but only after it's listened past 10%, say?)
• Dockets
  • Filings (these can get bundled within a docket in the UI, assuming multiple filings are viewed per docket)
• Judge profiles

Not included, I think:

• Financial disclosures (finding the judge is probably plenty good)

Features that we'd want to have included:

• A toggle to turn it off (also disables search history)
• Culling:
  • Bulk automatic deletion (default to 90 days?)
  • Bulk manual deletion (lets the user clear things older than X days, or in a date range)
  • Individual deletion (lets the user delete a given item)
• Search of the items by case or object name (just using postgres?)
• Filters by type of object, tags, etc, like in Wireframe for unified view of user tags, notes, prayers, etc. courtlistener#5220

[anseljh]

Can we avoid collecting history?

Can we put this data in browser local storage, and not collect this data ourselves? I assume there would be downsides like inconsistent history across devices, but that might be worth it for the privacy gain.

See Signal's privacy policy for inspiration:

Messages. Signal cannot decrypt or otherwise access the content of your messages or calls. Signal queues end-to-end encrypted messages on its servers for delivery to devices that are temporarily offline (e.g. a phone whose battery has died). Your message history is stored on your own devices.

Privacy policy update?

We should analyze whether a privacy policy change would be needed.

Opt-in instead of opt-out?

You suggested:

A toggle to turn it off (also disables search history)

Users may perceive this as a departure from previous privacy practices, so we should consider, perhaps do a user survey, whether current users should have this be an opt-in feature instead of turned on automatically for them. (If this data will be on our servers.) We should also check whether privacy laws require this approach.

[mlissner]

I was thinking a solution here might be to use the user's password/cookie to encrypt the values in our db. Might be hard to figure out, but I think that would leave us with nothing we can give and provide most of the usual functionality.

[mlissner]

Just did a bit of research. There are a lot of packages that allow you to encrypt based on a key you keep in memory, but none so far that work based on the user's info. I'm not sure how much this helps if we can still produce the values. Probably not much.

[mlissner]

Been thinking/poking around on this a bit this weekend.

On use cases

We need a list of all the possible features, so we can be sure our design works with them. Here's a start:

• List search history, ordered by date
• Group history into days
• Group docket entries viewed during a given day under their parent docket
• Delete an individual item from the history
• Delete a time span from the history
• Add new items to this history as the user browses

And on the encryption level, we need to:

• Be unable to access the data on demand.

  It's OK to have metadata about the visits, but we should not have information about what was visited.

• Be able to upgrade the encryption.

  As computers get faster, we need to upgrade our encryption algorithms. If the key is derived from the user's password, we'll only be able to do this when people log in. I think that's OK. It's how password encryption upgrades are handled.

  This needs to be performant even against thousands of encrypted items.

On encryption and threat modeling

1. Things like Signal have the requirement that the server never sees the content, even if hacked or compelled via the government. I don't think we need that level of security. We just need to be unable to access content on demand.

   This vastly simplifies the architecture, and allows us to have transient plaintext flowing through it rather than having to do key exchange and decryption on the client.

   Yes, this means it's possible that a gov't agency could make us capture flow logs, but I don't think that's our threat model.

2. I did some work with ChatGPT on this. It took some effort to get the prompt dialed into our threat model, but the conversation here is quite good:

   https://chatgpt.com/share/68e2a7b6-afe4-8013-8d40-6f25df6c769d

   The result of this conversation is a fairly straightforward system in which the data can only be decrypted by the user, and which uses a similar level of security to how we secure user's passwords.

   (Every website claims sysadmins can't access user's passwords, but it's not entirely true: Of course admins can, if they capture the password when the user logs in. This is a similar level of security: We can't access the data, except when the user logs in, their decryption key is generated, and we capture it.)

N.B. I've studied this stuff, but it's been a decade. We'll want to run this by somebody that knows this stuff better to make sure our threat model and approach are sound, but they seem reasonable to me so far.

Neat things

AWS Nitro is a system for providing secure enclaves in AWS. If we're serious about this, it's probably a good thing to consider using:

https://aws.amazon.com/ec2/nitro/nitro-enclaves/

Opt-in/out

Users may perceive this as a departure from previous privacy practices, so we should consider, perhaps do a user survey, whether current users should have this be an opt-in feature instead of turned on automatically for them. (If this data will be on our servers.) We should also check whether privacy laws require this approach.

Is there a middle ground where we opt people in, but give them a consent popup that says:

We just launched history tracking on CourtListener. From now on, the pages you engage with will be saved in encrypted format to your profile. This system uses encryption to keep your legal research private, even from government actors.

By default, we will store 180 days of history, but you can adjust this.

Then, we have some options. At the bottom of the notification we can say things like:

Learn More

Opt-Out

Adjust history length:

0-------|-------------------500   180 days

Etc.

[mlissner]

I chatted with an expert in this area today and put some notes into a document here, based on that conversation:

https://docs.google.com/document/d/1VWQyjXWB0GjeuBroR-6r9uXW0cFz2fm8H7d5L_zs7uI/edit?tab=t.p0nunhqjy3y3

I'm hoping he'll have time to look at this and plug in a few details that I left as call-outs.

[mlissner]

Our expert has chimed in, and we've got a threat model and an architecture for doing this in the Google Doc above. We can build when we're ready.

[mlissner]

Of note, Lexis does have this. Haven't checked West yet.