<wseltzer> join the BG via https://www.w3.org/community/web-adv/join

Agenda-curation, introductions. Including reminder to formally

Gatekeeper certification

<wseltzer> https://github.com/WICG/sparrow/blob/master/gatekeeper_certification.md

<inserted> scribenick: wseltzer

Basile: I'll do the intro
... we introduced two changes with SPARROW compared to TURTLEDOVE, with first new reporting proposals
... and introduced trusted gatekeeper
... so as not to do everything in the browser
... This is because we heard about performance issues e.g. with video
... we've shared concerns with SPARROW on TURTLEDOVE
... and because we do not want to just offer ideas, we have a proposal for how to certify the trusted entity
... we want to collaborate on how trust is given to the Gatekeeper
... This is a first step, and we'd like to hear feedback, proposals to improve the
... proposal. We want to define together with all interested parties
... including privacy advocates, browsers, advertisers, etc.
... the code of conduct.
... This code of conduct defines general rules surrounding gatekeepers
... It would be used as basis for certification
... We will ask audit-certification companies to use code of conduct to certify actors [who want to become a gatekeeper]
... This specialized certifier would audit [Gatekeepers] to make sure that gatekeeper is actually respecting the rules that were defined
... This auditor will have ability to certify/decertify
... that decision has costs [for Gatekeeper], as browser would choose whom to trust based on these, and would stop sending requests to uncertified Gatekeepers.
... We think that could help this group to make progress

https://github.com/WICG/sparrow/blob/master/gatekeeper_certification.md

bleparmentier: we'd like feedback: is this a reasonable way to certify trusted gatekeepers?
... stgart toward real process for certification

btsavage: wonder if this cert proposal would benefit from something like SGX
... lets you run code with certain guarantees
... you could have certification body, use SGX to get hash by which to verify that it's using the open source code
... then the certification is limited to verifying th open source code
... reduce the burden of trust
... a) trust that the cert body reviewed the code for bugs
... b) and trust Intel's SGX
... did you consider that?

bleparmentier: thanks

<btsavage> https://en.wikipedia.org/wiki/Software_Guard_Extensions

bleparmentier: happy to hear that suggestion
... want to look at that in defining code of conduct

<Zakim> kleber, you wanted to say there is Certificate Authority history that we should learn from

kleber: re SGX, there are two parts of what needs to happen for browser to communicate with/trust server
... one is what happens with SGX, there's open code, audited, with a governance model, so we know what it's supposed to do
... SGX can help us assure we're running what we think
... second is that the server is running as intended, protecting HTTPS keys and data
... those are part of the auditing, not technical solution
... some combination of technical and auditing regimes
... that's in-line with Criteo proposal
... There's a lot of history with auditing processes for servers
... browsers have some experience with those processes, e.g. with Certificate Authorities
... one of the lessons: you have to be cautious about the financial incentives
... the proposal has the Gatekeeper responsible for paying the auditor
... that's a bad misalignment of incentives
... you want the auditor incentivized to look carefully, not to grant certifications too easily
... look at that past experience and examples

bleparmentier: thanks for the point re incentives
... we borrowed from other examples, where the auditors are paid by the one being audited
... happy if we can find a better alternative

<Karen> Scribenick: Karen

<bleparmentier:> [to Michael Kleber] do you think it's worth following up on this proposal?

Wendy: James on queue
... if question to Michael about worth following up

Michael: Yes, agree we should follow up on proposal
... support moving forward with how to make it work

James: add to what Michael and other speakers said; deep and hard quetion
... how to ensure rules are being followed
... reminder about draft charter for decentralized web
... need to bring in other skill sets
... not so much engineering challenge; SGX
... other initiataives
... next steps is to engage broader group of stakeholders to get their insight

<jrosewell> https://w3c.github.io/charter-drafts/decentralized-charter.html

James: share that observation and plugged the decentralized web IG

Wendall: I am confused here
... I recall a conversation a while back; a Gatekeeper thing
... I recall response that this is technique we are trying to avoid
... one ring to rule them all in AdTech
... industry doesn't really tolerate that
... How would this actually work?
... Neutral fashion to run databases?
... Once upon a time there was a decentralized way to do this
... to signal privacy policies they were obeying; rich algebra on a strong

s/string

scribe: Some of you may recognize URL

<weiler> [decentralization has some pretty serious charms....]

scribe: not technical but some policy discussions of past 20 years
... we are not addressing the core criticism
... the two browsers no long wish to do this tracking concept
... need measurable, reliable media delivery without tracking
... not clear on this Gatekeeping proposal at all

Bleparmentier: two comments
... In SPARROW it's a trusted server that runs with as much data as needed and as little as possible
... The gatekeeper has limited scope
... it should never get user ID (or PII)
... yes, browsers don't want third party tracking
... but because of cost on the open Internet
... they want to replace it with something else
... Sparrow builds upon TURTLEDOVE to allow online advertising.
... In SPARROW, the Gatekeeper needs to follow a lot of rules
... I don't think the Gatekeeper necessarily is against the browser rules.
... It is not the one ring to rule them all.
... The idea to have an ecosystem with a new player is not surprising
... we are brainstorming how advertising will work without third party cookies
... It is not surprising that it paves ways for new players
... I am happy to organize a call with you about Gatekeeper role and limitation in SPARROW
... You can see SPARROW page where we explain the limited roles
... maybe that can help
... look at Sparrow
... we did a session with the measurement proposal
... we can do that on Gatekeeper

Wendy: I am hearing two levels of conversation
... If a Gatekeeper is needed, how would these certification proposals work
... And, do we want a Gatekeeper; both are live areas of conversation
... we are focusing on how certification fits into Sparrow
... thanks for laying that out
... close queue after Ben and Michael

Ben: I want to respond in more general way to Wendall's statement

<jrosewell> bleparmentier: Am I correct in thinking you envisage multiple gatekeepers? Not just one?

Ben: how I think about this, and generally FB; looking at future with no more tracking
... and how to preserve most important advertising cases
... one poss is everything is distributed and only on device
... Safari folks taking that approach
... some things done on device, some things done on servers
... both are worth investigating
... if we are going to do some computation within servers
... more powerful; not same battery considerations; run more powerful algorithms; offload things; more flexible deployment regime
... Limits of mobile devices; do not scale
... if possible to do things on servers
... leads to next question about what we would have to do to send data to some server we won't control
... Assume FB won't control this infrastructure
... what would it take for FB to feel comfortable
... Do various things
... technical guarantees
... is one part
... what tech guarantees that you do not need to trust in humans; trust in math or encryptions
... two versions I have seen
... One is Chrome aggregated measurement proposal
... secure multi-party cryptography
... or SGX for encryption and privacy guarantees
... talk about how secure, strong, resilient to attacts
... and a process thing
... rotate SSL keys and other server stuff
... Wendell, I think your characterization of Sparrow
... Chrome measurement is stateless; like that
... stateless APIs perform on batch of data
... no record of devices; stateless computation thing
... less familiar with Sparrow
... think it's designed with data limitations
... worthwhile conversations
... to get more complex and sophisticated use cases, we might want to use server
... how to we trust

<Zakim> kleber, you wanted to say not all trusted servers are the same — see some discussion in https://github.com/jkarlin/floc/issues/20#issuecomment-673562620

Michael: I got on queue
... but I think Ben said everything I wanted to say
... Only thing to add...absolutely correct the server we are going to trust
... in model with some server side component
... make that server as simple, understandable and auditable so we know what it should do
... as browsers will need to feel comfortable sharing information with this hypothetical Gatekeeper type server
... that we would not share elsewhere
... figure out what is the weakest requirement that that server could possibly have and still meet use cases
... give server as little special power as possible
... Wendall's example about keeping track of data about every individual person
... is a lot of power
... not likely to be on the table; not likely to trust that kind of server
... haven't figured out what level for Sparrow's Gatekeeper
... but figure out how a server gets some min amount of information
... trust not to do fingerprinting
... reasonable avenue to explore; what we should be figuring out

Kris: I was going to recommend
... thinking about Gatekeepers and who those trusted parties could be
... Sir Tim Berners-Lee has a new start-up called Inrupt
... that could be a trusted Gatekeeper
... move data to actual users and consumers
... Think of it as Flickr
... upload photos

<jrosewell> Isn't if for the person who uses the browser to decide who they trust and who get's their information? Enabling that trust choice and adding auditability is what we're talking about.

Kris: Inrupt doing that for data
... puts control with users
... meets in the middle situation t make sure consumers do have the control and allow access to a level of data and tracking that they want

<kleber> (hey @wseltzer can we change some Webex setting so that everyone starts out muted by default)

