Skip to content

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.

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.

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

  1. Identify protected sources and observer-visible sinks.
  2. Define the security domains and allowed-flow order.
  3. Choose program semantics and observations in scope.
  4. Track explicit and control-dependent influence.
  5. Model relevant side channels or state exclusions.
  6. State noninterference or a quantitative leakage metric.
  7. Verify the program statically, dynamically, or formally.
  8. 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

Local relationship map for Information Flow (Information-Flow Security)Parents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Information Flow (In…DOMAINPrime abstraction: Flow — is a kind ofFlowPRIME

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 (91st 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