Spec basic privacy budgeting #79
Conversation
Co-authored-by: Andrew Paseltiner <[email protected]>
There was a problem hiding this comment.
I'm not 100% sure about putting all this gory detail in that section, rather than pushing it down the document. Having it further down (in the privacy budgeting section) might ensure that the explanatory text in the document doesn't grow impenetrable algorithmic stuff. These algorithms are pretty reader-hostile (even if this one is pretty clear to me).
Otherwise, this seems solid.
| 1. Let |currentValue| be the result of [=map/get|getting the value=] of |key| | ||
| in the [=privacy budget store=]. | ||
|
|
||
| 1. If |currentValue| is less than or equal to 0, return false. |
There was a problem hiding this comment.
Do we need this step? From the outside, the algorithm doesn't change if you remove this line.
There was a problem hiding this comment.
I am open to removing it. The reason why I added this line was to avoid having to subtract budget from an exhausted epoch. It felt a little weird mutating a key's value in that state.
Heh I thought this was the part of the spec that was supposed to be gory :) . TBH I don't have a full picture of how we want the spec to be organized. It seems the latter sections are less algorithm-y and more like non-normative sections. |
This PR adds basic privacy budgeting, without getting into the safety limit budgeting (which I still need to think about).
cc #77 . This PR still uses floating point budgeting which is the simplest approach until we resolve that issue.