Cryptography often appears in privacy discussions as a single checkbox: encrypted or not encrypted. Software findings are rarely that complete. A scanner can identify a suspicious storage path or a call to an unsafe primitive, but it does not automatically know what data is involved, who can read it, which controls exist outside the analysed code, or whether the data needed to be stored in the first place.
That gap is a useful case for PrivDev, my research on connecting technical findings to privacy concepts. The project’s implemented first layer maps scanner data-type labels to a common vocabulary. A later research question asks how findings about software weaknesses could support developer guidance without turning a technical clue into a legal verdict. Cryptography exposes why this distinction matters.
A finding is an observation with a boundary#
Imagine a scanner reports that a value is written to browser localStorage and finds no encryption operation on the path it analysed. What can we safely say? We can point to the reported path, the value’s source if the scanner captured it, and the absence of an encryption call in that path. We cannot infer that the entire system has no protection. We also cannot infer that encryption would make the design appropriate.
Several questions change the assessment. Is the value personal data or a test value? Is it a short-lived token, a contact address or a medical note? Can scripts running in the page read it? How long does it remain there? Does the server apply another control? Which attacker is the team trying to defend against? The answers affect whether to remove the storage, reduce the data, change access controls or use a cryptographic measure.
This is not an argument to postpone an obvious security fix. It is a way to state the evidence precisely enough that the right person can act on it. “No encryption visible in the analysed code path” gives a developer a concrete lead. “The application violates the GDPR and must use field-level encryption” asserts facts the scan may not have established.
Why privacy needs more than a security label#
Security taxonomies organise technical weaknesses. Privacy work also asks about purpose, necessity, recipients, retention and rights. A weakness such as cleartext storage may be relevant to confidentiality, but the legal assessment depends on the processing activity and its circumstances. Even when encryption is appropriate, details matter: what is encrypted, where keys live, who can decrypt, and what happens after decryption. A label alone cannot answer those questions.
The GDPR’s security-of-processing provision names encryption among possible measures in a risk-based assessment; it does not turn every scanner warning into one mandatory implementation. PrivDev’s research notes therefore distinguish an observed weakness, a candidate measure and a possible legal review cue. The proposed connection between them needs its own evidence and expert scrutiny.
A bridge that can abstain#
One of the project’s recent lessons came from its first mapping layer. Earlier output asserted specific GDPR references from data-type labels and included identifiers absent from the pinned vocabulary. The method was revised to preserve category boundaries and to abstain when evidence is thin. That same discipline should apply even more strongly to cryptographic findings: a deterministic rule is still capable of formalising a mistaken premise.
A useful developer-facing explanation could contain four parts: the exact scanner observation; the privacy or security concept it might relate to; the unanswered questions; and one or more actions to investigate. It should link back to the code and identify which steps are assumptions. A privacy specialist can then assess the legal context, while an engineer checks the technical path and available controls.
This is a proposed way of presenting future PrivDev research, not a feature already validated in a working product. The implemented Layer 1 classifies data-type labels. The weakness-to-measure and weakness-to-obligation steps are still research problems. I want to test whether explicit uncertainty makes the eventual guidance more useful, rather than simply less confident in tone.
The cryptography example keeps the goal concrete. A scanner can tell us where to look. A vocabulary can help describe the concern. Choosing a protection measure requires the system’s actual context and an accountable decision.