[{"author": "Shan Wang", "text": "

Good morning everyone

", "time": "2023-11-07T12:03:38Z"}, {"author": "Tim Geoghegan", "text": "

Yes

", "time": "2023-11-07T12:05:40Z"}, {"author": "Junye Chen", "text": "

Question: as a speaker, should I join from the onsite tool, or as a full client with video?

", "time": "2023-11-07T12:07:48Z"}, {"author": "Samuel Weiler", "text": "

You're remote, yes?

", "time": "2023-11-07T12:08:15Z"}, {"author": "Samuel Weiler", "text": "

if so, use the full client.

", "time": "2023-11-07T12:08:29Z"}, {"author": "Junye Chen", "text": "

Yes. Ok, I will use the full client.

", "time": "2023-11-07T12:09:40Z"}, {"author": "Tim Geoghegan", "text": "

The other thing is that you may end up with label combinations that have a very small set of clients reporting, too few to meet the min batch size, so you never get to collect those reports.

", "time": "2023-11-07T12:24:41Z"}, {"author": "Tim Geoghegan", "text": "

*The other thing _about creating a whole bunch of tasks_

", "time": "2023-11-07T12:25:09Z"}, {"author": "Jonathan Hoyland", "text": "

But not filling in labels is, in itself, a fingerprintable attribute, no?

", "time": "2023-11-07T12:26:03Z"}, {"author": "Shan Wang", "text": "

Tim, if there are set of clients that are labelled by combinations, then shouldn't we avoid collecting their data

", "time": "2023-11-07T12:28:16Z"}, {"author": "Nick Doty", "text": "

if there's no difference, then what's the advantage?

", "time": "2023-11-07T12:33:12Z"}, {"author": "Tim Geoghegan", "text": "

If you simulate labels with tasks created up front, then you never get to aggregate reports for tasks with too few contributions.

", "time": "2023-11-07T12:33:37Z"}, {"author": "Tim Geoghegan", "text": "

If you do labels, you could try a specific query involving some label combo, get told \"nope, not enough reports\", and then try again with a less specific query until you get enough reports in the batch.

", "time": "2023-11-07T12:34:14Z"}, {"author": "Nick Doty", "text": "

the issue specifically suggests a preference for labels so that queries don't have to be pre-created

", "time": "2023-11-07T12:35:11Z"}, {"author": "Christopher Wood", "text": "

I disagree with Kunal here, to be clear.

", "time": "2023-11-07T12:35:56Z"}, {"author": "Christopher Wood", "text": "

Someone should just make a PR for this.

", "time": "2023-11-07T12:36:02Z"}, {"author": "Kyle Hogan", "text": "

is there a short answer for what the difference is between \"labels\" and \"tasks\" here?

", "time": "2023-11-07T12:36:51Z"}, {"author": "Jonathan Hoyland", "text": "

My question is, does combining labels make stuff different, because different tasks are not bound together?

", "time": "2023-11-07T12:36:56Z"}, {"author": "Christopher Wood", "text": "

@Shan what are the attacks?

", "time": "2023-11-07T12:37:17Z"}, {"author": "Benjamin Schwartz", "text": "

I think there's some disagreement over the query language that would be available over labels. Some folks anticipate only \"exact match\", others anticipate \"subset match\".

", "time": "2023-11-07T12:39:54Z"}, {"author": "Tim Geoghegan", "text": "

@Kyle Hogan the idea is that each task would define a set of labels for which clients could provide values. That's as short as I can make it. The long version is https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/489.

", "time": "2023-11-07T12:40:03Z"}, {"author": "Benjamin Schwartz", "text": "

\"Exact match only\" reproduces the behavior of independent tasks. Partial match query languages have different privacy properties.

", "time": "2023-11-07T12:41:10Z"}, {"author": "Nick Doty", "text": "

the title of the issue in github is different than the title on the slide

", "time": "2023-11-07T12:42:40Z"}, {"author": "Jonathan Hoyland", "text": "

Is it a requirement that the client knows what the parameters are?

", "time": "2023-11-07T12:43:42Z"}, {"author": "Tim Geoghegan", "text": "

Only a subset of the parameters.

", "time": "2023-11-07T12:43:52Z"}, {"author": "Tim Geoghegan", "text": "

The client needs to know e.g. what VDAF is in use, but it doesn't need to know what the batch size is

", "time": "2023-11-07T12:44:38Z"}, {"author": "Nick Doty", "text": "

transparency of the measurement parameters to the user seems very valuable. no preference on how to accomplish it.

", "time": "2023-11-07T12:47:10Z"}, {"author": "Christopher Wood", "text": "

Something like (1) and (2) would be this

", "time": "2023-11-07T12:47:23Z"}, {"author": "Jonathan Hoyland", "text": "

What if I don't understand the extension, and just see an opaque key ID?

", "time": "2023-11-07T12:51:02Z"}, {"author": "Tim Geoghegan", "text": "

DAP requires partcipants to bail out if they don't recognize an extension

", "time": "2023-11-07T12:51:28Z"}, {"author": "Shan Wang", "text": "

@Jonathan, the aggregator must abort if the extension is not recognised

", "time": "2023-11-07T13:02:53Z"}, {"author": "Benjamin Schwartz", "text": "

This doesn't look like a deviation: https://datatracker.ietf.org/doc/html/rfc8446#:~:text=suite%20selector%20*/%0A%0A%20%20%20%20%20%20struct%20%7B-,ProtocolVersion%20legacy_version%20%3D%200x0303%3B%20%20%20%20/*%20TLS%20v1.2%20*/,-Random%20random%3B%0A%20%20%20%20%20%20%20%20%20%20opaque

", "time": "2023-11-07T13:05:46Z"}, {"author": "Jonathan Hoyland", "text": "

Not complying with TLS syntax makes me sad :disappointed:

", "time": "2023-11-07T13:06:07Z"}, {"author": "Jonathan Hoyland", "text": "

I like Chris Wood's suggestion

", "time": "2023-11-07T13:07:08Z"}, {"author": "Shan Wang", "text": "

As an implementor, I found RFC8446 is a bit hard to use (apart from wire encoding)

", "time": "2023-11-07T13:09:21Z"}, {"author": "Samuel Weiler", "text": "

Junye, do you want to share and control your own slides?

", "time": "2023-11-07T13:10:29Z"}, {"author": "Simon Friedberger", "text": "

@Christopher Wood and presumably the current format with fixed sizes could also be encoded with the quic syntax, right?

", "time": "2023-11-07T13:10:38Z"}, {"author": "Samuel Weiler", "text": "

or have Ben do it for you?

", "time": "2023-11-07T13:10:41Z"}, {"author": "Tim Geoghegan", "text": "

@Benjamin Schwartz In TLS 1.3 that notation indicates a field in a struct that has exactly one legal value. In DAP we use that notation to illustrate constructing values of a struct in a particular case, but there's >1 legal value for the field.

", "time": "2023-11-07T13:13:07Z"}, {"author": "Christopher Wood", "text": "

@Simon yep

", "time": "2023-11-07T13:17:44Z"}, {"author": "Nick Doty", "text": "

dishonest clients can disrupt privacy of the honest client and accuracy of the aggregate value

", "time": "2023-11-07T13:24:11Z"}, {"author": "Nick Doty", "text": "

(if most clients are dishonest, there is no way to get an accurate measurement)

", "time": "2023-11-07T13:25:01Z"}, {"author": "Kunal Talwar", "text": "

Dishonest clients can impact the utility and the privacy. Here we are concerned primarily with the privacy aspect. The utility aspects are addressed by the verfication of contributions. E.g. for histograms, we can verify that each client contributes a 0-1 vector with at most one 1 in it. This would imply that K dishonest clients can create an error of K in the final histogram.

", "time": "2023-11-07T13:27:00Z"}, {"author": "Nick Doty", "text": "

is this a normative specification? or just some documentation/recipes for someone who wanted to do differential privacy with dap?

", "time": "2023-11-07T13:36:03Z"}, {"author": "Christopher Patton", "text": "

@Nick Doty I think this draft is informative, not normative.

", "time": "2023-11-07T13:37:25Z"}, {"author": "Christopher Wood", "text": "

Tim said what I wanted to say

", "time": "2023-11-07T13:37:27Z"}, {"author": "Nick Doty", "text": "

if the authors and group are interested in making this standards-track/normative interoperable, that sounds promising, if hard

", "time": "2023-11-07T13:39:25Z"}, {"author": "Martin Thomson", "text": "

FWIW, for DP, the best informational or framework documents come after you build and ship one or more concrete instantiations. I don\u2019t want to block this work, but it is still quite vague and academic.

", "time": "2023-11-07T13:47:14Z"}, {"author": "Tim Geoghegan", "text": "

Yes. Besides informational vs. standards track, I'd like the document to be clear on whether it's a paper for academics or a specification for engineers and implementers. Is it LaTeX or Markdown?

", "time": "2023-11-07T13:48:05Z"}, {"author": "Samuel Weiler", "text": "

whatever happened to nroff?

", "time": "2023-11-07T13:48:41Z"}, {"author": "Benjamin Schwartz", "text": "

For aggregator DP, it seems like a standards-track specification is required in order to configure the DP parameters.

", "time": "2023-11-07T13:49:25Z"}, {"author": "Martin Thomson", "text": "

I am most interested in concrete instantiations, not the abstract stuff. This is also a criticism of DAP, which I firmly believe is too abstracted.

", "time": "2023-11-07T13:51:43Z"}, {"author": "Christopher Wood", "text": "

@Martin by concrete instantiations, do you mean specific DP parameters?

", "time": "2023-11-07T13:53:00Z"}, {"author": "Christopher Patton", "text": "

In what way do you think DAP is too abstract?

", "time": "2023-11-07T13:55:01Z"}, {"author": "Junye Chen", "text": "

@Tim Some of the DP definitions are very theoretical, but once we establish them, I think the implementations of DP mechanisms, derivations of the mechanism parameters, and implementations of DP policies should focus mostly on engineering.

", "time": "2023-11-07T13:56:57Z"}, {"author": "Nick Doty", "text": "

don't those consistency questions also come up with out-of-band configuration? we just have unstandardized ways of distributing the task configurations

", "time": "2023-11-07T14:00:21Z"}, {"author": "Benjamin Schwartz", "text": "

@Nick Doty I think there's a hidden assumption that the client binary is audited, which generally includes consistency.

", "time": "2023-11-07T14:02:09Z"}, {"author": "Benjamin Schwartz", "text": "

@Christopher Patton I think TaskProv requires that the client provisioning happen over an OHTTP-like anonymizer. Otherwise, I can tag individual users and follow them by IP (supercookie).

", "time": "2023-11-07T14:04:27Z"}, {"author": "Christopher Patton", "text": "

but to what end? what does an attacker get to do with that?

", "time": "2023-11-07T14:04:51Z"}, {"author": "Benjamin Schwartz", "text": "

I get to see that my one user in Country A is now in Country B.

", "time": "2023-11-07T14:05:15Z"}, {"author": "Benjamin Schwartz", "text": "

@Christopher Patton I can watch the client IPs of individual users as they wander the network, indefinitely, building up a location history trace.

", "time": "2023-11-07T14:06:50Z"}]