PATTERN Cited by 1 source

Runtime information flow enforcement

Pattern

Enforce privacy/security constraints as data flows through code at runtime — not at rest via ACLs, not via post-hoc audits. At every transfer (function call, return value, SQL join, cross-service request), the runtime:

1. Reads the source annotation (e.g. BANANA_DATA).
2. Reads or infers the destination annotation.
3. Consults the policy lattice to decide whether the flow is compatible with the source's rules.
4. Blocks non-compatible flows (or records them as violations in logging mode; see patterns/logging-mode-to-enforcement-mode-rollout).

The canonical industrial instance on this wiki is Meta's Policy Zones, used to enforce purpose limitation across HHVM, Presto, and Spark.

When to use

• Many systems, many requirements, evolving policy. The failure mode of point-checking + ACLs is compounding audit cost as (systems × requirements) grows; IFC collapses the cost because the runtime does the check, not a human.
• Shared infrastructure where physical data separation is too expensive. Point-checking forces separate tables/caches per purpose; runtime IFC lets one table serve many purposes with per-request label-checking.
• Cross-system data flows. When data moves frontend → warehouse → AI, ACLs can't follow it; annotations propagate naturally through IFC-aware systems.

Mechanics

From the 2024-08-31 Meta PAI post:

• Annotate sources: tag data assets with metadata labels at the appropriate granularity (table/column/row or parameter/variable/return value).
• Annotate sinks explicitly or inherit via zones: a request or query that loads annotated data becomes a zone whose entire call tree / query plan inherits the annotation.
• Check every transfer: the runtime consults flow rules and blocks or permits.
• Separate language-level features to propagate the context natively — language/runtime modifications (in Hack, C++, Python at Meta) keep the context flowing through function calls cheaply.
• Performance engineering the lattice: Meta reports "10x improvements in computational efficiency" through lattice simplification + canonicalized annotation structures.

Trade-offs

• Runtime overhead: every data flow is checked. Meta publicly reports only a relative 10× improvement, no absolute overhead.
• Annotation coverage: requires initial + ongoing investment to annotate all relevant data assets across a large codebase (Meta's ML-based classifier is the Meta-scale automation input).
• Gradual adoption: not all systems can ship IFC overnight. Meta retains point-checking as a bridge for systems not yet integrated with Policy Zones. Plan for multi-year rollout.
• Policy composition: monolithic annotation APIs break under multi-requirement composition → adopt patterns/separate-annotation-from-requirement from day one.

Seen in

• sources/2024-08-31-meta-enforces-purpose-limitation-via-privacy-aware-infrastructure — canonical surfacing on this wiki; Policy Zones is the industrial-scale IFC system Meta built over multiple years to replace point-checking + lineage for purpose-limitation enforcement.

Related

• concepts/information-flow-control — the primitive.
• concepts/purpose-limitation — the canonical Meta use case.
• concepts/data-annotation — the label primitive.
• concepts/data-flow-violation — what the runtime detects.
• concepts/policy-lattice — the formal structure for flow rules.
• systems/meta-policy-zones — the canonical system.
• systems/meta-privacy-aware-infrastructure — the umbrella.
• patterns/logging-mode-to-enforcement-mode-rollout — the rollout companion pattern.
• patterns/separate-annotation-from-requirement — the annotation-schema companion pattern.
• companies/meta