Float contributions value in private aggregation API

[mehdisebbar]

Request:

We propose allowing contributions of float values (including negative ones) to contributeToHistogramOnEvent with a sensitivity of 2^16.

Background:

Currently, contributions are limited to integer values up to the L1 bound of 2^16. For specific use cases such as encoding gradients (for noised gradient descent methods), we need to encode decimal values that can be negative. The current implementation requires positive and negative integers values to be contributed separately into two different buckets, which doubles the privacy cost. Since the Laplace distribution considers the L1 norm (the sum of absolute values), the limitation to non-negative integers is unnecessary from a differential privacy perspective.

[alexmturner]

Hi @mehdisebbar, thanks for the feedback! Some initial thoughts below.

For allowing negative values, totally agree that theoretically we should be able to support this. As you point out, we would still need to use up (positive) budget for those contributions. (Also note some similar previous feedback here.) This would require some changes to the report format and processing on the Aggregation Service, however.

For allowing non-integer values, we originally chose 2^16 as we believed that it would have sufficient granularity, especially given the scale of noise added on the server. To quickly comment on privacy, I do agree that for simple flows, floats should be fine privacy-wise; however, there are some more complex flows in the future that could depend on the quantization here, e.g. choosing a threshold for key discovery.

A switch to floats would be a pretty big change in the flow, so we'd need to consider that carefully. Another option for more granularity could be to choose a larger L1 limit (and increase the server-side noise proportionally). What level of granularity do you think you would need for your use case here? (Keeping in mind the magnitude of noise the server adds.)

cc @csharrison

[ajvelasquez-privacy-sandbox]

@mehdisebbar would you kindly give us a bit more of the context? Is your encoding gradient use case for Private Aggregation a bidding optimization flow? If not, is it something else?

[mehdisebbar]

Hi, thank you for your answers and sorry for the late reply,

@alexmturner
The ability to contribute negative values without needing a specific key, and thus halving the budget, seems indeed necessary.
Regarding your proposal to increase the L1 budget, we will conduct benchmarks on our end to determine if this approach aligns with our learning objectives compared to using floats directly. We will get back to you with results soon.

@ajvelasquez-privacy-sandbox
We are indeed investigating Private Aggregation for learning models, and one method involves encoding gradients. Therefore, the ability to handle negative float values is necessary for this use case.