**Session Date/Time:** 29 Jun 2026 22:00

**Tim Geoghegan:** Yes, you're right, there is. That's an even better way to do it.

**Benjamin Schwartz:** All right. Um, so, yeah, let's glance at the changelog, and uh, I don't know, maybe it would be nice to talk about open issues. Uh, do we have any? 

**Benjamin Schwartz:** Uh, if there are none, then so much the better. 

**Tim Geoghegan:** Yeah, right.

**Christopher Patton:** The um, I'm not aware of much to discuss for DAP. The task-prov draft is kind of in a sad state right now. Um, I think uh, I feel a little unsure about what to do with it at this point. Um, so, it might be nice to talk about that.

**Christopher Patton:** All right. And then the last thing I would have is um, the uh, they just they did last call for the V-DAP draft, which is great. Um, yeah.

**Tim Geoghegan:** Which means that, whoever is in this working group,

**Christopher Patton:** Yeah, I don't know how to get more support for it, but if hopefully if no one objects, they just, you know,

**Tim Geoghegan:** It's really it's worthwhile for members of this working group to go over to CFRG and say that, yes, this draft is good and cool, and should get an RFC number. And that they should go back and find us one of the unused 7000 RFC numbers.

**Martin Thomson:** I can confirm that the CFRG will be very bad about completing a working group last call if you're not able to jump on top of that. So, be careful.

**Tim Geoghegan:** Excuse me, Research Group last call. Let's not let's not get confused about what CFRG is for.

**Martin Thomson:** Whatever. Whatever. It's it's a working group as far as I'm concerned. Yeah.

**Benjamin Schwartz:** Well, uh, maybe we will give people one more minute to trickle in. Uh, but I can't say I'm aware of anybody specifically who I'm expecting who isn't already here.

**Martin Thomson:** Chris, thank you for your words about task-prov. I do hope we discuss it because Ben and I were also wondering what we should be doing with it, so. I'm not sure to be happy or sad that we are not alone.

**Christopher Patton:** I mean, I think like the meat of what we wanted with that draft is actually in DAP itself at this point, so uh there's not much for it to do.

**Benjamin Schwartz:** All right, it seems like people can't uh can't hold on to their substantive comments any longer. So, let's get this uh party started. Welcome to the Privacy Preserving Measurement June Virtual Interim. 

**Benjamin Schwartz:** This is an IETF working group meeting. That means it is covered by the IETF Note Well. That Note Well creates certain kinds of obligations on standards of behavior, and how we treat each other as participants in the IETF. It also creates some legal obligations that may bind you and your organization, uh, if you are contributing to this working group. So, it is very important, if you're contributing uh and participating here, that you understand and review the content of the Note Well. 

**Benjamin Schwartz:** This is our draft proposed agenda for the day. Um, I hear there might be an agenda bash related to task-prov. Chris, do you want to propose a slightly uh to propose an addition, I guess, to the agenda?

**Christopher Patton:** Yep.

**Benjamin Schwartz:** Okay. So, we'll take that as an addition uh at the end of the agenda, I guess. Any other thoughts on our agenda?

**Tim Geoghegan:** Yes, I would like to discuss uh so, besides the, I guess, the DAP update, which is going to be sort of looking back at what we have done in the last few months, I'd like to discuss looking forward on DAP, um next steps towards an RFC.

**Benjamin Schwartz:** All right. Uh, let's make sure we cover that. Uh, I think we can do that immediately following the DAP update.

**Tim Geoghegan:** Sounds good.

**Benjamin Schwartz:** So, we have one chair slide with some notes of relevance. So, the V-DAP draft has completed the Crypto Panel review, which is an internal process that's very special to CFRG, and has now entered Research Group last call in CFRG. As some folks were saying earlier, this is uh the perfect time for you to go participate in CFRG and help them to make the right decision, uh whatever you think that is, about their Research Group last call. 

**Benjamin Schwartz:** Uh, I know as a chair, uh of a working group, that it can be hard to remember to uh keep track of all the documents that need to be props processed through the last call uh procedure. So, going and reminding them there are people interested in this draft could be helpful. 

**Benjamin Schwartz:** I want to thank JC Jones, who has volunteered to act as shepherd for the DAP draft. So, as DAP is wrapping up, uh hopefully, we will be hearing from JC about different about the the status of the draft. So, there will be some questions. If you are authors, and you get an email from JC, please prioritize it. Uh, that is very important to being able to make progress on the draft. 

**Benjamin Schwartz:** We wanted to mention task-prov. So, task-prov went through a working group last call uh six months ago. And the chairs kind of uh lost focus on it, maybe. But, we took another look at it today, and it seems like on the one hand, there's clear consensus in favor of publishing task-prov, and on the other hand, the uh the context has changed somewhat since then because there are material changes since then in the DAP draft that that have considerable implications for task-prov. So, I think we're going to revisit that today. 

**Benjamin Schwartz:** Um, and finally, there will not be a PPM session at IETF 126. Uh, so, if you have other topics that you want to cover outside of this meeting, um please do it on the list. 

**Benjamin Schwartz:** All right, uh that's all for chair slides. I think I'll hand it over to Tim to talk about some recent changes and any pending changes in DAP.

**Tim Geoghegan:** Thank you. Okay, I've requested screen share. Do I have it?

**Tim Geoghegan:** Uh, I don't have slides. I need screen share.

**Tim Geoghegan:** See, we do this too infrequently and then we always forget how the buttons work. Okay. On my end, it shows that I have screen requested. I think a chair needs to click a button that I think shows up in like my entry in the participants' list in Meetecho. And then, hopefully, that'll

