What it really means when a shared file self-destructs

It is easy to say a file disappears. It is harder to say where it goes, and whether a copy of it is sitting on someone else's phone the whole time.

So let us be specific. When you send something through Fliko and it self-destructs, here is what actually happens at the receiver's end, and here is what we cannot promise, stated plainly.

The file is locked before it ever leaves your phone

Before anything is uploaded, the file is encrypted on your own device with AES-256-GCM. Our servers only ever hold the scrambled version. We cannot open it, read it, or hand a readable copy to anyone, because we never have the key in a usable form. This matters for the rest of the story: "destroy it later" only counts if nobody could quietly read it in the meantime.

The receiver gets a view, not a copy

When you share in secure mode, the other person does not download your file. They open it inside a locked viewer. There is no download button, no save option, nothing that drops a permanent copy into their gallery or their Downloads folder.

That single design choice removes the most common way files leak: the casual save that you forget about, which then rides along into a cloud backup and lives forever.

Screenshots: what we block, and what we cannot

This is where honesty matters more than marketing.

On Android, Fliko blocks screenshots and screen recording outright while a secure share is open. The system simply refuses to capture it.

On iPhone, Apple does not allow any app to block a screenshot. We will not pretend otherwise. Instead, the content blanks out the moment a screenshot or recording is taken, so the capture comes back empty, and you get a real-time alert that someone tried. You cannot stop the attempt on iOS, but you are never left in the dark about it.

If an app tells you it can fully prevent iPhone screenshots, it is not being straight with you.

The timer starts when it is opened, not when you send it

You set a short self-destruct window. The clock starts the moment the receiver actually opens the share, not the second you hit send. So a file that sits unopened for an hour does not quietly burn before the right person ever sees it.

When the timer runs out, the view closes and the share stops working. The link goes dead. There is nothing left for the receiver to return to.

"Destroyed" means gone from our side too

Expiry is not just about the viewer on the other phone. Once a share expires, the encrypted file is removed from our storage, and it is cleared from backups on the next cycle. There is no archive we keep "just in case." There is no recovery afterwards, not even for us. If that sounds inconvenient, it is supposed to be. A copy that can be recovered is a copy that can be leaked.

You stay in control until the end

You do not have to wait for the timer. If you change your mind, you can revoke a share from your phone at any time, and it stops working immediately, wherever it was sent. A shared link is never a permanent handover.

Why this beats a photocopy or a WhatsApp forward

A photocopy has no timer and no off switch. A file sent over chat sits in the other person's media folder, their cloud backup, and anywhere they forward it. Both are permanent by default.

A self-destructing share flips that default. It is temporary by design, view-only when it needs to be, and gone when its job is done. That is the difference between hoping a copy is safe and knowing there is no lasting copy to worry about.

If you want to see why permanent copies cause so much trouble in the first place, read how document leaks really happen in India. If you just want to try it, here is how Fliko works.