Problem
The scalable pipeline numerical derivation path appears to derive exact lower and upper bounds from sensitive data before running DP quantile computation.
In dpsynth/pipeline_transformations/numerical_values_derivation.py, derive_numerical_attributes() computes:
pipeline_functions.min_max_per_key(...)domain.NumericalAttribute(min_value=min_max[0], max_value=min_max[1])
Those exact bounds are then used to normalize values before dp_engine.aggregate(...) computes DP percentiles and to denormalize the returned quantiles.
Why this matters
The DP quantile aggregation protects the percentile outputs, but exact min/max values are data-dependent releases. If the bounds are not public, releasing or using them as part of the output descriptor leaks sensitive extrema outside the DP mechanism.
The documentation also describes this stage as privately deriving domain boundaries / privately computing quantiles, which can lead callers to believe automatic numerical metadata population is fully DP.
Local evidence
Reviewed at commit 18c2c951bd2923f889f6e3b2b757e01aaae398ee.
Relevant lines in the current tree:
dpsynth/pipeline_transformations/numerical_values_derivation.py: min_max = pipeline_functions.min_max_per_key(...)dpsynth/pipeline_transformations/numerical_values_derivation.py: min_value=min_max[0], max_value=min_max[1]docs/processing_lifecycle.md: says DPSynth must privately deduce domain boundariesdocs/data_and_terminology.md: says the population phase privately computes numerical quantiles
Possible fix
Require numerical bounds to be public metadata supplied by the caller, then compute only the quantile cut points under DP within those public bounds. If automatic private bound discovery is desired later, it should use a separately accounted DP mechanism.
Draft PR
I opened a draft fix here: #30
Problem
The scalable pipeline numerical derivation path appears to derive exact lower and upper bounds from sensitive data before running DP quantile computation.
In
dpsynth/pipeline_transformations/numerical_values_derivation.py,derive_numerical_attributes()computes:pipeline_functions.min_max_per_key(...)domain.NumericalAttribute(min_value=min_max[0], max_value=min_max[1])Those exact bounds are then used to normalize values before
dp_engine.aggregate(...)computes DP percentiles and to denormalize the returned quantiles.Why this matters
The DP quantile aggregation protects the percentile outputs, but exact min/max values are data-dependent releases. If the bounds are not public, releasing or using them as part of the output descriptor leaks sensitive extrema outside the DP mechanism.
The documentation also describes this stage as privately deriving domain boundaries / privately computing quantiles, which can lead callers to believe automatic numerical metadata population is fully DP.
Local evidence
Reviewed at commit
18c2c951bd2923f889f6e3b2b757e01aaae398ee.Relevant lines in the current tree:
dpsynth/pipeline_transformations/numerical_values_derivation.py:min_max = pipeline_functions.min_max_per_key(...)dpsynth/pipeline_transformations/numerical_values_derivation.py:min_value=min_max[0], max_value=min_max[1]docs/processing_lifecycle.md: says DPSynth must privately deduce domain boundariesdocs/data_and_terminology.md: says the population phase privately computes numerical quantilesPossible fix
Require numerical bounds to be public metadata supplied by the caller, then compute only the quantile cut points under DP within those public bounds. If automatic private bound discovery is desired later, it should use a separately accounted DP mechanism.
Draft PR
I opened a draft fix here: #30