Why does LINDDUN treat non-repudiation as a privacy threat when security treats it as a goal?
answer
- Same word, opposite sign, different protected party
- The property is plausible deniability
- Encryption does not remove this threat
- Ask who is harmed by proof of the act
- Decide per flow, not per system
basics
~20 sNon-repudiation destroys plausible deniability. Where a person must be able to deny acting, such as a whistleblower filing a report, evidence that irrefutably binds them to the act is itself the harm, so LINDDUN treats it as a threat.
solid answer
~50 sSecurity wants actions attributable so an actor cannot deny them; LINDDUN asks who is harmed if they cannot. For a whistleblower intake portal at a mining group, the reporter's safety depends on being able to say they never filed. Every artefact that binds them to the submission — the account used, the source address kept with the record, a signed receipt, timestamps in the intake store — is a non-repudiation threat mapped onto that store and the submission flow. The adversary here is not an outsider: it is the employing organisation itself, or an operator with legitimate access to the intake system. So the two views do not contradict each other, they resolve per flow. You decide deliberately which flows need accountability and which need deniability, and the same system can require both — a payroll change needs attribution, an anonymous report needs the opposite.
go deeper
Know that a privacy threat model can treat proof-of-who-did-it as a danger, because some systems exist precisely so a person can act without being tied to the act.
Be ready to explain that the property being lost is plausible deniability, and to point at concrete carriers of it: the authenticated session, stored source addresses, timestamps and receipts.
Demonstrate that you resolve this per flow with a named adversary, and that you can trace where deniability leaks through joins, operational copies and backups rather than through one obvious field.
Own the policy tension: an organisation cannot run one blanket attribution or retention rule when some of its flows exist to protect the person acting. Be ready to say who arbitrates that per flow.
## The apparent contradiction In a security threat model, repudiation is the threat and non-repudiation is the goal: you want a record that ties an action to an actor so nobody can deny what they did. In LINDDUN, **non-repudiation is one of the seven threat types**. Both statements are correct, because they are protecting different parties. The security view protects the system owner from a user who denies an action. The privacy view protects the data subject from a powerful party who can prove what they did. The property at stake is **plausible deniability**: the ability of a person to credibly claim they were not the one. Where deniability is part of what the system exists to provide, evidence of the kind a security pass would demand is not a control, it is the harm. ## A worked example Take a whistleblower intake portal operated by a mining group so employees can report safety violations and bribery. The protected asset is not customer data or money — it is the reporter's identity and, downstream, their personal safety. The adversary is not an anonymous internet attacker either. It is the employing organisation, plus any operator of the intake system whose account is compromised or who is quietly asked to look. Run the non-repudiation type against the elements of that design and the threats fall out: | Where it lands | The non-repudiation threat | | --- | --- | | Submission flow | The session that carried the report can be tied back to a specific employee workstation or account | | Intake store | The stored record retains a submitter reference, source address, or precise timestamp that pins one person | | Confirmation to reporter | A signed or account-bound receipt proves the reporter filed, and can be produced later against them | | Case-handling process | Handling metadata accumulates enough detail to reconstruct who filed, even when the report body is anonymised | Notice that none of these is a confidentiality failure. The report may be encrypted at rest and in transit and every one of these threats still stands, because they are about **binding a person to the act of filing**, not about reading the content. That is exactly why the privacy pass finds them and a confidentiality-focused review does not. ## How you resolve it in practice The resolution is per flow, not global. A useful sequence: 1. **Name the adversary for this flow.** "Who would want to prove this person did this, and what access do they already have?" If the answer includes the operator or the employer, deniability is in scope. 2. **Ask what the subject risks if bound to the action.** Retaliation, prosecution, exposure of a protected characteristic, physical danger. If the answer is serious, non-repudiation is a threat here even if the same evidence is desirable elsewhere in the system. 3. **Decide what evidence this specific flow keeps, and for how long.** The point of the pass is that the answer becomes a deliberate design decision with a stated rationale, rather than the default output of a logging framework nobody scoped. 4. **Check the derived paths.** Deniability is rarely lost through one field. It is lost through a join: an SSO identity on the submission session, a support ticket raised on the same case, an access log on the case store, a backup that kept a field the live record dropped. A common weak answer is "so you just don't log anything". That is not the claim. Accountability and deniability are both legitimate requirements, and most systems need each on different flows. Financial authorisations, administrative actions, and consent changes generally need attribution; anonymous reporting, health self-assessment, and support contact for at-risk individuals generally need deniability. The methodology's contribution is forcing you to say which one this flow is, in the design phase, instead of discovering the answer after a reporter is identified. ## Why interviewers like this question It is the cleanest test of whether a candidate has actually made the shift from system-as-asset to person-as-asset. Someone who has only ever run a security pass will insist non-repudiation is a good thing and argue with the premise. Someone who has run a privacy pass will immediately ask **who the adversary is**, notice that the answer can be the operator, and reason about the flow rather than the whole system.
- How do you decide whether a given flow needs accountability or deniability?Name the adversary for that flow and ask what the subject risks if bound to the action. If the plausible adversary includes the operator or the subject's employer, and the consequence is retaliation or exposure, deniability wins. If the risk is a user denying a financial or administrative action they took, accountability wins. The same system routinely needs both — the mistake is setting one policy for the whole application instead of deciding flow by flow.
- Does encrypting the submission remove the non-repudiation threat?No. Encryption addresses disclosure of the content. The non-repudiation threats live in the metadata that binds a person to the act of submitting: the authenticated session, the source address stored with the record, precise timestamps, a receipt tied to an account, or handling records on the case. All of those survive an encrypted payload untouched, which is why the privacy pass surfaces them and a confidentiality review does not.
- Where does deniability usually leak once the obvious fields are removed?Through joins rather than through one field. A single sign-on identity attached to the submission session, a support ticket opened about the same case, an access record on the case store, or a backup that still holds a column the live record dropped. Analysing the flow end to end, including the derived and operational copies, is what catches these; looking only at the primary record does not.
An anonymous handwritten note and a notarised affidavit both deliver the same message. The notarisation is a feature when you need to hold someone to it, and a danger when the writer's safety depends on being able to say it was not them.
saying these in an interview costs you the question
- Insists non-repudiation is always a security goal
- Argues the premise is wrong rather than engaging
- Says deniability just means logging nothing anywhere
- Thinks encrypting the report removes the threat
- Assumes the adversary must be an outsider
- Applies one attribution policy to the whole system