Monday Session IV, Plaza A
2023 July 24, 17:30 - 18:30 PDT
San Francisco, California, USA
Chairs: Sam Weiler, Ben Schwartz
Area Director: Roman Danyliw
What's new in DAP-05 - Geoghegan (5 min)
Differential privacy for DAP - Patton (15 min)
Do we need multiple query modes? - Geoghegan (15 min)
Report Authentication Extension for DAP - Priebe (10 min)
Martin: I think this will be scoped to DAP and VDAF. We don't
deliver on our charter unless some of this is available. This is one
of the most important parts of the protocol we're building here.
[Martin supports this being in PPM.]
EKR: This should not be on the critical path for publishing DAP.
Chris P: Local DP is a property you get when things fall apart.
Local DP is not a replacement for DAP.
Martin: if we're doing central DP, we should have each aggregator
add noise, which has implications if an aggegrator is malicious. I'm
keen on having more than one method.
Watson Ladd: I want to see this here.
Tim G: Do the concrete bits here. Maybe guidance elsewhere. I think
DAP shouldn't say anything about local DP - it can be applied
orthogonally to Prio.
Shan Wang: local DP alone is not very useful. But coupled with
aggregation, could be useful.
Tim: this is the first time we've broached this, so I'm not looking
for a decision today. I'd like to hear objections, though.
EKR: this is incredibly seasonal, so fixed size won't work.
Martin: I like the idea of polling. Fixed time interval has
problems. Can't you just ask for what's there now, e.g. ask every
hour? It's not then time intervals - it would be variable sized
batching. Bias toward including data in later reports rather than
lose data. Maybe you have a "disregard older than X" option?
Kate Hudson: what if you want to compare simultaneous time periods?
e.g. exactly over a week, count for two different groups.
Seasonality use case is interesting.
Chris P: the intention of query types is to allow different ways of
slicing data. We're asking about constraining them in-band. Give
collector some control over data. I support this because it
simplifies - I don't think we need it.
EKR: the orphaned request comes in two flavors: many systems (e.g.
Firefox) do not trigger on timestamp in messasge but instead on
arrival time. The problem you're describing only appears with small
number of users/reports.
Tim: my take-aways are to think more about seasonality and whether
orphaned reports are really a problem.
Chris P: could we have an interim on this?
Tim: we should do more work first.
EKR: why do we need to change DAP?
Christian: client doesn't directly talk to helper.
EKR: the threat model doesn't include leader or helper lying.
Watson Ladd: similar question: in the PPM threat model, we trust the
leader and helper to assemble resutls - we don't necessarily trust
the leader and helper to preserve privacy. If we change threat
model, have to change other things, also.
Linmao: this doesn't solve for Sybil attacks - client sending many
reports.
Tanya Verma: the reuse of token problem is not just an optimization
Linmao: we're trying to prevent attacks on privacy pass
infrastructure.
Chris P: We're proposing a WG draft to mitigate Sybil attacks
without modifying threat model. This draft is a good starting point
Tim: in this scheme, the helper will extract the token and verify
it. Where does the helper get the public key to verify the token?
Linmao: out of band. Contact issuer via a public directory.
Tim: so a task parameter might be a URL for validation?