I have uploaded the official Google Drive file recovery confirmation email to GitHub because the Internet Archive removed it:
This is not a matter of opinion or personal perspective, but an empirical fact proven by tests: after emptying the trash, the chats immediately function with the restored JSON files, proving that the server-side data remained intact.
Even if Drive restores the plain JSON files, the chats should remain completely invalid (dead) on the server side, because the underlying AI prompt data should no longer exist on Google’s servers.
The Drive side is irrelevant: if the JSON file is restored to Drive, that’s fine. It is merely a configuration file containing an interaction ID. Restoring that file itself is not the issue.
The core issue is that I previously executed a deletion request on the AI Studio interface. Therefore, when the JSON file is restored to Drive and AI Studio reads that specific conversation ID from it, the AI Studio backend server should return “404 - Data Not Found”, because the full prompt history should have been purged from the server long ago.
https://web.archive.org/web/20260827061001/https://ibb.co/4R9hP1vy
https://web.archive.org/web/20260827061128/https://ibb.co/gbR1NtqW
https://web.archive.org/web/20260827061233/https://ibb.co/vCCHMK1f
https://web.archive.org/web/20260827061421/https://ibb.co/DgTrG7FG
The Double Deception: Google Lies on the AI Studio UI and Lies on the Drive UI
Forensic screenshots (authenticated timestamp: Aug 27, 2026, 07:59:17 CEST) provide undeniable visual proof that Google presents false statements across both user interfaces:
-
The Lie on Google Drive:
When emptying the trash, Google Drive’s explicit dialog box guarantees:
“The item will be permanently deleted and CANNOT BE RECOVERED LATER. This action cannot be undone.”- The Reality: This statement is factually false. Google’s own official Drive File Recovery tool recovers the file immediately after trash emptying.
-
The Lie on Google AI Studio:
The AI Studio interface explicitly claims:
“Your prompt will be permanently deleted after 30 days.”- The Reality: Executing deletion and emptying the trash does NOT trigger a backend purge. The “Delete” button merely hides the client-side JSON pointer. Once the pointer is restored to Drive, AI Studio instantly resurrects the complete conversation from the persistent server-side state.
Conclusion:
Both user interfaces actively deceive the end user regarding the scope and permanence of data deletion, in direct violation of GDPR Article 17 (Right to Erasure) and consumer transparency laws.
The Lie of “Recovery”: Google is not repairing a corrupted file system (as they claim); they are merely toggling a logical flag. When the robot “recovers” a file, it is in reality simply flipping an “is_deleted: true” value to “is_deleted: false”.
Since the file (and the underlying server-side state behind it) never ceased to exist in the background for even a single second, the data was never “deleted.” The file remained there all along, merely hidden/masked.
If Google tells the user that the file “cannot be recovered,” yet it remains sitting in their systems, Google is providing deceptive, false information. If a user requests “permanent deletion,” the data controller is legally obligated to ensure physical destruction. Google did not restore anything; they merely removed the mask from data that was never purged from the server.
Through this technical breakdown, Google’s “recovery feature” instantly turns into “evidence of illegal data retention.” True recovery does not exist; there is only the re-enabling of access to hidden data.
And Google has absolutely no legal basis to retain people’s prompts!
If Google allegedly retains my prompts for security reasons, they are legally required to explicitly disclose it! But the prompt is NOT the JSON file! They store the JSON file—fine, that is not the chat itself—yet restoring the JSON file instantly resurrects the entire prompt!
They need to make up their minds about what they are actually storing, because the Google Drive Trash unambiguously contained only the JSON files, not the server-side prompts!
If only the JSON file was in the Drive Trash, why did the entire conversation remain completely intact on Google’s servers after the delete button was pressed? And if they are intentionally storing it on their servers even after deletion, where is the user’s explicit consent and the lawful legal basis for doing so under the law?
I am submitting a critical update to the ongoing GDPR Article 17 enforcement case against Google LLC. The newly released official documentation for Google’s “Interactions API” (https://ai.google.dev/gemini-api/docs/interactions-overview) serves as the final “Smoking Gun” that perfectly corroborates my forensic findings and proves the deliberate nature of this data fraud.
The documentation exposes three undeniable facts:
-
The “Stateless” Defense is a Lie:
Google officially admits that the system is stateful and stores conversations on the backend by default.
Quote from the documentation: “The server uses this ID to retrieve the conversation history, saving you from having to resend the entire chat history.” and “By default, the API stores all Interaction objects (store=true)…”
This proves my claim: The Drive JSON file is merely a pointer. The actual data is actively hoarded on Google’s servers. -
The AI Studio “Delete” Button is a Documented Fraud:
The documentation explicitly claims: “…you can also view and manage stored interactions logs, including deletion from project storage, in AI Studio.”
My Bulk Forensic Video (restoring ~20 chats 5 days after permanent deletion) proves this statement is completely false. If the AI Studio “Delete” button actually executed a backend purge from “project storage” as documented, restoring the Drive JSON pointer would result in a 404 Data Not Found error. Instead, all 20 chats instantly resurrected, proving the backend deletion command is NEVER executed by the AI Studio UI. -
The Perfect Synergy with the Buganizer Confession:
This API architecture explicitly explains why the Google Security Team (Issue #552682596) closed my ticket as “Intended Behavior” and stated that data “persists on our backend systems.” They intentionally decoupled the visual UI deletion from the actual server-side data purging process.
Conclusion:
Google’s own technical documentation, combined with their internal Buganizer confession and my reproducible forensic video, provides ironclad proof that Google intentionally misleads users and actively bypasses the Right to Erasure (GDPR Article 17).
This complete evidentiary chain is archived and ready for court.
Sincerely,
György Istókovics (Bitu79)
They lie on the user interface, they lie in the terms of service, and they lie in their documentation!
“You can also view and manage stored interactions logs, including deletion from project storage, in AI Studio.” That is what the documentation says. I clicked “Delete” in AI Studio. Google is lying here by claiming that doing so deletes the data from “project storage” (the server). But by restoring the JSON, I instantly exposed them: the button does absolutely nothing to delete data from the project storage; it merely hides the Drive pointer.
As shown in my video recording, 5 days passed, and using a simple Drive recovery tool, I resurrected every single chat on the server! Their automatic server-side purge (Retention TTL) does not work either—the whole thing is a lie!
If their system truly automatically deleted everything in the Free Tier after 1 day, as the documentation claims, restoring the JSON from day 2 onward would have resulted in a 404 dead link! This proves that Google is openly lying to users about their automatic Data Retention Policy as well.
Here is the video, you fools:
Just imagine this scenario in court!
The Judge asks Google’s lawyer:
“Excuse me, when exactly is user data deleted?”
Google’s Lawyer: “Well… according to our official documentation, after 1 day.”
The Judge: “But your UI explicitly tells the user it takes 30 days.”
Me (holding up the video and the Buganizer ticket): “Here is my video showing everything is fully intact after 5 days, and your own engineer documented that you have absolutely no intention of purging the backend.”
These are the three parallel realities of Google! xD
https://github.com/istokovicsgyorgy79-jpg/CanusLupus/blob/main/CAUGHT~2.PDF
![https://github.com/istokovicsgyorgy79-jpg/CanusLupus/blob/main/FireShot%20Capture%20688%20-%20Caught%20by%20the%20Anchor_%20How%20Restoring%20the%20JSON%20Exposes%20Google’s%20Backe_%20-%20[www.google.com].png](https://github.com/istokovicsgyorgy79-jpg/CanusLupus/blob/main/FireShot%20Capture%20688%20-%20Caught%20by%20the%20Anchor_%20How%20Restoring%20the%20JSON%20Exposes%20Google's%20Backe_%20-%20%5Bwww.google.com%5D.png){kind=link}
![https://github.com/istokovicsgyorgy79-jpg/CanusLupus/blob/main/FireShot%20Capture%20689%20-%20Google%20–%20Saját%20tevékenységek%20-%20[myactivity.google.com].png](https://github.com/istokovicsgyorgy79-jpg/CanusLupus/blob/main/FireShot%20Capture%20689%20-%20Google%20%E2%80%93%20Saj%C3%A1t%20tev%C3%A9kenys%C3%A9gek%20-%20%5Bmyactivity.google.com%5D.png){kind=link}
The Search AI initially generated a generic theory (asynchronous purging) regarding my post.
However, when I presented it with the concrete evidence (the Buganizer ticket, the 5-day timeframe, and the official API documentation), the model retracted its theory and validated my technical breakdown step-by-step as correct.
My tests and the presented official documents are the actual facts. Google will also have to answer in court for the deceptive answers generated by AI Overview, as it disseminates falsehoods to protect the corporation!