**Benjamin Schwartz:** Oh, can you try can you try hitting request again?

**Tim Geoghegan:** All right. Stop. Request it again. Okay, that's working. Just one moment while I find the right window. Excellent. All right, so um as So, I just want to give a quick rundown of what has happened in uh DAP in the last few months, I guess, since the last time we met. So, to be perfectly honest with you, I forget what draft version we were on the last time we met. Um, but I think the important thing, so I don't want to go over each and every detail here, um I think really okay, the bulk of this was motivated by a review or a couple of reviews that Martin Thomson did. Thank you, Martin, for taking the time to um read the document, you know, study it closely, and share all your feedback with us, um as well as, actually, make a bunch of contributions directly, which is nice. Uh, so, I think All right, so one of the major headline things here, as Chris alluded to, right, is that task-prov, um besides a dynamic task provisioning mechanism, which I think is the meat of what we'll talk about when we get to that agenda item, task-prov included a task binding mechanism, which uh the intent of which was to force all protocol participants to commit to a given set of parameters or, you know, a given task configuration. Um, the idea is that this enables some measure of transparency, uh and gives clients an opportunity to assess the task configuration parameters and decide whether they like them, um before they participate in a telemetry collection task. Um, so, this had been one of the two mechanisms defined in that task-prov document. But, we decided to pull it into the core DAP specification because uh I mean, I think the motivation at a high level was that um the uh attribution level one work that's going on at W3C, PATWG, the Private Advertising Technology Working Group, um has a need for this, but like without um task-prov. Essentially, we we concluded that it was of that the uh parameter commitment part was valuable enough that we wanted it in core DAP. So, this required some shuffling around of text, like basically deleting a lot of text out of task-prov and moving it into core DAP. 

**Tim Geoghegan:** Um, the other things is we did some last-minute sort of reorganizing, refactoring of the HTTP API um in DAP itself, which is of course, you know, ground that has been well-churned uh in uh over many many iterations over the years now. Uh, but now we've landed at something that it definitely works, um and I think we're comfortable with it in terms of being sort of like a normal sensible HTTP API. Um, what else? Ah, okay. Also, with an eye towards eventual use by stuff that will come out of PATWG, we added new extensibility mechanisms to DAP. So, um for one thing, I think we have at this point three, no, four, come to think of it, right, extension points in DAP. Task configuration, which is now in DAP like um something that we have um an agreed-upon encoding for because everybody has to hash it in order to construct um AAD when encrypting messages, that has an extension point that lets you uh that lets, you know, future documents specify extensions. So, concretely, um task bind is, uh I think is an extension at this point. Um, Martin has drafted a handful of extensions that are going to be used by attribution level one. We envision that differential privacy will manifest as task extensions, um and you know, generally, it's a way to add extensions to a DAP task and make sure that all of the participants, you know, know what they are and know how they're configured. Then, aggregation jobs now also have an extension point. Um, the reason we did this is so that there would be some way that eventually implementations can convey the ID of the current verification key in use. Um or Sorry, I take that back. I think actually we put the verification key ID right like in the aggregation job and it's not an extension. Um, so, to be honest with you, off the top of my head, I forget why we did Oh, right, right, okay, sorry. I'm reviewing the changelog now. We moved the partial batch selector to uh yeah, become an aggregation job extension. Um, such that Right, okay, yeah, such that it can be more conditional upon the batch mode in use whether a partial batch selector needs to be conveyed. Um, I'm not going to get into what a partial batch selector is. Um, I think we don't have time to unpack that like particularly ugly piece of API. It's well written up in some of the issues, uh some of the issues on this repository, if you want to know why there is such a thing as a partial batch selector and all the history there. Um, but in any case, now it's represented as an extension. We also did collection job extensions, um so that uh I think they are again, that's so that that's so that a collector can convey to the leader some information that will eventually be used, I believe, to to assign reports to batches at aggregation time. So, there. Otherwise, I think we had just some cleanup. Um, we got a uh very helpful contribution from Hang on, where is it? Uh yeah, from Stan from Ireland. Thank you very much for taking the time. I don't know if Stan is with us today. In any case, uh they took the time to read the draft and submitted a couple of like very useful clarifications, uh typo cleanups. I went and did some auditing of the error types um that are defined in DAP. I found some codes that just weren't used anymore, basically leftover um stuff that got left over during past refactors, and made sure to delete those. And David just recently tidied up something complicated about uh how we handle um another error ver- I think, yeah, David went and cleaned up something about how we how we indicate that an extension is unsupported, or rather, we we no longer bother to indicate that since now that extensions have to be committed to in the task configuration, it no longer really makes sense for DAP participants to sort of dynamically indicate um which extensions they do or don't support. Um, so that's what's been happening. 

**Tim Geoghegan:** Now, this is the open issues on the document. Um, these two issues tracked tagged pre-WGLC are pretty mechanical. It's just so for instance, if and when V-DAP gets an RFC number, uh we'd want to go and fix that up. Um, and we, I guess, there's some IANA stuff we'd have to do in order to carve out our URN uh namespace for errors, I believe. And finally, uh this is the thing I just alluded to, uh David cleaned up some text um around uh whether some conditions are reported as like an abort of an entire aggregation job, or an error on an individual report share within the aggregation job. Um, but like I say, there is a subtlety there about re- about um what an aggregator should do in the face of unrecognized extensions. Um, I encourage people to go look at the pull request, review it closely, and uh discuss there. Um, I think that's pretty much all I've got for DAP updates. Um, any questions, discussion points?

**Benjamin Schwartz:** Where are we on interoperability with all of these new protocol changes?

**Tim Geoghegan:** So, implementation of these changes is in flight in in Janus, which is ISRG/Divviup's implementation. Uh, in fact, JC's been working on that um over a period of months. Um, I'm not specifically aware of other DAP implementations that are tracking towards this. Right, so as Chris just mentioned, Cloudflare's Daphne, um has not been maintained for a while. Um, and the uh I'm aware of other DAP implementations out there, but I have not heard of specific plans on their part to adopt the latest version of the protocol.

**Benjamin Schwartz:** So, uh my understanding of DAP is that you need more than one It It takes two to DAP. So, uh right.

**Tim Geoghegan:** So, for example, in um in our deployment at work with Mozilla, both aggregators are Janus. Um, so that's, you know, you still get the MPC group, right, and the organizational independence, but it is one implementation.

**Benjamin Schwartz:** Okay. Um, one thing I would say, uh I guess the question here, right, is do we want to hold further progress of the document on proving that there are two implementations that the that can talk to each other? All other things being equal, I would say yeah sure, but the thing is, um short of somebody actually committing to do that implementation, um I'm I'd be reluctant to block further future progress of the document on, um you know, somebody committing to do that.

**Benjamin Schwartz:** Okay.

**Martin Thomson:** Yeah, I I don't think it's worth doing that at this point. I think there's there's a lot of value a lot of the value that's derived from having DAP is in the protocol. Um, the fact that there is a published protocol means that other people can go go ahead and implement something. Um, but uh blocking publication, I know that we do that in some other cases, um we want to prove out that that something works before it becomes an RFC, but I don't know that that's ever been a requirement at the IETF, and you know, if it turns out this this is a a massive boondoggle and doesn't doesn't end up being successful, then that's one thing, but we know that DAP is in use. People are using it for real stuff. So, um I think that that aspect of it is is not a concern for me. So, ship it.

**Christopher Patton:** Just going to suggest that a cheap thing to do would be to um just to just to I don't know if any anyone at IETF has done this yet, but you could vibe-code an implementation and uh and try interop with Janus just to make sure a description of the protocol from the draft translates into a code that interops with Janus. That's complete That's woefully incomplete, but it also might have other benefits of like looking at the, you know, editorial changes that might be made.

**Martin Thomson:** I know the people have done that sort of validation on other drafts, um but I don't know that it's worth the tokens in this case. It's not cheap.

**Christopher Patton:** Yeah, I agree, it's it's expensive. And probably wouldn't teach us much.

**Benjamin Schwartz:** All right. So, uh as I said, we we wanted to switch here uh on our agenda bash from talking about recent changes to talking about next steps.

**Tim Geoghegan:** I mean, oh wait, let me get in the queue. There. Um, I think we all already kind of are just now talking about that, right, since we we came at it from the point of view of like what would be the milestones or validation we'd like to do before moving forward. Um, but I I agree with Martin, um and Chris, in that uh yeah, I think we should uh move forward here. Um, there's there aren't any changes that we're aware of needing short of this uh this one pull request that uh David has up that I think should be able to be taken smoothly. Um, but otherwise, I think we should we should go ahead with this this draft.

**Benjamin Schwartz:** Okay, um

**Benjamin Schwartz:** So, as a matter of process, um there's a question of of what we actually need to do. But, at a minimum, um there's uh we need we're going to need at least DAP 20 with these essentially editorial adjustments. Um, so, uh DAP currently has the or maybe it's 19 if 19 hasn't come out yet. Um, so, uh DAP has the state uh working group consensus waiting for write-up. So, my understanding is that means that, in principle, we have the ability uh to take the next revision without further process and and the chairs can simply declare that the uh that the the next version, the DAP 19, represents the result of the working group last call, and it can move forward. Or, I guess, we could rerun a last call given that there are a bunch of very substantive changes um since the previous last call. Uh, does anybody have a thought on which path they'd like to see this go?

**Christopher Patton:** Oh, I would say um, I would say I would say the first last call failed because um there were, you know, Martin had all of his stuff that he wanted to change. Um, I think it's appropriate to do a second second last call, and obviously, we don't expect much feedback, but you might as well run it again. Um, uh, like it's just seems like the appropriate thing to do, and I don't think we're like, you know, waiting a few weeks is is is is going to hold us up on any on anything, so.

**Benjamin Schwartz:** All right. Uh, Tim.

**Tim Geoghegan:** I was going to say the opposite, but actually, Chris just changed my mind. Uh, he uh Chris, you're right that, since we never did get like a formally passed last call, we should kind of tick that box. So, yeah, I think we should I think it's wise for us to do that. I suspect that we're going to get the answers we're going to get are going to be like a subset of the people who are in this room today, um but that's fine. That's, you know, that's PPM. Um, one thing I'll note, okay, never mind. Sorry, um I was in the background, I was asking JC whether this uh whether we had done this one thing. I wasn't sure that we had done it, but we did in fact land that one protocol change, so that's fine. So, yeah, um excuse me. To sum up, we think the document's in good shape. Uh, let's do a last call.

**Benjamin Schwartz:** All right. Um, I think this is the end of this topic and we can move on to Martin's segment of the meeting. Does anybody have any last words on DAP for the moment? All right, Martin.

**Martin Thomson:** Incoming. So, there there's a screen share on request open. I'll see if I can make that work. Ah, geez. Someone needs to improve the UX on this one, and that is entirely me. Um, Oh look, it worked. We need previews on these things. So, this is this is the kind of the key snippet from the draft that I've put together. I hope a few of you have at least read this uh ahead of the meeting. Um, the top diagram here is essentially a caricature of of how you would you would run DAP today as it is described in the in the main draft. You have a bunch of clients, they submit reports, and uh the leader and helper do some stuff to validate them and and aggregate them. And then you have a collector that uh periodically comes in and says, "I'd like a collection, please. Give me give me some results." And it's effectively a request-response exchange, and either the leader has an aggregate already prepared, which would be the case for things that happen on a on a regular basis like uh um the the scheduled batching, or the leader would then in response to to the request from the collector go off and do the validation and aggregation depending on on how things are structured. And so, this is the the DAP that we know and love. 

**Martin Thomson:** The architecture below is basically the same, um except that um in this case, we have um for attribution, we've sort of decided to take the the aggregators, the leader and the helper, out of the the critical path for the gathering of reports. And that was deemed uh important for operational reasons, uh it seemed like people who are in the adtech industry were reluctant to put a a browser-selected aggregation service on the critical path for their the handling of their their attribution reports. Um, but probably the main thing that this one does is it gives the collector the ability to choose which reports end up going through for aggregation. And so we have a a different structure here, but it's it's still fundamentally the same. The batch reports go via the collector, in this case, it's the website that you're visiting, um but then the same the same basic architecture applies for the the collection job. And so, um this would be the major major change that we would we would be asking for in attribution, and the nice thing is that the DAP doesn't require any fundamental changes to make this sort of thing happen anymore. DAP's in a pretty good shape to to be able to handle what we need, uh but it does need a couple of extensions. And that's uh that's the the the wonderful thing about the changes that we have in in DAP. We can just move on to the extensions. 

**Martin Thomson:** And so, um probably the most important one is this collector-selected batch mode, and in this one, essentially, the um the collector says, "For this particular task, I choose, not the leader, not um not we're not choosing based on timestamp, I'm choosing which reports go in each batch." And um the the key uh to to making that happen is that each collection job is given an identifier that follows the pattern from the draft, and the um the jobs the individual reports are submitted to a particular URL which encodes the collection job in order to make that happen. So, that gives the collector the ability to associate reports with a particular collection job that they've initiated, and that essentially gives them the the level of control that they need. And that was unavoidable, uh we didn't want to make any changes to the the report, so it seems like the URLs are a very easy way to to do that. And so that's just uh a new batch mode that we have defined um in this and and that follows all the existing batch mode definition stuff, and it makes this one change to the protocol which everyone agrees to. So, that's fine. Uh, there's a bunch of plumbing stuff in here which I think you can ignore. 

**Martin Thomson:** And so that's the that's the the the operational side of these things. Now, you have a system where the the websites can decide which reports make it through into aggregation, and uh they get their report their aggregates based on that one. So, um the other um the other ones are more interesting and and much more specific to the attribution case. We have uh differential privacy budget extensions, uh which essentially says that um uh two things. Um, one is the the task is configured with a a privacy budget. No, it's a report. Each report is is um has a privacy budget expenditure in epsilons. Um, that's attached to each one, and we do that in micro-epsilons so that there's a a degree of flexibility. Uh, obviously, micro-epsilons going up to 4000-odd is going to give you a pretty much the entire range over which anyone could conceivably want to um to do this um sort of budgeting stuff. And uh that is done on a report per-report basis rather than a task basis, uh because we wanted some amount of flexibility. There's a bunch of discussion around that that we had in the in the advertising technology working group meetings around this. The primary reason being that you don't want to pre-commit to a particular privacy budget on the part of the advertisers who are who are driving this system because if they make a mistake, it becomes very expensive to correct mid-stream because you can't mix um different task configurations together. You basically have to commit to that for a for an extended period. And so, if they change their minds, then um they they would basically lose all of the reports that they had collected, all that they had gathered from the from the the browsers, and they would be unable to use them potentially. So, um we've given that. 

**Martin Thomson:** And that's associated with a feature that uh applies here, which is effectively a minimum privacy budget, that uh is associated with each one of the reports in a batch. And so, if you are talking about collecting a thousand reports and you're concerned that you accidentally put a very very small amount of privacy budget in one of them, uh you don't want the privacy budget that's associated with that one report to cause the aggregators to add differential privacy noise uh based on that very very small budget, which would blow the noise out beyond your expectations. And so, this is a safeguard, um that uh that exists around all of that, uh the safeguard being to to cap the noise that's associated with anything. And and the result is that any report that exceeds this cap, or rather, is below this cap, gets dropped from the from the aggregation. And so, you don't have to have to add extra noise as a result. Um, and then finally, we have this collector identity uh task extension, which binds the task to a particular identity. And that was considered very important in the in the web case because if you have two websites collecting reports that have exactly the same shape, it would otherwise be possible to aggregate those into the same thing and because there's only one amount of differential privacy noise being added, there's the possibility to abuse that and uh effectively halve the amount of noise that's involved if the website has the ability to correlate all of these um these things. Um, and that also applies to that probably applies more more to this budget source extension, which is the one that the the attribution API uses specifically to to prevent that. I think that's all of the things that we had. There's a bunch of discussion around these last two ones that I think will be very interesting to to have, so happy to to answer questions around around those. Oh, I should say, I'm asking for adoption for this work, in case that was not abundantly clear. I I think this is uh certainly the private advertising technology working group considers this to be quite important and would like to see it happen, so um that's me forwarding a request from them.

**Sam Weiler:** We have Sam. Sam.

