Skip to content

Commit bc13320

Browse files
Create 2025-02-26-FLEDGE-call-minutes.md
1 parent 65d9679 commit bc13320

File tree

1 file changed

+148
-0
lines changed

1 file changed

+148
-0
lines changed
+148
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
# Protected Audience WICG Calls: Agenda & Notes
2+
3+
Calls take place on most Wednesdays, at 11am US Eastern time; check [#88](https://github.com/WICG/turtledove/issues/88) for exceptions.
4+
5+
That's 8am California = 5pm Paris time = 3pm UTC (during summer)
6+
7+
This notes doc will be editable during the meeting — if you can only comment, hit reload
8+
9+
Notes from past calls are all on GitHub [in this directory](https://github.com/WICG/turtledove/tree/main/meetings).
10+
11+
12+
# Next video-call meeting: Wednesday February 26, 2025
13+
14+
(February 19 was cancelled because no agenda items)
15+
16+
To be added to a Google Calendar invitation for this meeting, join the Google Group https://groups.google.com/a/chromium.org/g/protected-audience-api-meetings/
17+
18+
If the meeting disappears from your calendar: try leaving and re-joining that group
19+
20+
21+
## Attendees: please sign yourself in!
22+
23+
24+
25+
1. Michael Kleber (Google Privacy Sandbox)
26+
2. Jason Lydon (Innovid)
27+
3. Brian May (unaffiliated)
28+
4. Matt Kendall (Index Exchange)
29+
5. Phil Acker (Amazon)
30+
6. Fabian Höring (Criteo)
31+
7. Garrett McGrath (Magnite)
32+
8. Paul Jensen (Google Privacy Sandbox)
33+
9. Orr Bernstein (Google Privacy Sandbox)
34+
10. Sathish Manickam (Google Privacy Sandbox)
35+
11. Laurentiu Badea (OpenX)
36+
12. Jeremy Bao (Google Privacy Sandbox)
37+
13. Bharat Rathi ( Google Privacy Sandbox)
38+
14. Kevin Lee (Google Privacy Sandbox)
39+
15. Alonso Velasquez (Google Privacy Sandbox)
40+
16. Suresh Chahal (MSFT Ads)
41+
17. Trenton Starkey (Google Privacy Sandbox)
42+
18. Kenneth Kharma (OpenX)
43+
19. Alexander Tretyakov (Google Privacy Sandbox)
44+
20. David Dabbs (Epsilon)
45+
21. Sid Sahoo (Google Privacy Sandbox)
46+
22. Tal Bar Zvi (Taboola)
47+
48+
49+
## Note taker: Sathish Manickam
50+
51+
52+
# Agenda
53+
54+
55+
## Process reminder: Join WICG
56+
57+
If you want to participate in the call, please make sure you join the WICG: https://www.w3.org/community/wicg/
58+
59+
Contributions to this work are subject to W3C Community Contributor License Agreement (CLA) which can be found here: https://www.w3.org/community/about/process/cla/
60+
61+
62+
## Suggest agenda items here (meetings with no items may be canceled):
63+
64+
65+
66+
* [Jeremy Bao] Deals: Share the proposal on allowing sellers to query deal ID metadata through K/V server during scoreAd(): https://github.com/WICG/turtledove/issues/873#issuecomment-2652255187
67+
* [Phil Acker] What is the latest status of the dial-up plan for Real Time Metrics and Extended Private Aggregation reporting metrics rollouts?
68+
* It looks like RTM should be fully dialed up after launching with Chrome M132 in January (https://github.com/WICG/turtledove/issues/430#issuecomment-2590916564).
69+
* [Paul Jensen] RTM was rolled out with M129 to all but Mode A & B: https://github.com/WICG/turtledove/issues/430#issuecomment-2397357734
70+
* [Paul Jensen] RTM was rolled out with M132 to all traffic: https://github.com/WICG/turtledove/issues/430#issuecomment-2590916564
71+
* Has the Extended PA metrics also fully rolled out? (https://github.com/WICG/turtledove/blob/main/FLEDGE_extended_PA_reporting.md)
72+
* [Paul Jensen] Extended PA metrics were rolled out a while ago (2023?). We have added some features more recently: https://groups.google.com/a/chromium.org/g/blink-dev/c/F0GAisJlomc/m/aoD_b_CX[AAAJ](https://groups.google.com/a/chromium.org/g/blink-dev/c/F0GAisJlomc/m/aoD_b_CXAAAJ) which are rolling out; the roll out status can be followed on the related GitHub entries, e.g. https://github.com/WICG/turtledove/issues/1151#issuecomment-2631433357
73+
* [Phil Acker] Are there any updates about Chrome’s Elevated CX for controlling cookies?
74+
* Fabian Höring Discuss https://github.com/WICG/turtledove/issues/1361#issuecomment-2666429313
75+
76+
77+
# Announcements
78+
79+
Privacy Sandbox folks are holding every-second-Wednesday meetings in the hour after this meeting to discuss the trusted server elements of Protected Audience work. For more information see https://github.com/WICG/protected-auction-services-discussion/issues/27.
80+
81+
The Microsoft Edge folks are holding every-second-Thursday meetings at this same hour to discuss their very similar "Ad Selection API" work. See https://github.com/WICG/privacy-preserving-ads/issues/50 for logistics.
82+
83+
Everyone is responsible for checking the accuracy of the notes doc, especially the part with their own comments - so go back later and make sure the notes are accurate. You can even fix them on Github later!
84+
85+
86+
# Notes
87+
88+
89+
## Jeremy Bao: Update on Deals https://github.com/WICG/turtledove/issues/873#issuecomment-2652255187
90+
91+
92+
93+
* Proposal: Allowing selectable buyerAndSellerReportingIDs as a key in trusted Scoring signals.
94+
* We have heard from sellers that in PA they may have to preload the metadata, which is not ideal. We were requested so add to the signals. Requesting feedback
95+
* Matt Kendall: Agree with the proposal being useful.. Can the ordering of the IDs be matched to the renderURL?
96+
* Orr Bernstein: Yes, it can be matched. For example the first ID will be matched to the first renderURL etc. It is also the same thing we are doing in Creative Scanning. It can’t be matched, it will be an empty string. If someone wants to select an empty string, as opposed to an empty string is what is available - that distinction is not currently supported, but we can think about it if needed.
97+
* Matt: Not sure the use case where someone needs to select an empty string. We prefer to have it as one-to-one match as well.
98+
* Laurentiu Badea: Some Deals may not have an URL.. so, would it match with comma, comma.. Comma?
99+
* Orr: Yes.. it would be a match with that.
100+
* Kleber: Thanks for the discussion. Github post is available as well for additional comments.
101+
102+
103+
## Phil Acker: Status of Real Time metrics https://github.com/WICG/turtledove/issues/430#issuecomment-2590916564
104+
105+
106+
107+
* Should we assume that it is currently fully rolled out and most users have fully adopted.
108+
* Paul Jensen: A month after a stable roll out it is ok to assume most people have adopted. There will be some people who haven’t yet restarted, so, use feature detection if needed.
109+
* Phil: Do you have any updates on the roll out of the UX?
110+
* Kleber: We don’t cover time or make announcements in this meeting. It will be via the usual public channels.
111+
* Kleber: To follow up on Paul’s comments - Chrom has the concept of Long Term Stable, which is used for large groups to keep it on that version for a longer period of time (not the usual monthly updates). This may stay on for a while, e.g. enterprise sysadmins who want to control browser update cadence for their whole organization. So, you should assume that there will be a set of clients that will not have an update. Best to check the feature detection as needed. And folks are welcome to check the stats if needed.
112+
113+
114+
## Fabian Horing: https://github.com/WICG/turtledove/issues/1361#issuecomment-2666429313
115+
116+
117+
118+
* Could we get some responses to the above post?
119+
* Kleber: Sure.. we can do that. As we see, you have reported on the AB tests, and this is very helpful. Feel free to add more info..
120+
* Fabian: Seller script takes about a second.. Some of this is not clear to us why..
121+
* Kleber: This may need that we need to increase the default timeout.. GAM has already done that. But we can consider this more.
122+
* Fabian: It is an easy fix, but it may have an impact on auction
123+
* Paul Jensen: thanks for putting out these results, quite interesting. First thing to notice is that the reporting timeouts have a greater impact on reports that go out. We increased the default timeout to address this earlier.
124+
* Paul: The second thing is the difference between buyer and seller reports. If you look at the chrome trace, the bidding or generate bid happens first followed by scoread. We run these in separate process for security reasons. It is resource intensive, but the separation is needed. That is the auction side. Right after, we run the report win and report result, it will reuse the processes from the buyers. There is a gap between generate bid, and if it is successful we run the reportwin. Scoread runs separately. This causes some discrepancy in the numbers because the processes for an origin will go away. When we recreate from cache, the processes, it may be slower. This will happen more often for buyers than for sellers. We have noticed it, and we are thinking about.. This difference is likely what accounts for the things you saw in your B - population
125+
* Paul: In your C-population, the reporting timeout does not include the fetch for reporting script. That is why there isn’t a significant difference between b and c population
126+
* Kleber: Thanks for the summary. To recap, there is a relatively simple fix for timeout. And we are also thinking through the process side changes on chrome internals. Thanks for bringing this up, greatly helpful to have these inputs.
127+
* Fabian: It is not just runtime only.. We are interested in getting this to work as best as possible. What about group by origin? Does it apply here?
128+
* David Dabbs: It is for bidding right?
129+
* Fabian: It is in the same javascript..
130+
* Paul: we can’t use this since grouping across origins are not allowed… Combining reporting.. I also recommend going through the protected audience implementation document.. and it will go through a bunch of these details See link:
131+
* https://github.com/WICG/turtledove/blob/main/PA_implementation_overview.md
132+
* Brian May: Is there a sense of an upper bound on the resource pool?
133+
* Kleber: It is at about 10 right now, but if there is a large benefit on how / when to get rid of one, we can think more on this. But at this moment we don’t need that level of optimization
134+
* Brian: Not exactly about optimization, but the number of people participating in the auction..
135+
* Kleber: It is not about the number of people.. Any number can participate.. It is not limiting that..
136+
* David: Thanks for pointing out the document.. But if anything has changed since it was originally created, please update them.
137+
* Kleber: Yes.. some of the optimizations if we incorporate, we will include them. It's a good call out for us to update and others to remind that this may be needed.
138+
139+
140+
## Garrett McGrath: One of the main tenets is that cross-site tracking is not allowed. With User choice cookies, has that changed?
141+
142+
143+
144+
* Kleber: With user choice, if one user wants to have 3p cookies on, and another chooses to have 3p cookies off, the browser is expected to behave differently. When a user chooses to have 3p cookies off, the original tenets will continue to remain. I don’t think any of us are under the impression that disabling cookies will automatically result in the complete end of cross-site tracking. Prevention of cross-site tracking on web platform is an ongoing work. This is only a step along the road, but not the end of it.
145+
* David: The fingerprinting announcement in the public.. Is from the Google Ads, and refer to their functionality. But not a statement from Chrome or Google right?
146+
* Kleber: I am not the expert in Google Ads, so not the best person to talk about. From the Privacy Sandbox side, prevention of cross-site tracking, and promoting privacy is the philosophical goal. This hasn’t changed.
147+
* Brian: Will this also include the IP protection beyond incognito mode?
148+
* Kleber: we have only said about incognito mode. No plans on non-incognito mode.

0 commit comments

Comments
 (0)