Information Flow (Information-Flow Security)¶

Track whether observations in one security domain can depend on information from another, enforcing a policy over explicit, implicit, and indirect program channels rather than only access to stored objects.

Version: v3 · 2026-09-19 · History
Domain-specific #: 2063
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Information Flow Security → Computer Science & Software Engineering
Aliases: Information-flow security, Secure information flow

Core Idea¶

Information-flow security asks whether changing a protected input can change what a less-authorized observer can see through a system execution. Labels or security domains are ordered by a policy—often a lattice—and program semantics are checked so information moves only along permitted directions. Confidentiality commonly forbids high-to-low dependence; integrity policies can reverse or dualize the order.

The analysis goes beyond direct assignment. Control flow, termination, timing, resource use, exceptions, and shared state can carry information even when no secret value is copied explicitly. Noninterference gives a qualitative indistinguishability condition; quantitative information flow measures how much is leaked under a prior and observation model. Declassification deliberately permits bounded release and must be part of the policy, not treated as a violation hidden in code.

How would you explain it like I'm…

Secrets Stay Secret

Imagine a computer keeps a secret, and a stranger is watching it. Information flow security checks that changing the secret never changes anything the stranger can see. That even includes sneaky hints, like the computer taking longer or stopping early. If the stranger can't spot any difference, the secret is safe.

No Sneaky Secret Leaks

Information flow security asks one question: if you changed a secret inside a program, could someone without permission notice any difference? Data gets labels like 'secret' or 'public,' and rules say which way information is allowed to move. Usually secret information must not leak into public outputs. Leaks can be sneaky, like a program taking longer or crashing only when the secret has a certain value. Sometimes revealing a little on purpose is allowed, but only if the rules say so.

Noninterference and Leak Control

Information-flow security asks whether changing a protected input can change what a less-authorized observer sees when a system runs. Data carries security labels ordered by a policy, often a lattice, and the program is checked so information only moves in allowed directions. For confidentiality, high (secret) data must not influence low (public) outputs. Integrity policies flip or mirror that ordering, so untrusted data must not affect trusted data. The analysis goes beyond direct copying, because branches, loops that may never end, timing, exceptions, and shared state can all leak. Noninterference is the yes-or-no condition that the observer cannot tell different secrets apart. Quantitative information flow instead measures how much leaks. Intentional releases, called declassification, have to be written into the policy rather than hidden in code.

Information-flow security asks whether varying a protected input can change what a less-privileged observer can see of a system's execution. Security labels or domains are partially ordered by a policy, commonly a lattice, and the program's semantics are checked, for instance by type systems or other static or dynamic analyses, so that flows respect the order. Confidentiality forbids high-to-low dependence. Integrity uses a dual or reversed ordering to keep low-integrity inputs from influencing high-integrity results. Explicit flows through assignment are only part of the picture. Implicit flows through control dependence, along with termination, timing, resource consumption, exceptions, and shared state, are covert or side channels that must also be addressed. Noninterference states the qualitative goal: executions that differ only in high inputs are indistinguishable to the low observer. Quantitative information flow relaxes this by measuring leakage relative to a prior and an observation model. Declassification permits bounded, intentional release and must be specified in the policy, not smuggled in as an unacknowledged violation.

Scope of Application¶

The construct is literal in software and system security wherever source-to-observation dependence is compared with a declared policy.

Language-based security. Type systems and semantics enforcing noninterference.
Static program analysis. Tracking explicit and implicit dependencies.
Dynamic information-flow control. Propagating labels during execution.
Database and query systems. Controlling inference and release across compartments.
Side-channel analysis. Modeling timing, cache, termination, and resource observations.
Quantitative leakage. Estimating mutual information, min-entropy loss, or channel capacity under an adversary model.
Declassification design. Specifying what, who, where, and when release is allowed.

Clarity¶

Name sources, sinks, labels, policy order, observer, semantic equivalence, channels in scope, and whether the property is qualitative or quantitative. For quantitative claims, state prior, leakage measure, and observation resolution. Define declassification explicitly and distinguish confidentiality from integrity. A proof that ignores timing must not be described as timing-safe.

Manages Complexity¶

Information-flow analysis replaces an unbounded set of attack narratives with a dependence property over executions and composes local labels into a system-wide policy. It reveals leaks that object-level permissions miss. The guarantee is only as broad as the semantic and observer model; excluded timing or termination channels become a precise residual, not evidence of total confidentiality.

Abstract Reasoning¶

Identify protected sources and observer-visible sinks.
Define the security domains and allowed-flow order.
Choose program semantics and observations in scope.
Track explicit and control-dependent influence.
Model relevant side channels or state exclusions.
State noninterference or a quantitative leakage metric.
Verify the program statically, dynamically, or formally.
Audit declassification and residual channels against the threat model.

Knowledge Transfer¶

The strict parent is Flow: information moves through structured dependencies and channels from sources to sinks. Data Leakage is a failure outcome and Information Use License governs permitted use, but neither captures the neutral analysis of allowed and forbidden propagation.

Flow is the strict parent because information is modeled as propagating from sources through computations to observations under constraints. The transferable skeleton is typed or classified source -> transformation path -> observable sink -> admissibility policy. The information-security residue is that flow denotes dependence, including implicit and indirect channels, rather than physical movement or possession.

Relationships to Other Abstractions¶

Current abstraction Information Flow (Information-Flow Security) Domain-specific

Parents (1) — outgoing typed relations

Information Flow (Information-Flow Security) is a kind of Flow Prime

Flow is the strict parent because the construct tracks structured movement of information from sources through program channels to observations.

Hierarchy path (1) — routes to 1 parentless root

Information Flow (Information-Flow Security) → is a kind of Flow

Neighborhood in Abstraction Space¶

Information Flow (Information-Flow Security) sits in a sparse region of the domain-specific corpus (93^rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25