Overview
This series asks whether fine-grained filters isolate private data or only remove it from the final response. It examines PostgreSQL timing and Elasticsearch/OpenSearch scoring under studied conditions, then connects application-policy extraction with Ote to proposed database-resident m-NGAC enforcement. The practical test follows the query surface, shared computation, policy state, and observable signals, distinguishing structural separation from controls that merely reduce measurement.
Learning outcomes
- A filtered result does not prove that protected data was absent from the computation.
- PostgreSQL timing and Elasticsearch/OpenSearch scores can expose hidden matches under studied conditions.
- Ranges, prefixes, and conjunctions can amplify a small signal into reconstruction when the interface and workload permit it.
- Ote can improve application-policy visibility, while m-NGAC targets enforcement coverage; neither alone proves computation isolation.
- Controls that remove private data from the relevant path support a stronger claim than noise, rate limits, or interface restriction.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Does filtering a result isolate private data?
No. Filtering controls what crosses the result boundary, but private data may still affect timing, scores, errors, counts, or other observable computation unless the access path is evaluated for that dependency.
How can PostgreSQL row-level security reveal hidden rows?
PostgreSQL RLS can expose whether a predicate matched a hidden row when an optimizer-pushed, indexed condition changes the amount of later policy work and the timing is measurable. Range predicates and conjunctions can amplify the signal under suitable conditions.
How can Elasticsearch and OpenSearch document security expose hidden terms?
DLS can leave hidden documents in corpus statistics or prefix-expansion sets, allowing a visible document’s score to reveal term or prefix support. The demonstrated recovery depends on score visibility, query and index configuration, caller capabilities, and stable corpus conditions.
Do Ote or m-NGAC prove that an application is isolated?
No. Ote makes observed application queries and conditions reviewable within bounded coverage, while m-NGAC proposes database-resident enforcement across clients. Neither alone proves that hidden data cannot affect timing, scores, errors, policy state, or other observables.