You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our design requires that we communicate the sensitivity and budget expenditure that every contribution makes. The aggregation service needs to take that information and use that in applying DP noise. There are a few ways to slice this, but my suggestion would be:
Each task is configured with a preset sensitivity ($\Delta$) and budget ($\epsilon$).
Each submission is bound to these values. We can use the additional authenticated data (AAD) component of the AEAD we use for encryption, so that the values -- which are public -- don't need to be decrypted and therefore don't need to be resubmitted with every submission. That will save a lot of overhead for batched submissions.
A submission is invalid unless the sensitivity is less than or equal to the configured sensitivity of the query. Ideally, the values would be the same, which might simplify things. However, queries will likely need some way to vary metadata for individual submissions, so this might not result in a genuine simplification of the protocol. We should probably start with the simple approach, though there is no technical or privacy reason that a smaller sensitivity wouldn't work. Using a smaller sensitivity is going to result in greater noise relative to that contribution, but the smaller sensitivity will reduce the size of the submission, which could be well worth the modest increase in complexity.
A submission is invalid unless the privacy budget expended is greater than or equal to the privacy budget of the query. Again, it would be ideal of the values were the same, with similar effect to that of having a lower sensitivity.
The aggregation service would apply noise based on the configured sensitivity and budget.
Extensions to the DAP protocol will be needed to communicate these values.
The text was updated successfully, but these errors were encountered:
Our design requires that we communicate the sensitivity and budget expenditure that every contribution makes. The aggregation service needs to take that information and use that in applying DP noise. There are a few ways to slice this, but my suggestion would be:
Extensions to the DAP protocol will be needed to communicate these values.
The text was updated successfully, but these errors were encountered: