[{"author": "Christopher Patton", "text": "

Morning/evening/afternoon all

", "time": "2022-07-28T14:00:16Z"}, {"author": "Nick Doty", "text": "

good morning! (choosing to reveal timezone to jabber/zulip)

", "time": "2022-07-28T14:01:27Z"}, {"author": "Benjamin Schwartz", "text": "

Thanks all for coming. The chairs are waiting a few more minutes for onsite attendees.

", "time": "2022-07-28T14:01:42Z"}, {"author": "Christian Veenman", "text": "

Goodmorning/Afternoon!

", "time": "2022-07-28T14:01:47Z"}, {"author": "Christopher Patton", "text": "

I have fingerprinted you

", "time": "2022-07-28T14:01:48Z"}, {"author": "Christian Veenman", "text": "

Good morning!

", "time": "2022-07-28T14:02:19Z"}, {"author": "Shivan Sahib", "text": "

Hi all!

", "time": "2022-07-28T14:03:01Z"}, {"author": "Christian Veenman", "text": "

Good morning all

", "time": "2022-07-28T14:03:01Z"}, {"author": "Christopher Patton", "text": "

the mic is really choppy

", "time": "2022-07-28T14:03:54Z"}, {"author": "Christopher Wood", "text": "

We typically bash the agenda prior to starting any presentations. Chairs, why did that not happen?

", "time": "2022-07-28T14:04:50Z"}, {"author": "Christopher Wood", "text": "

That is distinctly unhelpful.

", "time": "2022-07-28T14:05:50Z"}, {"author": "Nick Doty", "text": "

we have a short timeboxed session for the presentation of the new work?

", "time": "2022-07-28T14:06:19Z"}, {"author": "Tim Geoghegan", "text": "

I can hear the room just fine

", "time": "2022-07-28T14:06:26Z"}, {"author": "Nick Doty", "text": "

I can hear fine remotely

", "time": "2022-07-28T14:06:26Z"}, {"author": "Tim Geoghegan", "text": "

And I can hear you quite clearly Christopher Patton

", "time": "2022-07-28T14:06:49Z"}, {"author": "Nick Doty", "text": "

yes, effective anonymizing proxy would be essential here! (and have a risk of collusion between the proxy and the server)

", "time": "2022-07-28T14:10:10Z"}, {"author": "Nat Meysenburg", "text": "

I'm getting very choppy audio (audio in ~8Kps), and no slides.

", "time": "2022-07-28T14:10:23Z"}, {"author": "Christopher Patton", "text": "

I'm back and I can hear great

", "time": "2022-07-28T14:10:26Z"}, {"author": "Christopher Patton", "text": "

(mi wifi is having issues)

", "time": "2022-07-28T14:10:46Z"}, {"author": "Nick Doty", "text": "

(I'm remote, getting clear audio, video and slides)

", "time": "2022-07-28T14:10:57Z"}, {"author": "Nick Doty", "text": "

can you re-try with a different set of secret shares to see if you can get around the bogus/false entry?

", "time": "2022-07-28T14:16:37Z"}, {"author": "Christopher Patton", "text": "

EKR's attack doesn't sound insurmountable

", "time": "2022-07-28T14:17:04Z"}, {"author": "Christopher Patton", "text": "

Here's the paper with the properties described :Lhttps://eprint.iacr.org/2020/800

", "time": "2022-07-28T14:18:43Z"}, {"author": "Christopher Wood", "text": "

Does ADSS actually prevent the problem that Ekr described?

", "time": "2022-07-28T14:19:18Z"}, {"author": "Jabber", "text": "

dkg: there is some sort of hammering going on in the floor below us here in the hotel -- if you're remote and you're hearing regular banging, that's what it is

", "time": "2022-07-28T14:19:26Z"}, {"author": "Nick Doty", "text": "

it sounds like yes you can re-try with a different set, but also that an attacker who can introduce many false values can make it involve many many re-tries

", "time": "2022-07-28T14:19:26Z"}, {"author": "Christopher Patton", "text": "

we can hear you great!

", "time": "2022-07-28T14:20:15Z"}, {"author": "Jabber", "text": "

dkg: i'd hope that the submissions in STAR aren't \"authenticated\" in the sense of identified. but if the scheme needs some sort of ingress filter, that should be documented in the draft.

", "time": "2022-07-28T14:20:49Z"}, {"author": "Nick Doty", "text": "

nice

", "time": "2022-07-28T14:23:58Z"}, {"author": "Alex Davidson", "text": "

To clarify my response RE STAR: the problem of clients sending bad shares by Eric raised is clearly valid. I used the word \"authenticated\" was the wrong choice of word, but there is a notion of error correction in adept secret sharing that allows recovering the correct value even if bad shares are supplied (see the paper). However, as raised on the list, if we want to use standard secret sharing then clearly that may not apply.

", "time": "2022-07-28T14:26:47Z"}, {"author": "Christopher Patton", "text": "

(\"Prio+\" is an example of a VDAF that doesn't have explicit \"proofs\". It's based on other techniques from MPC, like OT.)

", "time": "2022-07-28T14:26:49Z"}, {"author": "Jabber", "text": "

sftcd: going back to STAR, I think the requirement to use the randomness server is a real weakness in the design - can't recall if that was the same in -00 but it makes the protocol less attractive I think

", "time": "2022-07-28T14:27:06Z"}, {"author": "Christopher Wood", "text": "

@Alex, based on Ekr's attack, would you say then that robustness is a requirement for the secret sharing scheme?

", "time": "2022-07-28T14:28:58Z"}, {"author": "Shivan Sahib", "text": "

sftcd, in -00 we had an alternative deployment where you didn't need the randomness server. But that depends on the measurements being random enough in order to prevent the server from brute forcing all possible inputs

", "time": "2022-07-28T14:34:11Z"}, {"author": "Nick Doty", "text": "

sftcd, can you explain why you found it bad to require the randomness server? I (vaguely) thought it was a general improvement.

", "time": "2022-07-28T14:34:19Z"}, {"author": "Alex Davidson", "text": "

@Chris wood, possibly, it would be useful to have wider feedback on the trade-offs between requiring this and using standard secret-sharing with non-cryptographic attempts to recover values.

", "time": "2022-07-28T14:34:42Z"}, {"author": "Jabber", "text": "

sftcd: @nick: asking the n/w for random numbers is a bit smelly; it requires the client to talk to 2 things to play the game and I'd guess it's another thing that may break

", "time": "2022-07-28T14:35:46Z"}, {"author": "Samuel Weiler", "text": "

EKR, if you want to jump in, stand up? if you want to wait for the end, that's fine....

", "time": "2022-07-28T14:35:59Z"}, {"author": "Jabber", "text": "

sftcd: @shivan: I'm not sure I buy that a client who can do shamir sharing can't generate random numbers tbh but maybe I'm missing something

", "time": "2022-07-28T14:36:21Z"}, {"author": "Shivan Sahib", "text": "

but folks said on list that PPM has already accepted notion of multiple non colluding servers. The randomness server just needs to run oprf-as-a-service, doesn't have to be specific to star

", "time": "2022-07-28T14:36:23Z"}, {"author": "Christopher Wood", "text": "

@Shivan doesn't the randomness server need to have epochs aligned with the aggregation server? In that sense it sounds like it needs to be more in tune with the aggregation server.

", "time": "2022-07-28T14:37:05Z"}, {"author": "Nick Doty", "text": "

I worry that just specifying requirements means that there will be another unspecified set of configurations in order to actually create interoperability between clients/servers

", "time": "2022-07-28T14:37:06Z"}, {"author": "Christopher Patton", "text": "

Which WG?

", "time": "2022-07-28T14:37:50Z"}, {"author": "Christopher Patton", "text": "

@EKR

", "time": "2022-07-28T14:37:52Z"}, {"author": "Christopher Wood", "text": "

httpapi

", "time": "2022-07-28T14:37:53Z"}, {"author": "Christopher Wood", "text": "

https://datatracker.ietf.org/wg/httpapi/about/

", "time": "2022-07-28T14:38:08Z"}, {"author": "Alex Davidson", "text": "

@Christopher Wood, the epochs don't need to be aligned with the aggregation server. The clients simply need to know when it is safe to send messages. The clients can inform the aggregation server within which epoch the messages were constructed.

", "time": "2022-07-28T14:39:50Z"}, {"author": "Christopher Patton", "text": "

FWIW, the collect sub-protocol is low-bandwidth

", "time": "2022-07-28T14:40:49Z"}, {"author": "Nick Doty", "text": "

is there a github issue for the request authentication question?

", "time": "2022-07-28T14:40:52Z"}, {"author": "Sofia Celi", "text": "

+1 to dkg

", "time": "2022-07-28T14:41:45Z"}, {"author": "Christopher Wood", "text": "

@Alex, hm, we should take this offline, as I'm not sure I agree

", "time": "2022-07-28T14:42:11Z"}, {"author": "Christopher Patton", "text": "

Leader's extra power is to pick the set of reports to aggregate. This can lead to sybil attack if it colludes with the collector.

", "time": "2022-07-28T14:42:18Z"}, {"author": "Christopher Patton", "text": "

But it's worth noting that the Helper can do a Sybil attack too by impersonating clients to the leader.

", "time": "2022-07-28T14:42:41Z"}, {"author": "Christopher Wood", "text": "

(We hear nothing remotely, for what it's worth)

", "time": "2022-07-28T14:43:38Z"}, {"author": "Christopher Patton", "text": "

+1 EKR: Collector => Helper comm would not prevent sybil attacks

", "time": "2022-07-28T14:43:39Z"}, {"author": "Nick Doty", "text": "

(remote isn't hearing much of the background noise, we're just noticing everyone in the room looking around / reacting to it)

", "time": "2022-07-28T14:44:02Z"}, {"author": "Sofia Celi", "text": "

I can hear well being remote

", "time": "2022-07-28T14:44:46Z"}, {"author": "Christopher Wood", "text": "

Poplar only works with 1

", "time": "2022-07-28T14:44:57Z"}, {"author": "Jabber", "text": "

dkg: sftcd: i think in STAR it's mandatory that clients coordinate their seeds (\"random\" numbers)

", "time": "2022-07-28T14:46:56Z"}, {"author": "Jabber", "text": "

dkg: +1 to Nick

", "time": "2022-07-28T14:49:11Z"}, {"author": "Christopher Patton", "text": "

+1 to RECOMMENDED client auth

", "time": "2022-07-28T14:49:12Z"}, {"author": "Jabber", "text": "

sftcd: also +1 to nick

", "time": "2022-07-28T14:49:32Z"}, {"author": "Jabber", "text": "

dkg: if i'm thinking about asking a group to run a helper, i don't want to ask them to have to choose authentication schemes

", "time": "2022-07-28T14:49:32Z"}, {"author": "Christopher Patton", "text": "

Poplar costs 2 rounds of aggregate request per level of the tree.

", "time": "2022-07-28T14:49:48Z"}, {"author": "Christopher Patton", "text": "

FWIW, the Poplar paper reports that computing heavy hitters can take hours

", "time": "2022-07-28T14:50:21Z"}, {"author": "Jabber", "text": "

dkg: or, if they're going to run a helper for some specific telemetry scheme, i don't want to have to ask them to vet some complicated set of configuraiton choices that the scheme owner wants them to apply to their off-the-shelf implementation

", "time": "2022-07-28T14:50:23Z"}, {"author": "Christopher Wood", "text": "

(And each level of the tree in popular is one bit)

", "time": "2022-07-28T14:51:15Z"}, {"author": "Jabber", "text": "

sftcd: @dkg: maybe star randomness is a thing to go at via sketching on beer mats but istm there should be some way to coordinate seeds in an epoch locally - I'm totally willing to be convinced I'm wrong as usual but it seems there should be

", "time": "2022-07-28T14:51:31Z"}, {"author": "Christopher Wood", "text": "

Poplar*

", "time": "2022-07-28T14:51:32Z"}, {"author": "Christopher Patton", "text": "

yes :)

", "time": "2022-07-28T14:52:08Z"}, {"author": "Jabber", "text": "

dkg: sftcd: i would sketch on some beer mats with you and shivan if you want to brainstorm options

", "time": "2022-07-28T14:52:22Z"}, {"author": "Christopher Patton", "text": "

STAR is going to be much faster for heavy hitters than Poplar. But where Poplar is feasible it arguably provides stronger security.

", "time": "2022-07-28T14:52:32Z"}, {"author": "Nick Doty", "text": "

if an ohai anonymizing proxy is going to be an important part of the privacy protection, then we should specify that (similar to the STAR draft)

", "time": "2022-07-28T14:53:08Z"}, {"author": "Shivan Sahib", "text": "

Yes willing to do that, but I guess I'm skeptical :) but very happy to discuss @dkg @sftcd

", "time": "2022-07-28T14:53:20Z"}, {"author": "Alex Davidson", "text": "

@sftcd, if there was a way to do that efficiently then great. We found that the only way to do it locally is to derive all meaningful entropy from the internal measurement, since that is the only thing you can guarantee clients share that the aggregation server does not.

", "time": "2022-07-28T14:53:26Z"}, {"author": "Tim Geoghegan", "text": "

@Nick Doty ingestion servers is another case where we want to allow it but not mandate it, because it's not clear that it's practical for all deployments

", "time": "2022-07-28T14:54:17Z"}, {"author": "Jabber", "text": "

dkg: Alex: right, and the problem with that is that the aggregator can then guess and check the same thing, right?

", "time": "2022-07-28T14:54:33Z"}, {"author": "Shivan Sahib", "text": "

Sorry I guess you can't see all my +1s on Jabber dkg.

", "time": "2022-07-28T14:55:26Z"}, {"author": "Matthew Finkel", "text": "

@Tim Geoghegan I don't remember if that's mentioned in the draft, but if it's not then adding a sentence about it would be helpful around the high-level architecture.

", "time": "2022-07-28T14:55:36Z"}, {"author": "Alex Davidson", "text": "

@dkg, yep, exactly. If you use the randomness (OPRF) server, you at least move the guessing to an online check, and you can cut off infinite guesses by rotating the OPRF key.

", "time": "2022-07-28T14:55:38Z"}, {"author": "Matthew Finkel", "text": "

@Tim Geoghegan If it is mentioned, then my apologies :)

", "time": "2022-07-28T14:56:02Z"}, {"author": "Nick Doty", "text": "

(lack of fidelity of bridging between chat services is such a sad moment. +1 that we either need to bridge the reaction emojis, or stop using them.)

", "time": "2022-07-28T14:56:31Z"}, {"author": "Jabber", "text": "

dkg: wait, there are reaction emojis?

", "time": "2022-07-28T14:57:10Z"}, {"author": "Matthew Finkel", "text": "

Yep :) You're missing out

", "time": "2022-07-28T14:57:26Z"}, {"author": "Simon Friedberger", "text": "

I don't seem them in the web chat either...?

", "time": "2022-07-28T14:57:40Z"}, {"author": "Tim Geoghegan", "text": "

@Matthew Finkel you're right! We have https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/155 for one specific dimension of the problem, but it doesn't capture everything. I'll file a new issue.

", "time": "2022-07-28T14:57:52Z"}, {"author": "Nick Doty", "text": "

dkg, Zulip has reacji, not unlike Matrix and Slack (and iMessage and...)

", "time": "2022-07-28T14:57:55Z"}, {"author": "Jabber", "text": "

dkg: sigh, webberfaces :sad:

", "time": "2022-07-28T14:57:59Z"}, {"author": "Alex Davidson", "text": "

@Christopher Patton, interested to know why Poplar \"arguably\" provides stronger security guarantees than STAR. AFAICT for client privacy at least, the leakage from both schemes is largely incomparable, and you can imagine situations for both where you leak a lot about input measurements that are not part of the aggregation result.

", "time": "2022-07-28T14:58:48Z"}, {"author": "Nick Doty", "text": "

\"incomparable\" or comparable?

", "time": "2022-07-28T14:59:14Z"}, {"author": "Alex Davidson", "text": "

incomparable, the leakage that occurs in both is fundamentally different.

", "time": "2022-07-28T15:00:00Z"}, {"author": "Sofia Celi", "text": "

+1 to Alex POPLAR leaks all heavy-hitters prefixes, while STAR leaks which client share the same measurements

", "time": "2022-07-28T15:01:29Z"}, {"author": "Sofia Celi", "text": "

I also cannot see why POPLAR provides stronger security guarantees. Interested in knowing that

", "time": "2022-07-28T15:03:54Z"}, {"author": "Nick Doty", "text": "

is the risk that multiple queries could include the same report? or is the risk that some information about the grouping (the characteristics of the User Agent, say) adds something important to what is revealed about the reports?

", "time": "2022-07-28T15:06:32Z"}, {"author": "Christopher Wood", "text": "

@Nick, basically, yeah

", "time": "2022-07-28T15:07:35Z"}, {"author": "Christopher Wood", "text": "

(The former)

", "time": "2022-07-28T15:07:48Z"}, {"author": "Alissa Cooper", "text": "

it seems much easier to enforce a restriction on multiple queries containing the same report in the case of chunks as opposed to groups

", "time": "2022-07-28T15:08:27Z"}, {"author": "Tim Geoghegan", "text": "

Here's a GH issue about request/response authentication, please feel free to comment there, or here, or email, or come to my house and yell at me: https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/293

", "time": "2022-07-28T15:08:41Z"}, {"author": "Christopher Wood", "text": "

@Alissa yeah, I think that's accurate

", "time": "2022-07-28T15:09:25Z"}, {"author": "Nick Doty", "text": "

thanks Tim, I appreciate having a specific issue to add to rather than coming to your house

", "time": "2022-07-28T15:09:32Z"}, {"author": "Christopher Patton", "text": "

@Alex, @Sofi will respond afeter this ...

", "time": "2022-07-28T15:09:44Z"}, {"author": "Nick Doty", "text": "

the reason that people may be comfortable contributing to this scheme

", "time": "2022-07-28T15:11:23Z"}, {"author": "Sofia Celi", "text": "

+1 to dkg Perfectly put

", "time": "2022-07-28T15:11:31Z"}, {"author": "Sofia Celi", "text": "

people also need to consent to these systems. They can be uncomfortable with it even when private

", "time": "2022-07-28T15:11:54Z"}, {"author": "Yoshimichi Nakatsuka", "text": "

Can we simulate some form of a database query for Collector queries?I think this would help prevent creating a new language.

", "time": "2022-07-28T15:12:04Z"}, {"author": "Jabber", "text": "

sftcd: also +1 for not further complicating an already complex thing

", "time": "2022-07-28T15:12:12Z"}, {"author": "Nick Doty", "text": "

+1 dkg

", "time": "2022-07-28T15:12:26Z"}, {"author": "Sofia Celi", "text": "

research also do shows that if the privacy properties are correctly explained to users, they are usually more willing to share. But it is not a 'random, unclear' privacy definition: https://arxiv.org/abs/2110.06452 It should be vital to properly explain the downsides, properties of schemes

", "time": "2022-07-28T15:14:48Z"}, {"author": "Andrew Campling", "text": "

Keeping this is simple as possible to minimise the risk of abuse seems like a good plan

", "time": "2022-07-28T15:16:05Z"}, {"author": "Jabber", "text": "

dkg: we're looking for the intersection of \"useful in practice\" and \"confident that it cannot be used for targeting or abuse\" -- if we lose one or the other, i'm not sure what we're doing here.

", "time": "2022-07-28T15:18:22Z"}, {"author": "Nick Doty", "text": "

is there some business-level insight on to what makes this useful or definitely not useful?

", "time": "2022-07-28T15:18:57Z"}, {"author": "Jabber", "text": "

dkg: but prospective deployers might also need to reconsider what \"useful in practice\" means -- we're aiming to wean organizations from full-take global surveillance, and they're not going to get the same level of detail.

", "time": "2022-07-28T15:19:03Z"}, {"author": "Eric Rescorla", "text": "

The drilldown use case is very important

", "time": "2022-07-28T15:19:16Z"}, {"author": "Christopher Wood", "text": "

^^^

", "time": "2022-07-28T15:19:31Z"}, {"author": "Eric Rescorla", "text": "

I think it's fine to not have it today, but we will eventually need it

", "time": "2022-07-28T15:19:39Z"}, {"author": "Christopher Wood", "text": "

I think we ought to start asking people who might use this what sort of requirements they have to adopt it. The incentives need to be there.

", "time": "2022-07-28T15:20:07Z"}, {"author": "Nick Doty", "text": "

can we say more about \"drilldown\"? drill down based on client properties? or drill down based on a sub-time-period?

", "time": "2022-07-28T15:20:08Z"}, {"author": "Jabber", "text": "

dkg: how far can you drill down though? maybe i don't know what \"the drilldown use case\" is

", "time": "2022-07-28T15:20:15Z"}, {"author": "Eric Rescorla", "text": "

Client properties

", "time": "2022-07-28T15:20:17Z"}, {"author": "Jabber", "text": "

sftcd: guidance on when to not be bold seems pretty weak though (responding to wes)

", "time": "2022-07-28T15:20:42Z"}, {"author": "Nick Doty", "text": "

(we can't hear the q in the room)

", "time": "2022-07-28T15:22:01Z"}, {"author": "Christopher Patton", "text": "

(We = Firefox)

", "time": "2022-07-28T15:22:04Z"}, {"author": "Tim Geoghegan", "text": "

Still catching up on comments from my deck: here's a GH issue about how the protocol should discuss the use of anonymizing proxies like OHAI: https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/294

", "time": "2022-07-28T15:22:26Z"}, {"author": "Samuel Weiler", "text": "

question was \"clarify drilldown\", I think.

", "time": "2022-07-28T15:22:29Z"}, {"author": "Matthew Finkel", "text": "

\"Can you give an example of what you mean by drill-down?\"

", "time": "2022-07-28T15:22:29Z"}, {"author": "Nick Doty", "text": "

(thank you)

", "time": "2022-07-28T15:22:49Z"}, {"author": "Junye Chen", "text": "

With timestamp being rounded down to min batch duration (let's say 4 hours), if I have to specify a time interval (that also lasts for 4 hours) to collect the results, the minimum batch may quickly be satisfied in way less than 4 hours, but I can't collect any more report in that 4-hour window, so that could result in a lot of wasted reports there.there could be multiple batches that satisfy minimum batch size, but if I'm only allowed to collect that interval once, there could be a lot of wasted reports there.

", "time": "2022-07-28T15:23:35Z"}, {"author": "Jabber", "text": "

dkg: both DP and drilldown are very broad descriptions of practices that can be potentially abused

", "time": "2022-07-28T15:23:41Z"}, {"author": "Sofia Celi", "text": "

+1 to dkg

", "time": "2022-07-28T15:24:11Z"}, {"author": "Matthew Finkel", "text": "

Relatedly, Chris Wood shared this doc in the OHAI chat a few days ago: https://privacytools.seas.harvard.edu/publications/algorithmic-institutional-logics-politics-differential-privacy

", "time": "2022-07-28T15:24:33Z"}, {"author": "Eric Rescorla", "text": "

dkg: no question.

", "time": "2022-07-28T15:24:35Z"}, {"author": "Jabber", "text": "

dkg: e.g. DP with a mis-tuned \u03b5 is problematic, and drill-down based on arbitrary parameters is also problematic

", "time": "2022-07-28T15:24:41Z"}, {"author": "Jabber", "text": "

dkg: so we can't just say \"we want this protocol to support DP\" or \"we want this protocol to support drilldown\"

", "time": "2022-07-28T15:25:10Z"}, {"author": "Matthew Finkel", "text": "

+1

", "time": "2022-07-28T15:25:34Z"}, {"author": "Jabber", "text": "

dkg: it's on us as designers to be clear what the specifics are of what we want to enable.

", "time": "2022-07-28T15:25:39Z"}, {"author": "Eric Rescorla", "text": "

Jabber said:

\n
\n

dkg: e.g. DP with a mis-tuned \u03b5 is problematic, and drill-down based on arbitrary parameters is also problematic

\n
\n

Yes, though I think the number of times a given submission is sampled is a more serious concern

", "time": "2022-07-28T15:25:40Z"}, {"author": "Christopher Patton", "text": "

@Sofia, @Alex: STAR vs. Poplar: STAR is vulnerable to traffic analysis against the anonymizing proxy, whereas Poplar is not. That's all I meant. You're right about Poplar having leakage (via hit counts for candidate prefixes computed at each round), which STAR doesn't have. Basically I was wrong to say that one has \"stronger\" security than the other. I think the actual situation we're in is that the protcools are not comparable, at least formally. Do you agree?

", "time": "2022-07-28T15:25:52Z"}, {"author": "Sofia Celi", "text": "

+1 specially, due to the fact that there are many ways of adding DP: all of them have different privacy properties or efficiency

", "time": "2022-07-28T15:25:53Z"}, {"author": "Jabber", "text": "

dkg: ekr: i don't think these are different concerns.

", "time": "2022-07-28T15:27:08Z"}, {"author": "Christopher Patton", "text": "

With STAR it's also notable that how vulnerable to traffic analysis you are depends on how anonymization works: If you use Tor you're in pretty good shape.

", "time": "2022-07-28T15:27:22Z"}, {"author": "Sofia Celi", "text": "

@chris p: thank you! they are comparable in that they are heavy-hitters. But POPLAR is prio-based (and some notion of f-privacy), while STAR is k-anonimity. So it is difficult to formally compare them, yes

", "time": "2022-07-28T15:27:26Z"}, {"author": "Jabber", "text": "

dkg: i think your proposed limit might be a useful way to try to answer the question of \"just how much drilldown\" or \"what kinds of DP\"

", "time": "2022-07-28T15:27:43Z"}, {"author": "Jabber", "text": "

dkg: (but i'd need to see more analysis to understand the tradeoff)

", "time": "2022-07-28T15:28:03Z"}, {"author": "Alex Davidson", "text": "

@Christopher Patton, yes I agree with that analysis RE formal security guarantees. Though an anonymizing proxy is also used for message submission in poplar, right?

", "time": "2022-07-28T15:29:09Z"}, {"author": "Christopher Patton", "text": "

no, it's not needed

", "time": "2022-07-28T15:29:37Z"}, {"author": "Christopher Patton", "text": "

Anonymity is achieved via secret sharing.

", "time": "2022-07-28T15:30:00Z"}, {"author": "Tim Geoghegan", "text": "

Even without an anonymizing proxy, Prio and Poplar protect client privacy if >1 aggregator does not defect

", "time": "2022-07-28T15:30:02Z"}, {"author": "Christopher Patton", "text": "

you still need non-collusion, but no proxy is needed.

", "time": "2022-07-28T15:30:03Z"}, {"author": "Sofia Celi", "text": "

I did do a very informal comparison of the schemes over here (needs more work): https://sofiaceli.com/thoughts/ppm-tech-01.pdf

", "time": "2022-07-28T15:30:06Z"}, {"author": "Jabber", "text": "

dkg: the text says \"all but one is honest\", but Chris said \"only one needs to be honest\"

", "time": "2022-07-28T15:30:18Z"}, {"author": "Tim Geoghegan", "text": "

Dang it, I meant \"at least one aggregator\"

", "time": "2022-07-28T15:30:31Z"}, {"author": "Eric Rescorla", "text": "

@Sofia Celi I do not believe that this is accurate: image.png

\n
", "time": "2022-07-28T15:30:59Z"}, {"author": "Eric Rescorla", "text": "

Or rather it's only accurate if the input value is high entropy, which is not the interesting case

", "time": "2022-07-28T15:31:17Z"}, {"author": "Sofia Celi", "text": "

oh, I'll correct @erk Thank you! (I didn't know images could be sent here)

", "time": "2022-07-28T15:31:37Z"}, {"author": "Alex Davidson", "text": "

@Christopher Patton, okay good to know thanks, I thought that I had read in a previous version of the DAP draft that a proxy should be used.

", "time": "2022-07-28T15:31:45Z"}, {"author": "Simon Friedberger", "text": "
\n

=

\n
", "time": "2022-07-28T15:32:02Z"}, {"author": "Simon Friedberger", "text": "

\">=\"

", "time": "2022-07-28T15:32:15Z"}, {"author": "Jabber", "text": "

dkg: the images don't work in the relayed channels, fwiw, b/c the underlying image pointers are relative URLs

", "time": "2022-07-28T15:32:50Z"}, {"author": "Samuel Weiler", "text": "

The questions coming at the end of this are:

\n
    \n
  1. Is the threat model clear?
    2. \n
  2. \n

    Are there attacks on privacy we have not considered that the protocol should
    \naddress?

    \n
    3. \n
  3. \n

    Do folks agree the selection of attacks (intersection attack) that DAP can be
    \nmitigated in the protocol?

    \n
    4. \n
", "time": "2022-07-28T15:33:53Z"}, {"author": "Christopher Patton", "text": "

@Alex I do think a recommendation to use an anomyzing proxy got into the spec, yes. I think the idea is that, depending on how reports extensions are used, anonymization might be useful. But it's definitely not needed for the core protocol.

", "time": "2022-07-28T15:34:06Z"}, {"author": "Matthew Finkel", "text": "

Ekr's link: https://zulip.ietf.org/user_uploads/2/76/Mplt8SLL6Nf3VcGOcoXA09HQ/image.png

\n
", "time": "2022-07-28T15:34:08Z"}, {"author": "Eric Rescorla", "text": "

@Matthew Finkel that won't work if you aren't logged in

", "time": "2022-07-28T15:34:28Z"}, {"author": "Matthew Finkel", "text": "

I don't know if it requires cookie auth

", "time": "2022-07-28T15:34:32Z"}, {"author": "Matthew Finkel", "text": "

Ah, k. Oh well.

", "time": "2022-07-28T15:34:40Z"}, {"author": "Jabber", "text": "

sftcd: @sam: I'm not clear what your #3 is asking

", "time": "2022-07-28T15:35:16Z"}, {"author": "Sofia Celi", "text": "

dkg: I'll send you the corrected note with the correct of ekr so you can see it over email ;)

", "time": "2022-07-28T15:35:35Z"}, {"author": "Samuel Weiler", "text": "

@sftcd: these are Chris Wood's questions, so I'll leave it for him to ask them.

", "time": "2022-07-28T15:36:12Z"}, {"author": "Matthew Finkel", "text": "

dkg: specifically, ekr highlighted the STAR line in the Figure 1 table on page 8

", "time": "2022-07-28T15:36:54Z"}, {"author": "Christopher Patton", "text": "

lol

", "time": "2022-07-28T15:37:14Z"}, {"author": "Christopher Patton", "text": "

Good catch DKG

", "time": "2022-07-28T15:37:21Z"}, {"author": "Christopher Patton", "text": "

I don't know how to deal with over exposure w/o DP

", "time": "2022-07-28T15:38:23Z"}, {"author": "Christopher Patton", "text": "

(sorry, \"over exposure\" == \"over release\"

", "time": "2022-07-28T15:39:15Z"}, {"author": "Matthew Finkel", "text": "

I believe that was one motivating reasons for DP

", "time": "2022-07-28T15:39:46Z"}, {"author": "Nick Doty", "text": "

because the aggregator can't determine/prove that N distinct clients contributed? and so the risk is that actually only 1 user (or fewer users than we expected) is in the query?

", "time": "2022-07-28T15:39:49Z"}, {"author": "Christopher Patton", "text": "

@Nick yeah

", "time": "2022-07-28T15:40:15Z"}, {"author": "Sofia Celi", "text": "

I do think you need an issue tracking all the DP concerns @chris p ;) Happy to help on that (and maybe bring some DP community people)

", "time": "2022-07-28T15:41:29Z"}, {"author": "Jabber", "text": "

dkg: DP itself can fail with \"over release\" if that's what we're calling it, to the extent that submissions might be linkable

", "time": "2022-07-28T15:41:44Z"}, {"author": "Jabber", "text": "

dkg: and i'm not confident that we need \"strong\" linkability to trigger that kind of failure (e.g. just tracking source IP addresses might offer enough linkability to make the system uncomfortably leaky for some users)

", "time": "2022-07-28T15:43:21Z"}, {"author": "Sofia Celi", "text": "

oh that is nice! thank you chris p!

", "time": "2022-07-28T15:43:44Z"}, {"author": "Jabber", "text": "

dkg: Sofia: bringing in DP community people seems like a good idea

", "time": "2022-07-28T15:43:51Z"}, {"author": "Christopher Patton", "text": "

@sofi https://github.com/cfrg/draft-irtf-cfrg-vdaf/issues/94

", "time": "2022-07-28T15:44:37Z"}, {"author": "Sofia Celi", "text": "

dkg: yes. DP is not a simple thing. But there are people way more capable than myself to help on it ;)

", "time": "2022-07-28T15:44:55Z"}, {"author": "Christopher Patton", "text": "

@sofi it might be good for PPM to work on an informative document for guidelines in using DP in our protocols?

", "time": "2022-07-28T15:45:10Z"}, {"author": "Christopher Patton", "text": "

+1 EKR

", "time": "2022-07-28T15:46:06Z"}, {"author": "Sofia Celi", "text": "

@chris p: that will be useful in general. Not only for the IETF, but as an informative document for the whole community. Maybe a more pearg document, though?

", "time": "2022-07-28T15:46:08Z"}, {"author": "Jabber", "text": "

dkg: you're muted Tim

", "time": "2022-07-28T15:46:26Z"}, {"author": "Sofia Celi", "text": "

but yes, will be happy if there is such a document @chris p!

", "time": "2022-07-28T15:46:36Z"}, {"author": "Christopher Patton", "text": "
\n

Maybe a more pearg document, though?Yeah that makes sense :)

\n
", "time": "2022-07-28T15:46:57Z"}, {"author": "Sofia Celi", "text": "

I'll talk with Shivan ;) And we can work on something @Christopher Patton ;)

", "time": "2022-07-28T15:47:25Z"}, {"author": "Christopher Patton", "text": "

@Tim yes but we could restrict those subsequent queries to the first batch.

", "time": "2022-07-28T15:47:48Z"}, {"author": "Jabber", "text": "

dkg: nick you're breaking up

", "time": "2022-07-28T15:48:27Z"}, {"author": "Jabber", "text": "

dkg: please turn off video

", "time": "2022-07-28T15:48:31Z"}, {"author": "Eric Rescorla", "text": "

@Nick Doty you ran out of privacy budget

", "time": "2022-07-28T15:48:36Z"}, {"author": "Simon Friedberger", "text": "

@ChrisWood For 2.: a client might submit multiple related reports. i.e. same value every day. This allows some of the other attacks that are based on \"use report only once\" anyway.

", "time": "2022-07-28T15:48:51Z"}, {"author": "Tim Geoghegan", "text": "

@ChrisP yeah good point

", "time": "2022-07-28T15:49:01Z"}, {"author": "Nick Doty", "text": "

I think there are likely additional privacy threats, if we consider privacy broadly (as I think we generally should), where users may have concerns about threats to group privacy, especially small groups (your classroom in the school, say)

", "time": "2022-07-28T15:49:45Z"}, {"author": "Jabber", "text": "

dkg: Simon: by \"attacks that are based on\" do you mean \"attacks that we can defend against with\" ?

", "time": "2022-07-28T15:50:02Z"}, {"author": "Nick Doty", "text": "

I think some of those threats have been mentioned in the chat here, or in Sofia's presentation/writeup

", "time": "2022-07-28T15:50:21Z"}, {"author": "Simon Friedberger", "text": "

@dkg Ah, yes, should be \"where the defense is based on\"

", "time": "2022-07-28T15:50:58Z"}, {"author": "Nick Doty", "text": "

so we should continue to detail the impacts on users, or what users may care about in choosing whether to participate, and those considerations may not be exclusively the q \"can my individual report be traced back to me?\"

", "time": "2022-07-28T15:51:10Z"}, {"author": "Sofia Celi", "text": "

@nick doty: yes! there is the case in which there are 'surveys' for targetted for women, for example, (or other groups) in which group privacy might be leaked

", "time": "2022-07-28T15:51:20Z"}, {"author": "Sofia Celi", "text": "

and while not individually harming privacy, it is a target to a group a user belongs to

", "time": "2022-07-28T15:51:44Z"}, {"author": "Jabber", "text": "

dkg: Simon: yes, that makes sense. that's what i was trying to say at the mic

", "time": "2022-07-28T15:51:52Z"}, {"author": "Jabber", "text": "

dkg: +1 to Sofia and Nick: there are more harms than individualized harms that we need to consider

", "time": "2022-07-28T15:52:32Z"}, {"author": "Jabber", "text": "

dkg: especially when people are judged or controlled based on group membership

", "time": "2022-07-28T15:52:54Z"}, {"author": "Alissa Cooper", "text": "

It seems very hard to enforce against unsavory-but-not-privacy-invading group definitions once you go beyond groups defined by quantitative metrics like time or batch size. OTOH if an entity is putting in the effort to use ppm then being careful about group definition might be a natural thing to do.

", "time": "2022-07-28T15:54:29Z"}, {"author": "Jabber", "text": "

dkg: +1 Alissa: that seems like a good rule of thumb

", "time": "2022-07-28T15:56:16Z"}, {"author": "Matthew Finkel", "text": "

+1 I'm struggling to see the concrete attack, but I we should be careful that we don't make something like that easy to achieve.

", "time": "2022-07-28T15:56:34Z"}, {"author": "Jabber", "text": "

dkg: even quantitative metrics like time might be problematic, in the event that TZ/workday hours can split users by rough geographic location

", "time": "2022-07-28T15:56:54Z"}, {"author": "Sofia Celi", "text": "

I general I agree @Alissa Cooper but with the current trend of organisations of adversing privacy in a green-washing manner, I'm not so sure. The general point was that the user voice is generally absent on these schemes. Even if I know a system is private, I should be able to opt-out if I don't know what the output of the aggregation will be used for

", "time": "2022-07-28T15:57:38Z"}, {"author": "Benjamin Schwartz", "text": "

Privacy doesn't solve all problems. The draft can achieve privacy, and still acknowledge the protections it cannot ensure.

", "time": "2022-07-28T15:58:51Z"}, {"author": "Nick Doty", "text": "

@alissa what did you mean by \"unsavory-but-not-privacy-invading\"? is that the example of revealing about a group but not individually identifiable?

", "time": "2022-07-28T15:59:45Z"}, {"author": "Sofia Celi", "text": "

@Benjamin Schwartz yes! I think that is precisely what is needed: an acknowledge of it

", "time": "2022-07-28T15:59:56Z"}, {"author": "Jabber", "text": "

dkg: Shan i agree about the transparency. thanks for working on this!

", "time": "2022-07-28T16:03:29Z"}, {"author": "Sofia Celi", "text": "

great meeting! thanks!

", "time": "2022-07-28T16:03:40Z"}, {"author": "Tim Geoghegan", "text": "

Thanks to the chairs for chairing!

", "time": "2022-07-28T16:04:07Z"}, {"author": "Nick Doty", "text": "

per dkg, I'm not sure I would want users to read through parameters and agree to them, but I could see client software making some general decisions about which parameters seem invasive and which don't, and keeping a log for very interested users

", "time": "2022-07-28T16:04:20Z"}, {"author": "Christopher Patton", "text": "

thanks everyone

", "time": "2022-07-28T16:04:31Z"}]