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
In reviewing the source code, it is not clear which variables refer to private data and which refer to privitized data. I suggest that you clearly distinguish these in the source code, perhaps by using different variable naming conventions.
The text was updated successfully, but these errors were encountered:
The same naming convention is used for private, confidential variables, and privitized variables that have had noise added. This makes it harder to read and audit the code. For example, in this line:
void AddEntry(const T& t) override {
Is t a confidential value or a non-confidential value?
How about here:
base::StatusOr<Output> GenerateResult(double privacy_budget) override {
DCHECK_GT(privacy_budget, 0.0)
<< "Privacy budget should be greater than zero.";
if (privacy_budget == 0.0) return Output();
Output output;
double sum = 0;
double remaining_budget = privacy_budget;
Is the value privacy_budget confidential or public? It's probably epsilon, so it's probably public, but I can't tell that from the naming convention.
Interesting suggestion. We haven't given much thought to this sort of style/convention, but I can see how it would be useful. Do you know if there are any existing examples of this sort of convention in differential privacy code? We can come up with our own, but I'd like to avoid proliferating standards for this, if possible.
In reviewing the source code, it is not clear which variables refer to private data and which refer to privitized data. I suggest that you clearly distinguish these in the source code, perhaps by using different variable naming conventions.
The text was updated successfully, but these errors were encountered: