How to anonymise names in a spreadsheet, and keep the same person the same

Replace each name with a keyed hash of it. Under one key the same person becomes the same code in every file you ever process, so records still join up; under a different key they become entirely different codes, so one release cannot be linked to another; and without the key nobody can get from a code back to a name, because the codes cannot be recomputed without it. That is the whole method, and it is the one ANON uses. The rest of this page is why the two answers you will find instead do not do what they are asked to, and what this one still leaves behind.

Why Find and Replace is not it

Replacing names with Customer 1, Customer 2 and so on works for one file, once. The numbers are the order the names happened to turn up in. Next quarter's export has the same people in a different order, so Customer 7 is somebody else now, and the two files cannot be joined. If the whole point is a study that follows the same people over time, this has removed the one thing you needed to keep.

A hash fixes that half. A code that is computed from the name rather than assigned to it comes out the same however many times you compute it, in whatever file, in whatever order.

Why a lookup table is not it either

The other answer is a second sheet: name in one column, code in the other, and look each one up. It is consistent, so it passes the first test. It fails the one that matters, which is that the sheet is a complete list of who every code is. Keeping it beside the data means the data is not anonymised at all; anybody who can open the one can open the other. Keeping it somewhere else is the right idea, and at that point what you are keeping somewhere else is a key — so use one that is a few dozen characters rather than a spreadsheet of everybody.

Why a plain hash is not anonymous

This is the step page one skips. Hashing a name with SHA-256 gives a code that cannot be reversed by arithmetic, and it is still not anonymous, for a reason that has nothing to do with the arithmetic: there are only so many names. Anybody who wants to know who 0A2D45EF is does not reverse it. They hash every name they can think of — a phone book, an electoral roll, a list of common surnames crossed with common first names — and look for the one that comes out 0A2D45EF. That takes seconds, and it works just as well on dates of birth and postcodes, which are smaller spaces still.

A keyed hash closes that. The code is computed from the name and a secret key, so the attacker cannot build the candidate list: without the key, hashing every name in the phone book produces a different set of codes from yours. The construction is HMAC-SHA256, which is the standard way of doing exactly this, and the codes ANON writes are checked on every build against the same computation done independently outside the tool.

What the tool decides for you, and says so

• Spelling. Ash Whitfield, ash whitfield and Ash  Whitfield  with two spaces and a trailing one are treated as one person. Case, stray spaces and doubled spaces are collapsed before hashing, because they are almost never different people and because a method that gave them three codes would fail silently on the messiest data, which is all real data.
• The column is part of the code. The same value in two different columns gets two different codes. Otherwise a postcode that happened to equal a reference number would collide, and, more to the point, a code could be lifted out of one column and searched for in another.
• The key stays out of the file. What comes out is the data with the chosen columns replaced. The key is shown to you once, to keep somewhere the data is not, and is never written into the output.

What the key costs, both ways

Lose it and you cannot re-link anything, ever: a new key produces entirely different codes, so this year's file and last year's cannot be joined. Keep it, and anybody who has it can re-identify everybody. Neither of those is a fault in the method; they are the same property seen from two sides, and it cannot be designed away. Decide where the key lives before the first file goes out, not after.

Pseudonymised is not anonymous

The most important thing on this page is the limit. Replacing the names leaves every other column intact, and other columns identify people too. A postcode and a date of birth together narrow a country to a handful of people; a postcode, an employer and a salary band narrow it to one. The name was never the only identifier, and taking it out has not made the rest safe to publish.

That is a different question with a different tool. Checking a dataset is safe to publish goes through it: how many people share each combination of the columns you are releasing, and what to do about the combinations that come out at one.

What this is and is not

ANON reads a CSV in your browser, replaces the columns you choose with keyed-hash codes, and hands back the file and, separately and only if you ask for it, the re-identification key. Nothing is uploaded and it works with your connection off.

It is pseudonymisation and it is honest about being that. It does not judge whether the columns you left in still identify people, and it will not stop you publishing a file that does.