← All posts / Meta

The Delete Button That Lies: A Year-Long Crusade Proves Google AI Studio Fakes Data Deletion

A Hungarian researcher's reproducible 'JSON restoration test' shows AI Studio's delete only removes a Drive pointer while backend conversations persist — and Google's bug bounty program auto-banned him for reporting it.

The Delete Button That Lies: A Year-Long Crusade Proves Google AI Studio Fakes Data Deletion

On September 20, 2026, a story that has been simmering on Google’s own developer forums for the better part of a year finally reached the Hacker News front page: “Google AI Studio fakes data deletion. VRP auto-banned me in 60s for reporting it.” The poster, a Hungarian independent researcher who goes by Bitu79 (Istokovics György), has spent roughly eleven months documenting a claim that is either a serious GDPR problem for one of the world’s largest AI providers — or a misunderstanding of how modern cloud storage works. The technical evidence he has assembled, and the way Google has handled his reports, deserve a closer look either way.

What the delete button actually does

The core of the allegation is structural. Google AI Studio, the free web interface for experimenting with Gemini models, stores each prompt or chat session as a small .json metadata file in the user’s Google Drive. When you click “Delete” on a prompt, the claim goes, the system does not send any destruction signal to the backend. It simply moves that JSON pointer to the Drive Trash. The actual conversation — tokens, context, session state — remains alive on Google’s server-side storage, associated with the interaction_id embedded in the pointer.

If that were the whole story, it would be unremarkable; lots of products use soft deletes. The problem is what happens next, and what the UI says while it happens.

The JSON restoration test

The researcher’s proof technique is disarmingly simple, and this reproducibility is why the story keeps resurfacing. He calls it the JSON restoration test:

  1. Create a multi-turn chat in AI Studio containing identifiable test data.
  2. Click “Delete” on the prompt. The UI warns: “Your prompt will be permanently deleted after 30 days.”
  3. Open Google Drive, find the .json pointer in the Trash, and empty the Trash. A modal guarantees: “The item will be permanently deleted and cannot be recovered later.”
  4. Wait — five days in the documented test, far beyond any claimed TTL.
  5. Use Google’s own Drive File Recovery tool to restore the discarded JSON pointer.
  6. Open the restored file in AI Studio.

The result, captured on video across PC and Android: the chat session immediately resumes with 100% of its historical context, memory, and tokens loaded from the backend. The session was never destroyed; only the key to it was thrown away, and Google’s own recovery tool handed the key back.

There is an important nuance the researcher stresses: restoring the JSON does not restore the conversation content, because the JSON contains no content. It is a UI key. The conversation could only resume intact if the backend had done absolutely nothing when “Delete” was pressed. As one Hacker News commenter put it, the counterargument that “restore windows exist for accidental deletions” would be fine — if the button said so. Promising permanent deletion and then not delivering it is the actual complaint.

The documentation contradiction

The evidence gets sharper when set against Google’s own documentation. The Gemini API docs state that store=true is the default, but explicitly promise that data for Free Tier users is automatically purged by the system after one day. If that TTL were real, restoring the pointer on day five would yield a “404 Not Found” from the backend. Instead, the chat loaded completely intact.

The contradictions stack up across three layers:

  • AI Studio docs (UI): emptying the Drive Trash permanently destroys the data. The POC shows the delete button only discards the JSON pointer and never touches the server.
  • Gemini API docs (backend): a 1-day Free Tier TTL. The video shows full context recovery after 5+ days.
  • AI Studio log settings (/logs): a mandatory retention period of 55 days, with the privacy toggles that would disable Interactions API storage greyed out behind an active billing account. Free users, in other words, cannot opt out of logging at all.

When the user empties the Trash, the AI Studio UI throws a 404 error — which reads, to any normal person, as confirmation the data is gone. The researcher’s interpretation is that the 404 is a frontend response to a missing Drive pointer, not evidence of backend purging. He calls the whole mechanism “a visual placebo based solely on pointer manipulation.”

Reported through the front door — and banned in 60 seconds