**Sam Weiler:** Asking not as chair but as a naive observer. Um, what do the operating mode extensions do to the privacy properties? As in, could the collector, by behaving maliciously, expose the answers from any one piece of uh piece of collected data?

**Martin Thomson:** Yeah, so the the primary protection that we have in the system is the differential privacy noise, and so there's uh an implication that when you use the differential privacy budget extensions, that those are understood and that comes through as differential privacy noise. Um, that is the primary mechanism that we use. So, in that case, even if you just have a single report going into an aggregation job, the differential privacy parameters ensure that the the output of the aggregation is differentially private uh to that level. And so, the amount the amount of information that the that an attacker, the collector in this case, gains is is strictly bound by the differential privacy guarantees. Obviously, you can put other other task configuration things in there to to make that stronger. I think we are recommending a relatively low minimum batch size for for attribution, but you could you can adjust that to to match your the your needs under this.

**Sam Weiler:** Thanks. Thanks for that clarification.

**Martin Thomson:** Tim.

**Tim Geoghegan:** Thank you. Um, okay, a few things to say. Uh, first off, Martin, I think I sort of volunteer you to present today, so I just wanted to, you know, apologize and thank you for uh presenting this stuff to us. Perhaps on short notice. Okay, then, would you scroll up just a bit back to um collector identity uh task extension? Yeah. Um, okay, I think I saw a "must" go by in here, big bold "must" that addresses me. Okay. So, the idea here is that you have some string, some byte string that identifies a collector in the task configuration, so everybody gets to see who the collector is. But, also, excuse me. Yeah, all right. Okay, sorry, I think I've the two musts in this paragraph, like this also means that there's got to be some way, right, that the aggregators can verify not just that this string exists, but that actually like the collector controls it or, you know, they'll verify some authentication token or they'll hit some like reasonable URL for the given collector, something like that. Um, yeah, okay. So, so besides configuration.

**Martin Thomson:** It could be configuration. It could be configuration in this case. You you know that this string means this party and that's that party has this particular key configuration, or this is the way you get the key configuration for that party. It doesn't need to be strictly defined. In the case of the um the attribution API, the collector identity is the website that makes the request on the API. The budget source is the top-level website that's associated with it. So, you might imagine that um the uh budget source is the merchant that someone's visiting who's done some attribution, and the um collector identity is some adtech that they're using to to do the ad placements. That's the that's the basic model, and these are both website identities and we have spelled it out in the attribution API exactly how to spell these and how to how to correlate everything.

**Tim Geoghegan:** Yep, I remember that. And there's there's also an interesting thing there where like there's the impression site or the conversion site like JavaScript, but then there's the trusted part of the browser which in fact makes a lot of decisions about how to do DAP stuff. The unfortunate thing, I guess, is that short of like some attestation story, the aggregators can't do anything with the notion of like, you know, this piece of code was trusted browser, this piece of code was JavaScript. But, um nonetheless, I thought I had a point. Uh, the point I do want to make is, um I think this work is good, um I support it for largely the reasons Martin said, like there's a there's a very clear need uh for this at PATWG. There are I like I don't know I don't think W3C adopts documents in quite the same way, but like the the attribution level one stuff is, you know, moving forward. It's substantial, it's real, it needs this, and I think that uh, you know, I think it's incumbent on us at PPM to do this to enable um PATWG's work. Um, you know, on top of that, we already did adopt um the L1 bound sum V-DAP, which also is motivated by like this work overall, um and we put the extension points that we just discussed earlier into DAP. They're a good idea generally, but specifically they're motivated by enabling this. So, um it would make very little sense to me for PPM to not adopt this document. Thank you.

**Christopher Patton:** Yeah, um

**Martin Thomson:** Christopher, you're on.

**Christopher Patton:** Oh, uh okay, good. Thanks.

**Christopher Patton:** Um, I I agree, um and this doesn't seem hard to review, so I'm happy to review it. Uh, the question I had, I'm curious how far along implementations are. So, Janus is, what about on the uh what about in the on the adtech end of things?

**Martin Thomson:** That uh I understand is is in progress, um but uh I can't speak for for others in this case. Our implementation is um we we have not implemented any of these things. We have hacks to work around all of this in in our current implementation. We're using like I think some veg or something, which requires all sorts of contortions in order to make work properly because you have to do um we've got some weird assumptions about how we bound the L1 norms and and all sorts of things and the batch modes are inflexible and it it's it's kind of awful. Um, so, I think um I can only speak to intent there, um but I can't speak to the other browser implementations on this one, although I might infer that there's a great deal of interest in that because we we basically finished with with attribution level one. There there is discussions about level two at this point, because level one's out for review. Um, haven't got anything major yet, but um we'll see how that works out. Oh look, Mark's in the queue, that's great. Mark might have some more to say. I doubt it, but.

**Benjamin Schwartz:** Uh, okay. So, I just um just trying to understand this a little bit. The the privacy budget extension is inside the report in encrypted envelope. Is that right?

**Martin Thomson:** Uh, it's a public extension in the report. It's not It It's something that both leader and helper see in the clear uh in the way that we do the typical report extensions. It's not It's not the hidden ones.

**Benjamin Schwartz:** Okay. Does the collector set it?

**Martin Thomson:** Uh, the collector I think I think exactly how they work. Damn it. Um, I think so. They certainly set it in the API on the attribution side of things. They decide how much the value is.

**Benjamin Schwartz:** That's the so the collector sets the the minimum privacy uh minimum privacy budget on the task, you said.

