Generate realistic fake test data FAUX

Why the fake data is fake in specific ways

Making up a plausible person is easy. Making one up that cannot accidentally be a real person takes a little care, and the care is the tool.

• Email addresses end in example.com. RFC 2606 reserves it for exactly this: it cannot be registered and mail to it goes nowhere. A demo that used gmail.com would be generating addresses that belong to somebody.
• Phone numbers come from the ranges reserved for fiction. The UK's 07700 900xxx and 0113 496 0xxx, the North American 555-01xx block. These are held by the regulators so that a number in a screenshot, a test suite or a film does not ring a stranger's phone.
• Card numbers are the published test numbers. They pass the Luhn check, so a form accepts them, and they map to no account at any issuer.
• Names are combined rather than copied. Common given names and surnames mixed independently, so the output looks ordinary without being a list of real people.

What it is for

Chiefly the screenshot. The most common way personal data escapes an organisation is not a breach; it is somebody demonstrating a system with live records open, in a slide deck, a support ticket, a training video or a bug report that then lives in a tracker forever. Populating the demo with people who do not exist costs a minute and removes the problem.

Also: filling a template so the layout can be judged, loading a test database, checking that a form handles a long name or an apostrophe, and giving a contractor a file shaped like the real one without any of the real one in it.

What it is not

It is not anonymisation. Generating new people is a different operation from de-identifying existing records, and one cannot substitute for the other. If you need to keep the shape and statistics of real data while removing who it is about, ANON pseudonymises consistently so the same person stays the same person across rows.

And the output is deliberately not realistic in every respect: the addresses do not geocode, the companies do not exist, and the dates are not drawn from a real population's distribution. If you are testing something where those properties matter, generate for the property you actually need rather than trusting a plausible-looking table.

Decoy files, and the marker you watch for

The decoy tab makes a file that looks worth taking and is worth nothing: a stray .env, a credentials list, a short database dump. Each one carries a marker, a string written into a place a thief would read, a session secret, an API token, the address on a row. You keep a record of the marker; FAUX keeps none.

The point is not the file. It is the day the marker turns up where it should not: in a log, in your inbox, in a paste somebody sends you. A string that is in one file and one file only can have reached that second place just one way, so the moment you see it again you know the decoy was taken, and roughly when.

• Give an inbox or a domain you watch and the marker becomes an address. If you own a catch-all domain, mail to that address reaches you, so a message to it is the alarm. Leave the field empty and the marker is a plain string you set a search alert on, or search your own logs for.
• The keys are the right shape and none of them work. An AKIA… line or an sk_live_… line makes the file read as real; the value after it is random, so it authenticates nowhere.

What a decoy will not do

It does not call home. Nothing in the file runs when it is opened, there is no macro and no script, and FAUX sends nothing anywhere, to you or to us. The watching is yours to set up, on an inbox or a log you already have. A decoy is a tripwire you can see go off, not a program that reports back.