The story’s second act is what happened when he tried to use official channels. He filed a report with Google’s Issue Tracker on September 8, 2026, classifying it as “Broken Access Control: ‘Deleted’ Interaction API sessions remain persistently accessible and bypass the 1-day TTL purge.” The automated acknowledgment arrived at 1:22 PM. Six minutes of detailed technical follow-up later, the ticket’s fate was sealed.

When he submitted the finding to Google’s Vulnerability Reward Program — the AI VRP launched in October 2025 with rewards up to $30,000 — an automated bot banned him within roughly 60 seconds, citing a “Code of Conduct” violation. Worse, from Google’s perspective, the bot’s rejection went on record describing the behavior as “Intended Behavior.” If the deletion behavior is intended, then the UI text promising permanent deletion is not.

His treatment on the official Google AI Developers Forum paralleled the VRP experience. He estimates around 70% of his posts detailing the mechanics were deleted by moderators without explanation — he counts over 140 removed posts — and he has archived video of the removals happening in real time. Everything now lives on archive.ph, the Internet Archive, and ghostarchive, which is why the censorship attempts have become part of the story rather than the end of it. According to his account, almost a year of outreach has not produced a single human reply: even Google’s Data Protection Officer channel responded with what he describes as an automated script. NOYB, Max Schrems’s privacy organization, initially replied and then went silent. The Irish DPC, which he characterizes uncharitably as “Google’s shield,” gave him trouble for using AI to write his emails.

Under GDPR Article 17(1), the right to erasure means the controller must, without undue delay, execute a process that permanently prevents future restoration and active processing — not merely hide data from a frontend. Article 5(1)(e)‘s storage limitation principle requires removal from active production once the purpose ends, which a user pressing “delete” clearly signals. A terms-of-service clause saying “in some cases we do not delete immediately” cannot override these; they are non-derogable rules. The researcher has sent physical letters to Google — he has posted the USPS return receipts — and says a civil lawsuit is coming: “Do you guys think I’ll actually file the lawsuit? HELL YES!!!”

It matters that AI Studio’s free tier has logged, retained conversation data by default for training-adjacent purposes, and the opt-out is paywalled. For enterprise deployments, this story is a reminder that “delete” in a vendor UI is a claim about backend lifecycle, and the only proof that counts is a recovery test after the TTL window.

The steelman

Fairness requires the counterposition. A Hacker News commenter who runs websites with customer data argued that soft-delete-plus-restore is standard engineering: users catastrophically delete things by accident, blame the service, and demand recovery; no operator builds hard deletes for consumer products. Google’s anticipated defense — that background retention within a disaster-recovery window (Drive’s is about 25 days) is a deliberate recoverability feature — has real precedent. From there, the argument goes, the bug is one of UI copy, not architecture: label the button “hide” and expose a genuine “permanently delete” path further down.

But that defense cuts both ways. If deletion semantics are documented as a 1-day purge and the UI promises irreversibility, then a 55-day default retention with greyed-out opt-outs is not a wording issue — it is a mismatch between promise and practice. And an auto-ban issued in under a minute, with “Intended Behavior” in writing, is the opposite of the human review a responsible disclosure program exists to provide. Google has not publicly responded to the allegations. The most damning detail is also the simplest: the researcher says that after he exposed the flaw, Google quietly changed the warning text on the delete dialog rather than the backend behavior — an archived diff of a failed cover-up.

Why it matters now

Two developments pushed this from forum grievance to front-page news. First, the Medium post consolidating the year of evidence hit 46 points on Hacker News on September 20, with active discussion. Second, corroborating threads on the Google AI Developers Forum characterize the same behavior as a GDPR Article 17 deletion failure affecting the free tier — meaning millions of users who assumed their throwaway AI Studio experiments were ephemeral may have server-side conversation state that outlived the delete click by design.

For anyone building on Gemini’s free tier, the practical takeaway is uncomfortable but simple: treat nothing in AI Studio as deleted until you have run the restoration test yourself after the documented TTL. For Google, the issue is not that disaster-recovery windows exist — it is that the company’s UI text, API documentation, log settings, and VRP bot each tell a different story about the same data, and a lone researcher with archives has now documented all four versions.