**Martin Thomson:** Yeah, so in in the collection job, they set a they set the minimum budget, but they also when the when the report is generated, they say, "Please generate generate a report, and here's how much privacy budget you should spend at a maximum." And that value goes through in the report.

**Benjamin Schwartz:** Am I using the wrong word? I thought the report is what goes up from the client.

**Martin Thomson:** Yep. Yep. So, the collector's in control of of determining when a report is generated in this API.

**Benjamin Schwartz:** Okay. I'm I'm trying to I guess I would have thought My mental model here is that the privacy budget is something that's set by the client, and the website can't override it.

**Martin Thomson:** There's there's multiple layers to this because of the the differential privacy design that we have. So, the the browser, the client, has a privacy budget. Right. That will be some number that will be determined by whoever builds the browser. And that might be five, for instance. And the website can spend that budget by asking the browser to generate reports. And it says, "Please spend one." And the browser will spend one, deduct that from the budget that it tracks, and then the report goes up. It's a bit more complicated than that, but that's the that's the basic arrangement. And then, when it arrives at the aggregators, the minimum is there as a bit of a safeguard to say if the budget if the value's too low in the report, throw it out because that would contribute too much aggregating over that would end up contributing too much noise to the to the final, which would blow the noise out beyond your expectations. And so, this is a safeguard,

**Benjamin Schwartz:** Okay.

**Martin Thomson:** that uh that exists around all of that. Uh, the safeguard being to to cap the noise that's associated with anything. And and the result is that any report that exceeds this cap, or rather, is below this cap, gets dropped from the from the aggregation. And so, you don't have to have to add extra noise as a result. Um, and then finally, we have this collector identity, uh task extension, which binds the task to a particular identity. And that was considered very important in the in the webcase because if you have two websites collecting reports that have exactly the same shape, it would otherwise be possible to aggregate those into the same thing. And because there's only one amount of differential privacy noise being added, there's the possibility to abuse that and uh effectively halve the amount of noise that's involved if the website has the ability to correlate all of these um these things. Um, and that also applies to that probably applies more more to this budget source extension, which is the one that the the attribution API uses specifically to to prevent that. I think that's all of the things that we had. There's a bunch of discussion around these last two ones that I think will be very interesting to to have, so happy to to answer questions around around those. Oh, I should say, I'm asking for adoption for this work, in case that was not abundantly clear. I think this is uh certainly the private advertising technology working group considers this to be quite important and would like to see it happen, so um that's me forwarding a request from them.

**Benjamin Schwartz:** And the other element of that was if you have some number of reports and some of them fall under the minimum privacy budget and get excluded, does that cause your job size to fall in a way that would cause you to fail the job size threshold?

**Martin Thomson:** Absolutely. Yes.

**Benjamin Schwartz:** Okay. Uh, thanks for helping me to understand that. All right. Um, Mark.

**Mark Blunk:** Hi. Yeah, I was wondering, the the batch, sorry, the collector-selected batch mode, I'm probably getting that name wrong. So, that, yeah, it seems like almost everything else in this extension, or in this document, is related to differential privacy, which makes sense, but then this one thing is not. Is it rel- I, yeah, I don't know. Like, could you separate these out as two concepts that are are detached from each other, or is it like, no, they are interlinked in some very deep way?

**Martin Thomson:** Um, as much as possible, I tried to make these individual extensions um decomposed. So, you're right, this one doesn't really relate to differential privacy, except very tangentially, in the sense that um it a lot of the modes that we presently have are based on a particular model of of aggregation, effectively shuffle DP would be a reasonable way of of thinking about the model that the DAP sort of operates under generally, although in some cases, you're not actually adding any differential privacy noise at all, um but the the collector-selected version of this does require um that's sort of an assumption of central DP or something like that. And so, the this is much more suited to the the DP thing. So, everything here has some connection through to the differential privacy questions, but I think, fundamentally, this really is just a collection of things that are that exist to support the um the modes that we're using in the in the attribution API. Hence, the the draft, and that sort of thing. Yeah, cool. Makes sense. Thanks. Yeah.

**Tim Geoghegan:** I have, uh, couple of things. First, I guess, in response to Mark, I recall we did approximately a million years ago, uh, talk about whether these extensions could could or should be carved up into individual drafts, individual individual drafts. But, we what we agreed, for some value of "we," was that would just be like more paperwork, more repositories, more versions to to you know, to wrangle. And we just agreed, like, it'd be easier to just do them all in one document. Um, and yeah, which makes sense to me, since, as Martin just laid out, they are like, you know, thematically connected. Um, the theme of "this is the stuff that DAP needs to enable um, L1" seems perfectly valid. Um, second thing is, which I should have said earlier, I um, we at Divviup are very, very likely to implement this stuff in Janus, at least like, you know, the the portions that are pertinent to aggregators. Um, so I guess that goes to the the adoption question, right? Like, we we will not just um, review the document and provide feedback, uh, I think we will go and implement this stuff.

**Martin Thomson:** Hopefully, it's not too hard to implement. I think, as much as possible, we I think the difficult one here is the collector um, that, the batch mode, which does change the the structure of the system that you're building. I don't think it fundamentally changes the the architecture of DAP, it's just that it's a it's a bigger lift than the rest of the things which are often just extra attributes.

**Tim Geoghegan:** All right. Thank you, Martin. We, from our agenda bash, we have another topic to switch to and that is task-prov. So, uh, does anybody want to try to explain where we have gotten to with task-prov?

