Why does OpenAI collect and retain for 30 days^1 chats that the user wants to be deleted

It was doing this prior to being sued by the NYT and many others

OpenAI was collecting chats even when the user asked for deletion, i.e., the user did not want them saved

That's why a lawsuit could require OpenAi to issue a hold order, retain these chats for longer and produce them to another party in discovery

If OpenAI was not collecting these chats in the ordinary course of its business before being sued by the NYT and many others, then there would be no "deleted chats" for OpenAI to be compelled by court order to retain and produce to the plaintiffs

1. Or whatever period OpenAI decides on. It could change at any time for any reason. However OpenAI cannot change their retention policy to some shortened period after being sued. Google tried this a few years ago. It began destroying chats between employees after Google was on notice it was going to be sued by the US government and state AGs

The two documents you linked are responses to specific parts of OpenAI's objection. They're not good sources for the original order.

Nevertheless, you're generally correct but you don't realize why: A core feature of ChatGPT is that it keeps your conversation history right there so you can click on it, review it, and continue conversations across all of your devices. The court order is to preserve what is already present in the system even if the user asks to delete it.

For those who are confused: A core feature of ChatGPT and other LLM accounts is that your past conversations are available to return to, until you specifically delete them. The problem now is that if a user asks for the conversation to be deleted, OpenAI has to retain the conversation for the court order even though it appears deleted.

They could have been stored at the client, and encrypted before optionally synced back to OpenAI servers in a way that the stored chats can only be read back by the user. Signal illustrates how this is possible.

OpenAI made a choice in how the feature was and is implemented.

This is true but why retain deleted conversations?

This article says nothing of the sort. The court order is to preserve existing logs they already have, not to disable logging, and hand all the logs over the plaintiffs. OpenAI's objections are mainly that 1/there are too many logs (so they're proposing a sample instead) and that 2/there's identifying data in the logs and so they are being "forced" to anonymize the logs at their expense (even though it's what they want as a condition of transferring the logs).

There is nothing in the article that mentions OpenAI being forced to create new logs they don't already have.

This is an excellent article and source. Thank you.

I read in the pleadings that OpenAI claims it cannot search its logs without decompressing them first

I can search the logs I keep without decompressing

Every user is different and each is free to use whatever software they want

Using RePair for compression I can also search inside compressed tarballs full of logs

To do this, I first insert a blank line at the top of each log file before adding to the tarball

IME, RePair is faster than compressing with zstd and the size reduction is almost the same

The only "catch" is that RePair requires more memory during compression

"Have you used ChatGPT?"

No

Large number of upvotes on the quoted comment however. Maybe some of those voters are ChatGPT users

I do searching from the command line in text mode. The script I use keeps a "log" (a customised SERP) of all query strings and search result URLs. I also have these URLs stored in the logs from the forward proxy. These are compressed using RePair. I can search the compressed logs faster this way than with something like

    ztsd -dc log.zst|grep pattern

    rg -z pattern log.zst

They made the feature, now they get to live with it. So they can spare us the feigned surprise and outrage.

Instead of writing open letters they could of course do something about it. Even Google stopped storing your location timeline on their servers and now have it per-device only.

Presumably for cross-device interactivity. If I interact with ChatGPT on my phone, then open it on my desktop. I might be a bit frustrated that I can't get to the chat I was having on my phone previously.

OpenAI could store the chat conversation in an encrypted format that only you, the user, can decrypt, with the client-side determining the amount of previous messages to include for additional context, but there's plenty of user overhead involved in an undertaking like that (likely a separate decryption password would be needed to ensure full user-exclusive access, etc).

I'd appreciate and use a feature like that, but I doubt most "average" users would care.

> Is there a technical limitation that prevents chat histories from being stored locally on the user's computer

People access ChatGPT through different interfaces: Web, desktop app, their phones, tablets.

Therefore the conversations are stored on the servers. It's really not some hidden plot against users to steal their data. It's just how most users expect their apps to work.

If I am sending HTTP POST requests using own choice of software via the command line to some website, e.g., an OpenAI server, then I can save those requests on local storage. I can keep a record of what I have done. This history does not need to be saved by OpenAI and consequently end up being included in a document production when (not if) OpenAI is sued. But I cannot control what OpenAI does, that's their decision

For example, I save all the POST request bodies I send over the internet in the local forward proxy's log. I add logs to tarballs and compress with an algorithm that allows for searching the logs in the tarballs without decompressing them

It does not matter what "reason" or "excuse" or "explanation" anyone presents, technical or otherwise, for why OpenAi does what it does

The issue is what are the consequences

They're very valuable data, and it's convenient to log in to see a previous chat.

If you have ever played with the api, its clear as day that the protocol itself is stateless.