My related post:
https://hn.algolia.com/?query=The%20crusade%E2%80%93against%...
92 karma · joined March 30, 2026
https://hn.algolia.com/?query=The%20crusade%E2%80%93against%...
Google AI Studio’s “Delete” Button Is Not Real Deletion — This Is Illegal Data Retention in the EU
I have proven that Google AI Studio does not delete user data, even when the interface claims it does. This is not a UI bug. This is undisclosed backend behavior and illegal data retention under EU law. When you press Delete, Google only removes the local JSON file from the client side. The server-side session, context, and conversation data remain fully intact. Even after emptying the trash, the backend still keeps everything. When you restore the JSON, the chat continues from the exact same internal state, which is only possible if the server never deleted anything. This is the equivalent of saying: I have a key and a house. The house disappears, but I can still walk through the door. If the data had truly been deleted, the model would not be able to continue the conversation. But it does, which proves the backend never removed the data. Under GDPR, the right to erasure, data minimization, purpose limitation, lawful basis, and transparency are all violated. Google claims the data is deleted, secretly retains it, and continues to process it. This is not a misunderstanding. This is not a UI issue. This is undisclosed internal behavior and unlawful data retention. I proved it with a simple logical test that anyone can reproduce.
Official Google emails about the recovery process:
https://archive.org/details/gmail-0-1805000041398-confirmati...
I prove the authenticity of the video by saving the long screenshot from the Google My Activity page, the PDF‑exported screenshot, and the full HTML archive into both my Google Drive and the Internet Archive. These files can be compared with the events shown in the video down to the exact minute. Google My Activity logs confirm every browser action, and the saved files are fully synchronized with the video in both timing and content.
Google My Activity:
https://drive.google.com/file/d/1Vywb6sim4lVin3d4dA9CUQMF_Pr...
https://archive.org/details/my-activity_202607
Part 2 of the video can be viewed here:
Google AI Studio’s “Delete” button is misleading.(Part 3):
I can prove that my posts were deleted 3–4 hours earlier, and I can also prove that afterwards Google’s AI Overview still found them cached. This puts Google in a very bad legal position, because the system logs and the Wayback snapshot together show that they stored and processed deleted data without any lawful basis. In this post you can find the full demonstration of this fact:
https://discuss.ai.google.dev/t/they-deleted-my-post-so-i-m-...
The posts were deleted, yet the snippet was still there — a stored fragment of my post in the Google index that AI Overview uses. The screenshots ‘Képernyőkép 2026‑07‑20 155225’ and ‘Képernyőkép 2026‑07‑20 155249’ clearly prove that Google continues to possess and process the deleted data. Here are the images:
https://discuss.ai.google.dev/t/they-deleted-my-post-so-i-m-...
The platform also continues to store the images that were deleted from the post, and these files remain physically present on Cloudfront. The deletion only hides the images in the user interface; it does not remove the actual files from the CDN. Because the image files are still stored on Cloudfront, Google Lens can find and recognize them without any issue. This proves that the platform keeps the deleted images on its servers, unchanged and accessible, which constitutes unlawful data retention.
Archive.ph does not save the Cloudfront‑hosted images, because Cloudfront is a separate CDN layer that the archiver does not capture. The only reason these “deleted” images still open is that the platform never removed them from its own servers. The files remain physically stored on Cloudfront, unchanged and accessible, even after the post is deleted. Because the images are still present on the CDN, Google Lens and other systems can find and analyze them without any issue. This proves that the platform’s deletion is only a UI‑level hide, not an actual removal, and that the service is unlawfully retaining deleted images on its Cloudfront infrastructure.
The proof‑of‑evidence video is available here:
https://archive.org/details/unknown_2026.07.20-17.19
These are the deleted posts:
https://archive.ph/qIl2L/image
https://web.archive.org/web/20260720054146/https://discuss.a...
https://web.archive.org/web/20260720055537/https://discuss.a...
Google’s diabolical plan was that since the Drive trash automatically empties after 30 days, the JSON file would disappear from my sight forever. At that point, the interface tells me “there is no such prompt,” and because the chat cannot load without the file, Google assumed they were fully protected. They calculated that the user would never again have any technical means to enter the conversation, making it impossible to prove that they never actually deleted anything from their internal servers.
But Google got caught precisely because of their own file‑restore robot, and this is my technical checkmate against them: The built‑in Google Drive file recovery tool is a local, “blind” robot. This robot physically has no access to Google’s remote, internal AI backend servers, and it cannot reconstruct server‑side database records or live session states out of thin air. This robot only operates inside the Drive storage and can only resurrect the discarded JSON file.
When, after emptying the trash, I successfully restored the deleted JSON file with this robot, the AI Studio interface immediately loaded the working chat with its full previous memory and internal state.
Since the Drive robot demonstrably did not touch the backend system, the chat’s instant startup proved in black and white that Google’s backend servers continued running and storing my data uninterrupted even after pressing the delete button and after the trash was emptied. The backend system was never affected by the deletion command.
Google cannot deny this in court. They cannot claim temporary deletion or technical error, because due to the operational limitations of their own robot, their fraud has become an irrefutable fact. They only hid the surface key while illegally stealing and retaining the data. If they had the nerve to cheat, now they must publicly apologize and take responsibility before the court and the cameras.
This is corporate fraud, and they cannot produce an update log for the renaming of the button, and the renaming itself states misleading things that contradict the technical behavior of the deletion. This was a rushed move by Google, demonstrably, intended to hide the illegal data retention.
I had already raised the issue of data retention before the button was renamed — by email, on the forum, in every possible way. I even sent physical letters to Google’s US corporate address, which were demonstrably received, with signed return receipts and confirmation from the Hungarian postal service.
Here are the posts that prove everything: