Security, Privacy, and Integrity

People use security, privacy, and integrity interchangeably. I think this causes confusion.

They are related, but they answer different questions:

• Security: can someone do something they should not be able to do?
• Privacy: are we handling people's data the way we promised?
• Integrity: are users using the product to harm other users?

The same incident can involve all three, but the categories point toward different fixes.

Security

Security is about preventing unauthorized actions.

A security vulnerability is a flaw, usually in software, that lets someone cross a boundary they were not supposed to cross.

Equifax is the boring canonical example. A public-facing app used a vulnerable version of Apache Struts. Attackers exploited it. Data was stolen.

The important part for this taxonomy is not the data. It is the boundary crossing. Someone who should not have been able to run code or access internal systems was able to do so.

Security fixes usually look like boundary enforcement: patch the bug, harden the system, add authz checks, segment the network, reduce reachable attack surface, log the important stuff.

Security asks:

Can someone do something they should not be able to do?

Privacy

Privacy is not primarily about attackers.

Privacy is about whether you are handling people's information the way you promised, and the way the law requires.

Twitter's 2FA phone number case is a clean example. Users gave Twitter phone numbers and email addresses for account security, including 2FA and account recovery. Twitter then used that information for ad targeting.

Nobody needed to hack Twitter for that to be a privacy failure. The issue was use: data collected for one purpose was reused for another.

A more generic example: your privacy policy says you delete user data after 90 days, but the deletion job silently stops running. No attacker. No exploit. Still a privacy failure.

Privacy fixes usually look like purpose, consent, retention, deletion, access controls, documentation, and proof. You do not just have to do the thing; you often have to prove you did the thing.

Privacy asks:

Are we handling people's data the way we promised?

Integrity

Integrity is about reducing harm between users.

The product can work exactly as designed and still be abused. A network of fake accounts pretends to be real people, joins groups, posts links, comments on each other's posts, and tries to make an idea look more popular than it is.

There may be no software bug. No private data needs to be misused. The platform is being used to manipulate other users.

Spam is the same shape. A bot network floods comments with fake giveaways or crypto scams. The product is doing what it was built to do: letting users post comments. The problem is that some users are using that capability to hurt other users.

Integrity fixes usually look like detection, ranking changes, friction, policy, enforcement, appeals, and adversarial iteration. Of the three fields, this is probably the most cat-and-mouse.

Integrity asks:

How do we reduce harm between users?

Overlap

Real incidents can straddle categories.

A breach can be a security failure that creates privacy harm. A hacked account can become an integrity problem if it is used to scam other users. A privacy control can depend on security controls to work.

But the distinction is still useful. It tells you what kind of failure you are looking at and what kind of fix is likely to work.

Security protects boundaries. Privacy protects promises about data. Integrity protects people from each other. That is oversimplified, but useful.

This is an experiment with having AI craft an article based on my prompts.