I asked what a fingerprint was. Then it found a video I thought was gone.

The file was empty

A long client call was recorded in the browser, straight onto an external 4 TB drive. It was the best working session of the year.

After the call, the video file was 0 bytes. The file had been created when the recording started, and nothing was ever written into it.

The tool was Jitsi. The meeting screen said to stop the recording before leaving, or it would not save. The tab closed without that stop.

What do you mean you fingerprinted them?

That question is this note.

It was writing the whole time

Chrome does not pour a recording into the file you picked. While the call is going, it writes a hidden file, and it only turns that into the real recording when you stop and let it finish saving. The hidden file's name ends in .crswap. You are not meant to see it.

Two recordings from July were still sitting on the same drive as those hidden files, about 492 MB and about 395 MB. So the browser really had been writing video the whole time. A length for them is not in this note. An unfinished file like this can claim a length that is nonsense. The deleted call itself claims 240 hours. That number is a blank the file writes, not the length of the call.

Deleted is not erased

Delete, on this drive, is a line crossed out of a table of contents. The drive uses a format called exFAT. Microsoft's instructions for deleting a file update that list and mark the space as free. They do not wipe what was written.

The pages stay until something new is saved on top of them. Before the search, the drive was set so it could be read and not written. A download, a copy, even a small save, can be the new chapter.

Try it

A fingerprint is a short code made from a file's contents. Same contents, same code, every time. Change one letter and the whole code changes. You can compare two codes instead of comparing two files.

The box does this in your browser. Nothing you type is sent anywhere.

What a fingerprint is

Think of a rubber stamp that the file presses into a card. The stamp is not the file. It is much shorter. For the job in this note, two files with the same stamp are the same file, and two files with different stamps are not.

The stamp has a name. It is called a hash. Put the contents in, get a short code out. The box uses a recipe called SHA-256, and its code is 64 letters and numbers. The hunt on the drive used an older recipe, SHA-1, and kept only the first 16 characters. Same idea. Shorter code. The box uses the full newer one, so you can watch a single letter change the whole stamp.

Why the first megabyte was enough

The drive still held 81 video files. Reading them would have meant watching other people's recordings, which was never going to happen. The first second of a recording is different every time: the clock, the screen, the sound in the room. So the first megabyte is enough to tell those 81 recordings apart without opening them.

Each of those files got a code from its first megabyte. All 81 codes were different.

A mark every one of these videos shares

Every one of these recordings is a WebM video, and every WebM video starts the same way: four tiny marks, then the word webm. The search was not watching the videos. It was walking the drive, looking for that mark.

Those four marks are written 1A 45 DF A3. A cousin format starts with the same four, which is why the word had to be there too.

The first try finished in the same second it started. The computer reported the drive's size as zero, so the script believed the drive was empty. Reading the disk directly on a Mac can report a size of zero even when the disk is full. The size was read another way. The real pass started at 12:22 AM and finished at 1:59 AM, 1 hour and 38 minutes across the whole drive. It moved at 546 to 683 MB per second and found 85 videos. The counts below are from that finished pass.

85, then 62, then 23

The scan found 85 videos. The same short code, compared with the 81 files still on the drive: 62 matched a file that still exists, and 23 did not. Those 23 are the deleted ones.

The twenty-third

Sorted by where they sat on the drive, the call was the twenty-third deleted recording, and the last one on the drive. It sits about 765 GB in.

One frame, pulled privately and not shown here, was enough to know. Two founders, and the meeting on the screen. Nothing from that frame is on this page. Other people's calls stay off it.

What I have, and what I do not

The recording file from that night is still 0 bytes. The deleted video was found. A copy that plays from the start, through the middle, and out to the end has not been made, and it has not been checked. If that changes, this note will say so, with the length and what the frames actually show.

An audio backup would be a separate claim. It is not here, because it was not checked for this page.

Deleted a recording? Do this first

This is for anyone who just recorded a call in a browser and found an empty file, or who deleted a file and has not written anything new to that drive yet.

1. Stop writing to that drive. Do not save, copy, or download anything else onto it.
2. Remount it read-only if you can, or eject it, until someone can read it without writing.
3. Next time, stop the recording from the tool's own menu and wait until it finishes saving.
4. Record to the computer's own disk. Copy the finished file after it has a real size.
5. If you have to go looking, fingerprint the files you still have first, so you can skip them.

Nothing to buy tonight. The first move is to stop writing to the drive. A full read is slow and stays read-only. If you want that done, it is a fixed piece of work, agreed before it starts.

You already use this

When Git saves a version of your work, it names that version with a fingerprint of what is inside. Same contents, same name. Git can use the newer recipe, SHA-256, for that name. Its own notes say it picked SHA-256 in 2018, after someone showed, on 23 February 2017, that two different files could be built to share an old SHA-1 fingerprint.

A password store is a cousin, and it is not this. A password should be mixed with a pinch of random data, then run through a recipe that is deliberately slow, so guessing millions of passwords is painful. NIST, the standards body, requires that. Pasting a password into the box above and saving the code is not that. Do not store a password that way.

Dropbox can check that a file in the cloud is the same as a file on your computer without downloading it, by comparing fingerprints. Its recipe cuts the file into 4 MB pieces, fingerprints each piece, then fingerprints that list.

Microsoft Defender can block or allow a file from its fingerprint, instead of opening it. When it has two fingerprints for the same file and they disagree, it trusts the newer, longer one. That is one product's rule, not a claim about every antivirus program.

Shazam is the cousin people mean when they say fingerprint out loud. If the phone is offline, Apple's own support page says the app still creates a fingerprint of the sound, and matches it once the phone is online again. A different recording of the same song can match. A fingerprint of the file would not, unless the file itself were the same. Same word. Different job.

Where this stops being the right tool

The short recipe used on the drive, SHA-1, is old. It was enough to ask whether a file was one already on the drive. It is the wrong tool if someone is trying to fake a match on purpose. NIST is retiring it for security work, and that retirement finishes on 31 December 2030. The box on this page uses SHA-256 for that reason. Nobody that night was trying to build a second file that would wear the same stamp.

Two limits on the hunt. Only the first megabyte was fingerprinted, so two files that start the same would look the same even if the rest were different. Only the first 16 characters of the code were kept, not the full 40. That is a shorter stamp, so two different files are more likely to share it than they would with the full code. The 81 files on the drive had 81 different codes, so the short stamp told them apart. It is not proof that no two files anywhere could ever match.

And if something new has already been written over those pages, there is nothing to find. That is the amber in the diagram. A fingerprint cannot read what is no longer there.