Meeting minutes
https://
Agenda-curation, introductions
wseltzer: note side and related meetings in the github issue
Dovekey Auction Q&A (continued)
https://
wseltzer: Gang started to introduce Dovkey Auctions last time
… let's return to that
GangWang: I'll share some more information that I was able to last time
… we have a full-length explainer
… This work introduces a new trusted server that can serve key ad-tech use cases with privacy preserving properties
… we've heard many proposals
… want to explore
… last year we published Dovekey explainer with key-value lookup, simplified version of SPARROW
… hear feedback from industry
… that prompted us to add more functionality
… beyond k-v
… adding utility, enhancements
… Adds: auction capability, with additional features industry requested in GH issues
… this is the first batch of features layered on aution
… [pointing at Intro]
… 2 primary goals: user benefits
… e.g. reducing bandwidth consumption
… cross-domain freq capping so user doesn't have to keep seeing same ads
… and mute-this-ad
… also improving user's ad experience
… Move computation from browser to server, to reduce browser resource usage
https://
GangWang: Second reason is to benefit advertisers and ad tech
… allow bidding price to be precise to improve ROI
… avoid wasting budget (freq capping, mute this ad)
… timely precise budgeting control and pacing required, many issues pointed out
… so we also improve that
… [diagram]
… We add DoveKey server
… SSP and DSP, server-to-server communications
… Ad request in step 1, browser to DoveKey server, composite message w/ 2 sub-requests
… 1 is contextual request generated by SSP's adtech in the browser
… other is IG request that goes to DoveKey server to fetch cached material
… separate contextual and interest group requests, as set by TURTLEDOVE
… So DSP, after receiving contextual request, generates 2 kinds of resposne
… Conditional, based on user data such as IG membership
… e.g. if user belongs to shoes, I'm willing to bid $1.50
… and Unconditional, based on context, might be willign to bid $1
… Run auction among all all unconditional bids, return winner + conditional bids to DK server
… trust model
… aligned such that browser is willing to tell DK server sensitive data of IG membership
… to use to evaluate the conditions associated with conditional bids
… DK server also gets sensitive business information from SSP, such as rev share or business exclusion rules
… DK server applies these rules, runs a combined auction
… resulting in a single winning bid, either the conditional or unconditional
… and sends that single result back to the browser
… browser renders ad, sends reporting back to DK server
… DoveKey server has well-defined functionality and trust model such that browser can send sensitive data there
https://
GangWang: a bit more detail on how we achieve this functionality
[describes Mute-this-ad, as in explainer]
GangWang: general design pattern. if you want to support additional functionalities in DK server
… you can program it to alter availability for auction
… e.g. FCAP
… [describing FCAP]
… [Precise and timely budget and pacing control]
… imagine that when browser renders ads, sends notification to DK server; DK server updates impression count and budget usage, can then throttle auction entry based on budget spend
… and whether impressions are ahead of or behind schedule
… e.g. if campaign is over budget, DK server can block the ad from going into auction
… or, depending on budget, can change the probability of including it in auction
… Micro-targeting prevention
… adds k-anonymity
… based on impression notification, DK server could know how many users have seen ad
… but when a new campaign starts up, how can we recognie that a campaign isn't microtargeting
… inspired by RTB House proposal
… run "counterfactual auction", similar to real auction without k-anonymity rules
… send both ads to browser, browser displays, sends back update to impression count
… DK server could count # of unique browsers who could have seen the ad
… and then, if # greater than k, note that the ad can be shown
… last, improving bid precision
… Allow a limited computation capability in DK server
… buyer specifies a vector for each cached bid
… based on IG
https://
… precise bid price as dot product of 2 vectors
… enable buyer to precisely adjust bid
… How does the DoveKey server earn the trust of vendors
https://
GangWang: a few possible trust models
… auditing
… technical enforcement (secure MPC)
… designed this proposal to be flexible
… ID a small set of well-defined functionality to fit with either model
… I think MPC seems an acheivable goal
… with two non-colluding parties running distinct servers, we can have crypto guarantee that no user data or business confidential data is leaked
… we aim to demonstrate the practicality of secure MPC in the next few quarters, with running code
… to enable industry to assure that when user data is encrypted, nobody but user's browser can see the data
… Disclaimers: MPC is still research in progress, we hope to demonstrate practicality with running code
… This morning, I published another explainer
https://
GangWang: this explainer is the "how"
… describes the cryptography
… that can support the existing proposed functionality
… if you're interested in the MPC how, happy to schedule follow-up
… re crypto design
angelina: when it comes to frequency capping, what level?
… campaign, creative, audience?
… e.g. a group of creatives with multiple sizes?
GangWang: level determined by each buyer and ad network
… you can define a "campaign" at whatever level you want
… and define ID
… the creative gives that ID to the browser, and browser does the counting
… the browser doesn't care the semantics behind the ID, nor the DK server
angelina: if there's a way to carry universal ad ID
… which can mark creatives as grouped on concet
… included in VAST
… From budget standpoing
… will buyers have real-time pacing?
… what's the timeframe from having buyer change bid, budget, and browser update
GangWang: Buyer can reallocate budget from time to tiem
… how quickly DK server can react
… 2 aspects: when buyer reallocates budget, needs to tell DK server
… DK server, when receives impression notification, needs to update budget spend/campaign and current allotted budget
… to know where campaign is in relation to budget
… How quickly DK server can do that process is key
… In follow-up explainer, we have diagram explaining how offline processing works
… because it's done with crypto, don't need to aggregate
… so how quickly can generate a number
… without yet prototyping, thinking 10-15 mins, get down to single digits
angelina: with regard to creative updates, where does the adserver sit?
… when an advertiser decides they want to change, set waiting, sequential messaging, how it's being optimized, may be controlled by adserver, not SSP or DSP
GangWang: short term or long- term
… in short term, you can imagine creative snippet is part of ad response
… may call back to creative server to fetch real creative
… similar to today's creative serving flow
… today, without fenced frame
… longer term, when fenced frame can't call out to internet
… then the creative serving flow will need to change
… instead of returning a creative snippet, step 6 would return actual snippet
… maybe in web bundle, with everything browser needs to render creative
… in that scenario, for buyer to update creative, need to send updated creative to DK server and ask for cache update
… may add delay
… again we need to test prototype
angelina: consider when running a wrong creative can cause financial or legal issues, e.g if an offer changes
GangWang: we did consider DK server "emergency stop" button where could stop serving a particular campaign
bmay: thanks for starting with the what and why
bmay: thinking there's a much higher bandwidth requirement than currently
… how will you handle all that data
… particularly DSP-SSP communication, cache?
… how many DK servers will it take to support current ecosystem?
GangWang: good engineering questions
… first, what's DSP's compute cost and bandwidth cost
… conditional bids will be cached in DK server for minutes or hours
… longer the TTL, the lower computation needed at DSP to regenerate
… so they can reduce their computation by lengthening TTL
bmay: when the DSP responds with conditional bids, are they responding for every conceivable IG?
GangWang: if TTL is 24h, you only need to respond per IG once in 24 hours, so you can pace your responses
GangWang: Next, what's the DK server's storage and bw cost? if every ad requests flows through there
… it needs to sustain a pretty high rate
… getting MPC from theory to practical implementation
… research we've been doing is all about how do we speed up the crypto design
… optimize the design, some detail in new explainer
… how to optimize the server to meet scalability requirements
… more research to come
apireno_groupm: happy to see frequency-capping in-scope
… think about balance between reporting and privacy
… how do you think about the info of someone reaching the cap gets to the advertiser
… will it reach them, or will it jsut be "you lost the auction", or with a lag?
GangWang: in step 1, DK server gets list of IDs
… to block
… exclude those IDs from entering auction
apireno_groupm: so if my creative is being muted, I'd like that signal as an advertiser
… do you imagine some disclosure to the advertiser
… also, am I reaching frequency caps
… how might that info reach advertisers?
GangWang: 2 possibilities
… browser vendors might be willing to enhance aggregate reporting API to share this info
… ask the browsers to put this on their radar
… second, it might be technically possible for DK server to share info aggregated for troubleshooting,
… e.g., why isn't my ad being delivered
… we should probably follow up
rene_baudisch: how is this better than current ad server?
GangWang: the DK server has a trust model acceptable to the browsers to disclose user data
… if we prove the feasibility of the crypto
… Existing ad servers might find it hard to achieve that trust model goal
rene_baudisch: you have to get this reputation on both ends
Mehul: if the adserver is implementing MPC, is there no need for DK?
GangWang: if the existing ad server can implement crypto and get approval from browsers, sure
Mehul: will you cover the crypto in another session
<jrosewell> If there are conditions under which the browser vendor (on behalf of the user) can trust a DoveKey server, should we not also try and define the conditions under which other entities might become trusted?
GangWang: I can ask for a slot for discussion
Mehul: we're working on a similar line to empower ad servers on functionality
GangWang: I look forward to contributions from multiple experts
<kleber> Maybe we should have a separate one-off to talk about the Multi-Party Computation questions Mehul is talking about
Mehul: a generic setup that many ad servers could implement
GangWang: open to other crypto designs
JohnWilander_: on microtargeting prevention
… we consider the "cliff attack"
… where a bad actor behaves one way until they reach threshold
<jrosewell> In order to use time efficiently next week could Google provide some data on this issue ahead of next week’s meeting? https://
JohnWilander_: and then change, once they reach threshold
… consider
… is there any signal that reaches the advertiser, you've reached threashold
… and can now microtarget
GangWang: there's no signal back to the advertiser
… and creatives are rendered in fenced frame
… in eventual end state, bundle served in fenced frame, advertiser's creative server doesn't have decision
… we need to think holistically, agree we need to think more
JohnWilander_: we have thoughts as well,
… if the user engages with the ad, that's a strong signal
<jonasz> RE "cliff attack": OBTD has a specific algorithm to prevent against that: https://
Mehul: counting-based or outcome-based can be attacked with time
… e.g. after duration on a popular page, then modify
… k-anonymity is not a privacy protection
… need a combinatorial counting
… open an issue for more discussion
<Zakim> kleber, you wanted to discuss bidding via dot product
GangWang: good point, let's discus in more detail
[adjourned]