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: v2 · 2026-09-06 · History
Domain-specific #: 2063
Origin domain: computer science
Subdomain: information flow security
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.^[1]

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.

Structural Signature¶

The information sources. Variables or events carry protected or trusted content.
The observable sinks. A declared observer can inspect selected outputs or behaviors.
The security lattice or policy. Allowed flows are ordered across labels and compartments.
The program/process semantics. Executions define how sources can influence sinks.
The explicit channels. Direct data assignments propagate labeled content.
The implicit channels. Branches and control dependence encode information in values or behavior.
The covert/side channels. Timing, termination, resource use, or shared state expose additional signals.
The security property. Noninterference, bounded leakage, or another criterion evaluates dependence.
The release mechanism. Declassification or endorsement permits scoped policy exceptions.
The adversary model. Prior knowledge and observable resolution delimit quantitative claims.

What It Is Not¶

Not ordinary data movement alone. Statistical or semantic dependence can flow without copying bytes.
Not access control. Access checks who may read an object; flow control constrains downstream influence after access.
Not encryption by itself. Decrypted data can propagate through untrusted outputs.
Not synonymous with Shannon channel capacity. Security adds labels, policies, programs, and adversary observations.
Not only explicit assignment tracking. Control, timing, and termination can leak.
Not necessarily zero leakage. Quantitative systems and explicit declassification can permit bounded flow.

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.

State the security domains, the protected source information, the observer's allowed outputs, the execution model, and the policy being tested. A flow claim is relative to what the observer can distinguish; changing timing, termination, exceptions, resource use, or declassification can change the answer. Explicit assignment is only one channel. Branch conditions, array indices, control termination, shared resources, and probabilistic behavior can make low observations depend on high information without direct copying. Noninterference formulations should specify whether they are termination-sensitive, probabilistic, quantitative, or conditioned on an authorized release. Access control governs permitted operations on objects, whereas information-flow control constrains dependence across executions. Testing selected examples cannot establish a universal semantic property unless the analysis method soundly covers the declared program model.^[1]

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.

The abstraction replaces a potentially enormous set of execution traces with a policy over sources, sinks, and permitted dependencies. Static type systems, program analyses, dynamic labels, and quantitative measures are different mechanisms for approximating or enforcing that policy. Their trade-offs become legible when separated into soundness, precision, termination treatment, concurrency, covert channels, and declassification. A conservative analysis may reject a secure program because it cannot prove independence; a permissive monitor may miss a channel outside its observation model. Complexity is therefore managed by declaring the attacker or observer model and by preserving the distinction between an actual semantic flow and a tool's approximation. Composition also matters: two components that satisfy local policies can leak through their interaction if shared state or scheduling introduces a new dependency.

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. Data lineage may record where values were copied without proving that unrecorded control dependence is absent. Causal influence is a neighbor, but security policies can use epistemic indistinguishability or quantitative leakage rather than interventionist causation. Transfer is literal when the mapping preserves sources, observations, transformations, and a dependency policy; otherwise flow is only a metaphor.

Examples¶

Canonical¶

A program reads a secret bit h and sets public l through an if-statement. Even if h is never assigned directly to l, the final public value depends on h, so two runs differing only in h become distinguishable. A noninterference analysis identifies this implicit high-to-low flow.^[1]

Mapped back: secret source → control dependence → public output → distinguishable executions → policy violation.

Applied / In Practice¶

A service labels tenant data high and aggregate metrics releasable only after an approved declassification. Static analysis covers explicit and implicit dependencies; separate tests evaluate timing leakage from cache and response paths. The assurance statement lists the channels proved, quantified, and excluded rather than claiming generic security.

A service returns a public status message after consulting a confidential account flag. No confidential value is assigned to the response, but the branch selects between two public strings. Analysts define low-equivalent initial states that differ only in the flag and observe that their outputs differ, demonstrating an implicit flow. A revised service always returns the same public string and records the confidential distinction only in an authorized high channel. Review then expands the observation model to timing and error behavior; equal text alone is insufficient if response delay still reveals the branch. An explicit declassification rule can permit a narrowly defined release, but it must identify what, to whom, and under which condition. This trace-pair reasoning separates information dependence from mere read permission.

Mapped back: labeled sources → program dependencies → scoped declassification → multi-channel verification → bounded guarantee.

Structural Tensions¶

Strong noninterference vs. useful release. Zero flow can make systems unusable. Diagnostic: Is every declassification purpose-bound and reviewable?
Semantic completeness vs. tractability. Rich channel models are realistic but hard to analyze. Diagnostic: Which observations are excluded?
Qualitative absence vs. quantitative smallness. A tiny leak violates noninterference yet may be operationally bounded. Diagnostic: Which security objective and metric applies?
Static precision vs. soundness. Conservative analyses reject secure programs; permissive ones miss flows. Diagnostic: What false-positive/negative contract is claimed?
Autonomous security construct vs. generic flow. Flow travels; labels and observer dependence define information-flow security. Diagnostic: Is propagation evaluated against a security policy?

Structural–Framed Character¶

Information flow is mixed. Program dependence and information measures are structural; secrecy labels, authorized observers, release purposes, and threat models are institutional and evaluative. The same execution can be secure under one policy and insecure under another. Flow supplies the portable skeleton; security semantics keep the entry domain-specific.

Policy composition supplies a decisive diagnostic. A component that releases one authorized summary and another that releases a different summary can jointly disclose more than either policy intended. Review therefore tracks release budgets and correlations across outputs, not only each statement in isolation. Concurrency introduces analogous problems through scheduling and shared caches. No single enforcement technique covers every physical or microarchitectural channel, so the claimed observation model must remain explicit. The abstraction is still useful under a bounded model: it makes that boundary auditable and distinguishes a proved nondependence claim from a vague assertion that confidential data were never printed directly.

Structural Core vs. Domain Accent¶

The skeleton is source → dependency/channel → sink/observer → allowed-or-forbidden flow. The accent is security lattices, noninterference, program semantics, side channels, adversary priors, and declassification. Removing them yields generic information flow.

Flow is the strict parent because the construct tracks structured movement of information from sources through program channels to observations. Data Leakage is a possible prohibited instance, not the neutral parent.

The prospective workspace queue contains one strict upward edge to prime:flow. No live DAG mutation is authorized.

Relationships to Other Abstractions¶

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

Parents (1) — more general patterns this builds on

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) → Flow

Neighborhood in Abstraction Space¶

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

Family — Application Security & Adversarial Input (9 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Access control. Restricts initial object access rather than later propagation.
Data leakage. A prohibited disclosure outcome, not the full flow-analysis framework.
Taint analysis. A common dependency-tracking technique that may not establish semantic noninterference.
Shannon information flow. Quantitative dependence without necessarily carrying security labels or policy.
Covert channel. A specific unintended communication path within the broader analysis.

References¶

[1] Andrei Sabelfeld and Andrew C. Myers, ‘Language-Based Information-Flow Security,’ IEEE Journal on Selected Areas in Communications 21, no. 1 (2003): 5–19, https://doi.org/10.1109/JSAC.2002.806121. registry ↩a ↩b ↩c