Kris: I just wanted to recommend that is something folks could look at
... for possible companies to look at for Gatekeepers

Wendy: Aram, I saw you trying to queue up

Aram: I was wondering if we know we are building something that Safari does not intend to support
... should we account for that?
... thinking out issues

Wendy: you are right that is an element of consideration
... as things advance further, validating assumptions where there is interest, how much of Web is willing to support this becomes more important
... At this point, part of the work is fleshing out proposals so they have enough
... so would be implementers and users can understand them and express interest

<jrosewell> It's a very important issues for the One Web purpose of the W3C. Another reason for multiple gatekeepers.

Wendy: Did you want to say anything more?

Bleparmentier: Happy there is support to follow through this code of conduct idea to define
... what can we get in trusted servers or not
... What condition gatekeepers must satisfy in the future.
... This would allow for the creation of a server that would allow performance without infringing on user privacy
... happy to see this level of interest; now we have to make it work
...so that we can create this new entity of gatekeepers in the future

Outcome-based TURTLEDOVE

Wendy: Thank you
... moving on
... sent a message of introduction

<wseltzer> https://lists.w3.org/Archives/Public/public-web-adv/2020Sep/0003.html

Jonasz: At RTB House we are looking at ways to actively improve the existing proposals
... present today our latest idea

<wseltzer> https://github.com/jonasz/outcome_based_turtledove

Jonasz: outcome-based Turtledove
... some existing feature requests on Github
... to bid more accurately
... has other advantages
... Problem to solve is approach to micro targeting hurts accuracy
... target single users with individual ads
... TD wants to disallow
... approach is input based
... restrict input the function gets
... if it cannot differentiate interest
... most visible in fetch ads

<wseltzer> https://github.com/jonasz/outcome_based_turtledove#more-accurate-bidding

Jonasz: TD design ensures design of fetch ads is uniform across members of IG

l...comes up in other places; issue #5

scribe: addition of new bidding signals is discussed