**Christopher Patton:** Chris, I hit the button first, but like, if you would, if you, as an author, if you'd like to go. Okay. Fair enough. So, okay, we touched on some of this earlier when I was discussing like what is changed in DAP, right? And the big thing is that task binding has moved to DAP itself. Um, but the thing is task-prov still has the uh, in-band, uh, dynamic task provisioning mechanism in it. Um, and that thing is actually still useful. Um, in fact, we have, uh, in Janus at Divviup, we have implemented it, and we are using it in production now. So, um, I think it makes sense to, uh, tidy up that doc, clean it up, sort of re-sync it with DAP, um, and uh, continue moving it along. Because, um, it it does still provide a meaningful, like, extension, right? Addition, uh, to DAP that people have shipped and that we, and there are two, at least, implementations of it out there.

**Christopher Patton:** Um, so, I certainly don't object to publishing something. I just don't know exactly what it is we're publishing. Um, so, there's one point, I think, we did not totally agree on, and I'm just I'm going back and looking at the, okay, there's no open pull requests. Um, I don't know if the issues are going to be particularly insightful on this, but let me see. Probably, probably 126 is what you want to look at, because that was the last closed pull request, where we moved a bunch of things. Remove task-prov. Yeah, that was the big that was Tim's change. Thank you, by the way, for that, Tim. Um, so, there is a so, there's so, the the task advertisement is a useful thing. Um, I can see a doc that just says like, "Here's a header. Like, this is" that defines the header and says what the content is, which is a task configuration. Um, and that's one thing. The other thing is does there need to be a DAP extension? Um, so, that could be a report extension, which, the the semantics of which would be unclear. Previously, it meant like, if the report has the extension, then what did that precisely mean? It meant that you were to reject the report if if uh, what exactly?

**Tim Geoghegan:** Well, I think the idea was that we wanted to make sure that every participant acknowledged and agreed that task-prov was in use. And the question, which I believe I recall Martin raised, was what actually what actually bad thing happens if some protocol participant runs a task that was provisioned through task-prov, and they don't happen to know that. Like, does it really make a difference to the security of V-DAP or like, you know, any of the other extensions or anything like that?

**Christopher Patton:** Well, it it previously indicated like, a task misbinding, so like, if you if you, um, it was and and it was like, our only we didn't have like, task extensions at the time, so I think this is it makes more sense as a task extension that says like, "If the" if the task ID doesn't match is not equal to the hash of the task config, then, um, reject the report, or or reject the task that you're being asked to do, the job you're being asked to do. Um, and, in, but now that's kind of like, baked into DAP, so the question is like, yeah, what would be I I can't think of a I can't think of a bad thing that would be prevented by having a task extension. Um, I'll stop rambling. Go ahead, Martin.

**Martin Thomson:** I don't know why I'm not sending video, hopefully, I'm sending, um, audio. The, basically, it was always possible for someone to take the task configuration that they know, and confirm whether or not the task ID that they have, which they have to agree with everyone, uh, in order to participate, matches, using whatever process is defined in task-prov. It was always possible to to do that. With the changes to DAP, it just becomes even more possible to do that because everyone is able to, um, to make this confirmation. So, um, I think, I think having an having no extension actually makes it better because it means that everyone who's using task-prov or not, doesn't really care how the task came into existence. They just, we'll agree that the that the task configuration is this, the task ID is this, everyone agrees, and, um, DAP is effectively safe by default, which is a really nice property to have. So, um, I think, I think having no extension is is fine. There's a bunch of plumbing stuff in here which I think you can ignore. And so, that's the that's the the the operational side of these things. Now, you have a system where the the websites can decide which reports make it through into aggregation, and uh they get their report their aggregates based on that one. So, um the other um the other ones are more interesting and and much more specific to the attribution case. We have uh differential privacy budget extensions, uh which essentially says that um uh two things. Um, one is the the task is configured with a a privacy budget. No, it's a report. Each report is is um has a privacy budget expenditure in epsilons. Um, that's attached to each one, and we do that in micro-epsilons so that there's a a degree of flexibility. Uh, obviously, micro-epsilons going up to 4000-odd is going to give you a pretty much the entire range over which anyone could conceivably want to um to do this um sort of budgeting stuff. And uh that is done on a report per-report basis rather than a task basis, uh because we wanted some amount of flexibility. There's a bunch of discussion around that that we had in the in the advertising technology working group meetings around this. The primary reason being that you don't want to pre-commit to a particular privacy budget on the part of the advertisers who are who are driving this system because if they make a mistake, it becomes very expensive to correct mid-stream because you can't mix um different task configurations together. You basically have to commit to that for a for an extended period. And so, if they change their minds, then um they they would basically lose all of the reports that they had collected, all that they had gathered from the from the the browsers, and they would be unable to use them potentially. So, um we've given that. 

**Martin Thomson:** And that's associated with a feature that uh applies here, which is effectively a minimum privacy budget, that uh is associated with each one of the reports in a batch. And so, if you are talking about collecting a thousand reports and you're concerned that you accidentally put a very very small amount of privacy budget in one of them, uh you don't want the privacy budget that's associated with that one report to cause the aggregators to add differential privacy noise uh based on that very very small budget, which would blow the noise out beyond your expectations. And so, this is a safeguard, um that uh that exists around all of that. Uh, the safeguard being to to cap the noise that's associated with anything. And and the result is that any report that exceeds this cap, or rather, is below this cap, gets dropped from the from the aggregation. And so, you don't have to have to add extra noise as a result. Um, and then finally, we have this collector identity, uh task extension, which binds the task to a particular identity. And that was considered very important in the in the webcase because if you have two websites collecting reports that have exactly the same shape, it would otherwise be possible to aggregate those into the same thing. And because there's only one amount of differential privacy noise being added, there's the possibility to abuse that and uh effectively halve the amount of noise that's involved if the website has the ability to correlate all of these um these things. Um, and that also applies to that probably applies more more to this budget source extension, which is the one that the the attribution API uses specifically to to prevent that. I think that's all of the things that we had. There's a bunch of discussion around these last two ones that I think will be very interesting to to have, so happy to to answer questions around around those. Oh, I should say, I'm asking for adoption for this work, in case that was not abundantly clear. I think this is uh certainly the private advertising technology working group considers this to be quite important and would like to see it happen, so um that's me forwarding a request from them.

