Your data is never actually being deleted

Source: Dev.to

Why the Delete Button Doesn’t Actually Delete Data

There’s a reasonable assumption most people make when they press a delete button: that the thing gets deleted. It doesn’t, and this isn’t some secret — it’s just how cloud infrastructure works, and it’s worth understanding before you invite a robot that moves and listens into your home.

When you delete a file from Google Drive, or a message from any cloud service, what actually happens is that the pointer to that file gets removed from your interface. The data itself stays on the server. From the company’s perspective, this makes sense: if a government agency shows up with a legal request for a specific piece of data that your user already “deleted,” the last thing you want to say is that you no longer have it. So you keep everything and simply stop showing it to the user.

• Some companies have data‑retention policies that run for decades.
• Others don’t delete anything at all because the cost of storage is negligible and the cost of not having something when someone important asks for it is high.

How Cloud Infrastructure Handles Data

The data rarely stays in one place. Cloud infrastructure is built on layers — the raw data goes in, gets split, filtered, and routed to different systems for different purposes. There are audit logs for forensic analysis, processing queues for various data types, and at each hop there are people and systems that touch what’s passing through.

If you’ve ever looked at a cloud provider’s terms of service and seen the phrase “we may use your data to improve our services,” that clause does a lot of work. Model‑training teams need real conversations because synthetic data only goes so far. Customer support needs access to user accounts to help people. Server administrators have root access to the file system because that’s what administering a server requires. These are all legitimate reasons, and none of the people involved are doing anything wrong. The cumulative effect is that private conversations, in the normal course of business, pass through dozens of systems and become accessible to far more people than most users would guess.

I know this from the inside. Before starting Syntheva, I worked at one of the large technology companies on a product that listened. What surprised me wasn’t the data retention — I expected that. What surprised me was how porous the internal access model was in practice, not because of negligence but because large organisations inevitably accumulate access grants over time.

• Someone needs to debug a problem → they get access to the relevant logs.
• Someone is training a model → they get access to the relevant dataset.

Over years, at the scale these companies operate, this adds up to a situation where your data has been touched by an enormous number of people for an enormous number of reasons, all defensible, none visible to you.

Implications for Cloud‑Connected Robots

For most cloud services, the exposure is mostly passive — data flows in one direction, gets stored, and might be used for something you didn’t intend. The robot case is different in a way that matters. A cloud‑connected robot isn’t just sending your data out — it’s receiving instructions back. The cloud doesn’t just log what you say; it determines how the robot responds, what it does, and how it behaves in your home while you’re not watching it.

That bidirectional flow means that whoever controls the cloud pipeline controls the robot. Not in theory — in practice, someone with internal access could implement a change in an afternoon by inserting a filter into the pipeline that adjusts what responses get generated. This isn’t a sophisticated attack; it’s a configuration change.

Our Approach with Synthia

We built Synthia without a cloud connection because we understood this from experience, not from reading about it. There are no wireless modules inside her because there’s nothing to compromise if there’s no connection to compromise. Updates happen by taking out the SD card and burning a new image — what security professionals call an air‑gapped process, meaning there is no live connection through which anything can be pushed or intercepted.

Because of this architecture, we also cannot remotely access your robot to help you if something breaks. Some people read that as a limitation; we read it as the architecture working exactly as intended. Any company can tell you they don’t access your device. We physically cannot, and you can open her up and verify that yourself.

The delete button in Synthia’s interface truly deletes things because the data never left the device in the first place.