<kleber> (New bidding signals discussion: https://github.com/WICG/turtledove/issues/5)

scribe: information on recent impressions; membership page of an IG

<wseltzer> https://github.com/WICG/turtledove/issues/5

scribe: when another signal is proposed; consider impact of micro targeting
... downside of input based approach to micro targeting prevention
... makes it hard to bid accurately
... makes sense to differentiate bid value
... this is not possible with TD
... we propose outcome based targeting
... label each ad as validated or no
... let's say an ad wins on auction but has not been validated

<wseltzer> https://github.com/jonasz/outcome_based_turtledove#outcome-based-td

scribe: browser would discard and call it ghost win
... browser picks highest bid and that becomes impression
... How to validate ads
... if ad becomes ghost winner
... validate that ad
... stream of ghost wins would translate to stream of impressions to many unique users
... this is proposal

<jonasz> https://github.com/jonasz/outcome_based_turtledove

scribe: take a look at our Github page with our proof of concept algorithm
... we can reason
... proof of concept algorithm we can show ad has high chances of being validated only if there is @
... why we think this shift from input to outcome based is beneficial
... first this allows bidders to have wider range of bidding signals
... we propose custom bidding signals
... other signals
... like those discussed in issue #5
... could be added without need to aggregate
... Secondly cost of implementing TD is lower for bidders
... internal analysis shows adopting outcome based approach is lower cost
... Thirdly, beneficial to decouple microtargeting from bidding
... outcome based approach, decoupling makes it easier to maintain each of these
... microtargeting and bidding are separate areas
... microtargeting guarantees
... great to hear from browser teams
... from performance bidders and other interested parties to see if they see this being incorporated into TD
... go to our Github page
... happy to take questions
... thank you

Michael: thank you Jonasz
... great, well-thought out proposal
... I wrote original input based proposal
... your output based approach is a great improvement
... one good idea to call out
... was your mechanism of fallback creatives
... where in the case where a TD IG is trying to bid to show an ad
... if ad it wants to show has not yet exceeded this threshold and in the ghost phase because doesn't know it is being microtargeted
... if ad is not certified, shows this other ad as a fallback
... that seems like a good idea
... to deal with the situation where a new ad campaign would have trouble spending because of lack of a certified ad to go with it
... good idea overall
... need to think about thresholds and infrastructure to do it

Arnaud: Thank you RTB House for this proposal
... questions about performance outside of clicks
... 99% of clicks; can you share numbers on objectives, mainly conversions
... visits
... I feel that clicks are very close you can predict with only
... conversions are only quantity
... wondering if you can share stuff around that

Jonazs: Changes are mainly technical
... if we see only a slight drop in CTR model
... see a small drop in other models like conversion rate model
... one more thing, invite you to take a look at what we call user signals
... might greatly improve the performance rate of conversion and other models
... allows for inclusion of more precise signals

Wendy: thanks
... non one further on the queue
... thanks for discussion and inviting further feedback on Github

Dashboard highlights

Wendy: look forward to seeing where these proposals go
... Opportunity to look back at our dashboard
... A lot of issues there currently

<wseltzer> https://w3c.github.io/web-advertising/dashboard/

Wendy: Lots of tracking
... many different repositories
... at our virtual F2F I would like to invite
... the editors of any of these proposal documents to suggest
... items that would benefit from synchronous discussions
... especially where there has been a productive Github thread
... where we want to work out details
... or flag questions people have raised as issues for potential discussion
... It's great to see that a lot of asynchronous discussion is going on
... better way to work out the back and forth

<dialtone> 1+

Wendy: Is there anything right now
... that someone would find useful to raise?

@: outcome based...
... concern why there is only one IG to add someone to
... when browsing web
... size is concern
... lots of different ad sizes, not one specific ad
... not all members of a group would browse same ad size or same subset across the web
... will slow down speed at which you can display ads
... which in turn will have performance degrade; especially with conversion
... with retargeting and behavioral advertising
... drop after several hours on web site
... not sure about threshold
... web bundle...solve multiple sizes
... would punish more smaller advertisers

<kleber> +1 to validating the Web Bundle, as Valentino said

Jonasz: Latency at which ads would be validated depends upon the algorithms and parameters browsers choose to adop

t

scribe: one of assumptions to make inside proof of concept
... is ad renders same each time you show it
... ensure something like that occurs in multiple slot sizes
... perhaps avoid this fragmentation of validation

<kris_chapman> I read something this week that suggested Apple is enabling ITP in WebView in iOS 14? Can anyone confirm?

Ben: suggest a possible topic for virtual F2F
... I've noticed this group
... has become increasingly Turtledove focused over time
... talked about Sparrow, outcome based TD; brand measurement

<kleber> @kris_chapman Yes, Apple announced that in June

Ben: variations of TD
... but I feel like we have not really vetted the underlying assumptions
... one problem to discuss at F2F is there any multivendor interest in TD
... have not heard from any other browsers; that gives me pause

<rotem_eyeo> I agree with btsavage

Ben: secondly, are publishers amenable to idea of not knowing what ad is being rendered on their site
... assumption that blind ads is good assumption

<kris_chapman> thank you, @kleber!

Ben: and we have not done enough to talk about user experience
... tracking...confusing about targeting browser ad
... idea about transparency and some level of control to turn off

<jrosewell> btsavage: Also it would be good to get an update from Project Rearc and IAB TL about their solution. IAB TL are technical arm of PRAM with some pretty big stakeholders in this space. https://www.ana.net/content/show/id/ResponsibleAddressableMedia

Ben: does this solve our user experience
... what is approx optum to expect
... really important foundational questions that we have not spent time evaluating

<AramZS> Does anyone in the browser side think Rearc is realistic? I don't think they have said so.

Ben: Like to do this before evaluating TD

<kleber> TURTLEDOVE only moved into WICG after a sign of interest from Firefox: https://discourse.wicg.io/t/advertising-to-interest-groups-without-tracking/4565/17

Wendy: balance between understanding proposal enough to get that feedback v. going into unnecessary detail if there is not interest
... without not asking people to commit to a product in next quarter
... but get people's expression of interest to help focus some of that discussion

<jrosewell> AramZS: Google are members of PRAM and IAB TL.

Wendy: thanks, Michael for that pointer above
... Apologies to Arnaud and Aram, we are out of time today

<AramZS> Perhaps we can address Ben's questions first thing next week?

Wendy: if you want to suggest topics for future discussions, please send to list or put in irc
... we will wrap up now
... invite your follow up for the next meeting

<AramZS> Google being a member is different from agreeing that Rearc will work.

Wendy: I will look into the settings for "mute" on join
... thanks for all of the participation

[adjourned]

<kleber> s/"mute on join"/"mute on join"

<kleber> :-)