**Christopher Patton:** Just to point out there's one more thing this draft is doing which is uh derivation of the V-DAP verification key is explicit.

**Martin Thomson:** Which, by the way, I think is a great feature, uh. It would have been nice to get that into DAP proper as well, seems like all of task-prov is slowly migrating into DAP. It doesn't need to migrate into DAP uh, in this case, but I think it's a useful thing to to have, uh because it means that then you've got a looser coordination. Uh, so, I think it's a useful useful property to retain in the draft.

**Christopher Patton:** Yeah, it's worth it's worth kind of noting here, like similar to the the attribution draft, where like, we have a bunch of things that we're doing for a single-use case. I kind of view task-prov that way. There was like, a deployment scenario that was envisioned, and there was a few different things that we wanted to do within that deployment scenario that made sense, so um, yeah. Ah, Tim, go ahead, sorry.

**Tim Geoghegan:** Yeah, um, I just want to plus-one on to Martin's point. Uh, because it occurs to me, so, in Divviup, we have like, uh, an unspecified, you know, non-standard mechanism for provisioning tasks. Basically, you know, we have an API that sits in front of our DAP aggregators that users can hit to provision a task, and then it goes out to leader and helper. Um, and the thing is, we don't have anything in that in like, in the task configurations of tasks provisioned in that way to tell you how they came to be, and yet we've never really had doubts about whether they're secure or whether like, whether that's okay. So, um, yeah, so it makes sense to me that we don't really need an extension just to indicate that task-prov was in use. So, I would, I guess, I would get my vote on record for, uh, removing the task-prov extension.

**Christopher Patton:** So, I think at the end of the day this day, um, I could screen share, by the way, I'm just I'm just looking at the draft. Section three goes away, that's the task-prov task extension. In-band task provisioning, that's that's the main thing it does. And that kind of has two main components, which is the header, and the verification key, and then, um, I don't know if the section 4.4 still makes sense, uh, opting into a task, we'll have to kind of review that. Um, I think what I can do is, if everyone likes that plan, I I could sit down and, um, I'll I'll do a PR where like, I just go through the whole doc and kind of rework it with that vision in mind. Um, and we can review it and land it, call it a day. So, that'd be my proposal, proposed way forward.

**Tim Geoghegan:** Uh, sounds good, and uh, I'm happy I'm happy to help review changes if you need.

**Benjamin Schwartz:** All right. Um, thanks, everybody. Uh, I feel like we've covered a lot of important stuff, very productive. Um, look out for some uh some updates about working group last calls, seems like we've got uh a few potential working group last calls that chairs will work through exactly how to deal with that, and uh and please uh continue to engage on the mailing list, and hopefully, we're getting close to some pretty good milestones here.

**Sam Weiler:** Are did we just say, for Martin, you were talking about deriving the V-DAP verification key, and wanting to slide that into DAP, are you okay not sliding it into DAP?

**Martin Thomson:** Yeah, I think I was arguing for not not putting that into DAP. DAP presently assumes that the leader and helper work out what the verification key is ahead of time, and that's fine. Um, the the task-prov version is stronger, I think, in the sense that it requires less coordination, um but it does create uh some interesting questions for analysis, and I think that work has been done, but it doesn't need to block DAP moving forward. Thank you. Thanks for that clarification.

**Christopher Patton:** Before we go, I just wanted to clarify a few things. Um, so, I think last call for DAP is appropriate. Um, what other things are we doing last call on? The L1 norm ban, I haven't reviewed that in a while, but that's that I can imagine that's probably pretty close to done. Um, task-prov definitely needs more work. Uh, and then we have an adoption call for the attribution stuff, and I think we still need to that's one we're just going to do one draft for that, we decided?

**Martin Thomson:** So, my my position is that the um that DAP is like almost done. As in the sense that, well, last call it, and I don't expect any comments. Uh, task-prov needs that revision, um and will need a little more bake time. L1 norm bound, from my perspective, and David can correct me, that is that is baked. There's the there is only one open question, and it's not necessarily one that we need to resolve, um which is whether we want to go with the 128-bit field or the 64-bit field and three proofs rather than one. Um, that is a question that I have open for Ben Case, who um has is looking into it. Once we have an answer to that, and I expect the answer to to just be "carry on," um once we have that answer, then I think we'll we'll last call makes sense. Yeah.

**Tim Geoghegan:** Uh, I I think I agree with Martin on all points. Um, I hadn't thought about L1 norm bound, but yeah, we should last call that once once we get confirmation from uh Benjamin Case that uh we're happy with the field. Another option there, we should try not to do this, but another option there would be to introduce two flavors of L1's uh bound sum that use uh that let deployments choose either field.

**Benjamin Schwartz:** All right, thank you, Martin. We, from our agenda bash, we have another topic to switch to, and that is task-prov. So, uh, does anybody want to try to explain where we have gotten to with task-prov?