W3C

– DRAFT –
Improving Web Advertising BG

21 June 2022

Attendees

Present
AramZS, bmay_, dinesh, GarrettJohnson, jeff_burkett_gannett, kleber, kris_chapman, l_basdevant, mjv, punhon, wbaker_, weiler, wseltzer
Regrets
-
Chair
wseltzer
Scribe
wseltzer

Meeting minutes

Introductions and Agenda Curation

Shared Storage (Josh Karlin) https://github.com/WICG/proposals/issues/57 https://github.com/WICG/shared-storage

josh_karlin: Talked about Shared Storage a few months ago
… wanted to give an update
… it's now in WICG

Shared Storage API Explainer

josh_karlin: What if we had a storage mechanism that is intentionally not partitioned by the top frame site
… unlike the other things we've been considering
… Unconstrained, that would enable tracking cross-site, not something we want
… but can we offer controlled version?
… e.g., you only get to read in javascript worklet environment
… insert whatever state of the art privacy tech on data output
… Trying not to be prescriptive of what you can do, but make sure the rate of data export is safe
… We just sent an intent to experiment
… First output gate of two planned
… Imagine you've just performed an auction, with 8 possible ads, do a post-auction-filter and give best ad using cross-site data
… what might you use it for? e.g. lift experiment.
… or frequency cap
… as an example non-ad use case, say you have a payment button
… you want to show the user a "pay" button if they're logged in, or a "sign-up" if not. SS could do the picking and display
… As operator, you have multiple choices of which to display, you can't send back which, because that would leak data
… That's the first sort of output gate we're pitching for M104
… You can try it out in chrome canary or dev browser
… by turning on the privacy sandbox ads API flag

<kleber> The "Privacy Sandbox Ads APIs" flag on chrome://flags

demo page linked from Explainer

<kleber> chrome://flags/#privacy-sandbox-ads-apis is the direct link to just this flag, if you want to play with it

josh_karlin: Second example, private aggregation

https://github.com/WICG/shared-storage#private-aggregation

josh_karlin: some limits. We don't really know what the data is
… the data you write into your shared storage bucket is yours, and you're leaking it at some rate
… we don't want to be able to cross-site identify users
… yet over more time and interactions, more information gets out

AramZS: Thanks for the run-through
… Looking through the demo, wondering how extensively you're looking to test this
… e.g. with partners on the advertiser buy-side
… A challenge of FLEDGE and related proposals is a significant shift in how bidding process operates
… Some thinking about how that shift could occur
… Does it make sense to collaborate with prebid, as they're also working on the same shift?

josh_karlin: open this question to the room
… we're aiming to make the transition easier with event-level reporting
… undertstand the shift from server for browser is a big shift for DSP, SSP
… One thing we're thinking about , if you could have chained URL results
… e.g. if you've chosen one, but the DSP wants to do an experiment, and make a different choice
… challenge that each element in the chain is more information
… Each org is contributing a few bits; when the user clicks the ad, info gets leaked
… could help in adoptability

kleber: I want to highlight that SHared Storage is conceptually different from FLEDGE
… FLEDGE is browser trying to mimic interactions of different parties in ads ecosystem today, creating environment that enables those interactions to happen
… structure of fledge mirrors that environment
… SS is not trying to reflect part of ads ecosystem, it's trying to provide a broadly applicable API with many uses
… like cookies, file system, with write and read
… but with the limitation you can't send the info you read to server, but use on-device for display
… it's not trying to force anything about the ads interaction
… a lower level primitive
… letting others figure out how to use it toward their goals

bmay_: SS is partitioned by eTLD of the entity that originally writes to it?

jkarlin: the origin, like other JS APIs

bmay_: how does someone trying to use this know what's happening, if no information is sent back?
… we have no idea what the browser's doing with the info

jkarlin: once we have aggregate reporting, that's one of the things we want to use it for
… you have this worklet, this is distribution across users of the errors and behaviors
… Would love to get feedback on what kind of tools we should be providign for local debugging, enable utility

bmay_: also an attack vector, as unusual errors are as important to understand;
… and could be a vector for leaking information
… We all have to know across a billion browsers that we're seeing exactly the same execution env

jkarlin: yes, rare vs common
… In aggregation reporting, we're using differential privacy. How much information can leak per time-period, works for both rare and common events
… If you have suggestions, let's talk on GH issues

<Zakim> AramZS, you wanted to respond to kleber

AramZS: 2 things. Want to explore what signals are useful for debugging
… I need to be able to answer ad display questions, in my position. Ad should have shown but didn't, why?
… Seller will have different quiesetions
… This is different in function from FLEDGE, but the shift is similar
… as most adtech environments today don't sent back a wide variety of eligible ads
… The shift in handling adtech logic is similar
… taking a bunch of info that's not currently available to browser, and making it available in worklets
… generally supportive
… similar shift in logic imagined in PARAKEET

<kleber> Hahahaha!

AramZS: analogy: a human eats food in their stomach; a sea cucumber extrudes its stomach. Both are digestive systems!

<bmay_> Nice use of the sea cucumber.

<kleber> Now I need to come up with an API whose acronym is SEACUCUMBR

AramZS: maybe talk more with prebid

<bmay_> +1 kleber

jkarlin: do we have someone from prebid here?

wseltzer: I'll work to coordinate with them on a good forum

<AramZS> I know that they have an open issue on FLEDGE, it might make sense to think of the commonalities of changes between this and FLEDGE and how we can coordinate both together.

bmay_: in today's world, if I have a bad condition, I can turn it off
… in this world, shifts in relationships, have you considered the liability for bad results, e.g. if someone puts a bad worklet out?

jkarlin: not yet. I'm hoping industry can find ways to make the tech work

bmay_: considerable barrier to adoption if people don't know what risks they're taking by using

<AramZS> Here it is - https://github.com/google/ads-privacy/issues/57

jkarlin: wonder what the simplest use cases might be? frequency capping or lift?
… with limited risk

angelina_iabtl: can you repeat the question?

jkarlin: you're using scripts in the browser environment to make a decision; what happens if there's a flaw in the script, and opportunities lost?
… you can currently use event-level

angelina_iabtl: there's a risk of storing the creative in the browser
… if a wrong ad is served
… I've been in situations where the agency has to eat that cost

<AramZS> Yeah, the simplest case is a big question. We're taking a look at this internally, but the scale of change in switching where decision making occurs seems very large, in part because a good end to end test means that we can't just change this on the publisher side, but also need to collaborate with buyers and think through some difficulty around "successful bids" that we would need to have occur and the expectations around ad rendering that are

<AramZS> automated at the buyer or SSP level.

angelina_iabtl: even with best practices, we can't assume everyone reads and follows
… typically, the onus will fall on the person who incorrectly activated, whether agency or publisher
… I've said before, I don't think creative should be stored in the browser
… I've been in position where wrong ad was served, need to swap out in 5min
… e.g., pharmaceuticals not allowed to be served in the US
… need a chain of command, audit trail of who is accountable

<AramZS> To be clear, we're talking about long term storage of an ad, not always the browser mediation ad process? I assume worklets like this would not be cached long term? CC: angelina_iabtl

<Jeff-b> Wendy….couldn’t get off mute earlier. I am prebid board member and will connect you to the right people via email

angelina_iabtl: lots of training needed to help people work with new system

[thanks Jeff-b!]

jkarlin: thanks.
… the ad itself doesn't need to be preloaded in the browser
… served via URL
… but your overall point applies: have to be careful on client-side auctions about user-appropriateness

JoelPM: a number of prebid participants here; there's no "representative" per se

<bmay_> Thanks Joel

JoelPM: we'll have to understand API, would it help use cases that exist

AramZS: to Angelina's point, being capable of auditing and know what happens when something goes wrong
… wrt privacy outcomes, also interested in being able to explain to user why they see an ad
… often, users thinking "this ad shows up in creepy way, and I don't understand why"
… so along with adops, think about how user might be able to understand the system

AramZS: IAB has presented an interesting accountability API

david_dabbs: are you suggesting we should add transparency constraints for ads delivered through this new mechanism?

AramZS: don't know if it's necessarily a constraint, more additional feature
… we're just at the point of thinking how we explain
… in W3C priorities, highest constituency is the user
… so worth thinking about user understanding

kleber: completely agree user transparency should be an important consideration in API development and use
… highlights the fundamental differences between FLEDGE and Shared Storage
… FLEDGE has built a system where the browser understands what has happened
… browser sets limits on what data can be share
… has enough information to say, e.g. you saw this ad because you were added to X interest group on Y website
… we can trace info provenance
… great, because the browser can play user transparency role
… In the case of SS, it's harder to see how the browser can help
… browsers currently give UI for showing all cookies, but that's rarely useful to end-user in finding ad provenance
… if the browser is further removed from decision making, in less position to help with transparency goal

<AramZS> Useful thank you kleber

bmay_: with respect to user transparency, also a question of what the user does with info received, and another potential data leakage vector
… if they do something to respond, they're raising hand in relatively unique way

JoshKarlin_: Thanks, further questions welcome in GH issues

https://github.com/WICG/shared-storage/issues

AramZS: to Brian, what info might users release that leaks data?

bmay_: if I tell the user how they saw a particular ad, they might do something, e.g. to stop it
… if they take action, they're providing information to somebody

bmay_: I queued to note problem with getting information to right people at the right time
… with all these modalities
… need to figure out the information flows
… not build an autonomous vehicle just yet

AramZS: I think users might value from information without taking action
… some want to know how an adtech system understands them
… e.g. those who are concerned about adtech without necessarily understanding it
… engage with journalistic coverage

<GarrettJohnson> One important use case is for the user to be able to "X"-out of an ad to prevent seeing a specific ad in the future.

<GarrettJohnson> Also, there is some value in ad transparency. I think this may be legally required in Europe under the Digital Market Act, but not sure about that.

AramZS: consider brand safety, and users' ability to take action when someone else illuminates the question

JoshKarlin_: agree with kleber's discussion of the difference between special-purpose APIs and this general-purpose
… in terms of explainability
… Browser designers want, if they show something to a user, make it actionable
… you don't necessarily want them to flush some site's shared storage becaouse of one bad interaction

<AramZS> Makes sense!

JoshKarlin_: want to think more about the transparency story

wseltzer: AOB?

AramZS: it might be interesting to hear from IAB TechLab on Accountability API
… looking at similar concepts

bmay_: I was heavily involved in accountability platform proposal
… focused primarily on sharing of IDs across supply chain, user consent signal propagation
… maybe could be adapted, but not sure how
… providing lots of data, potential exposure

<AramZS> The IAB has presented this also as an auditing tool, even outside the ID systems question, which indicates that it might have some useful tools, perhaps?

bmay_: don't think it's directly applicable

angelina_iabtl: Global Privacy Platform, about protocols to manage consent based on regulatory requirements
… Accountability Platform, main goal to use as auditing platform to communicate source of consent and who has permission to use
… If we like, can invite Benjamin Dick to walk through those solutions

wseltzer: thanks! At the ecosystem level, good to hear from other organizations and how the ideas fit together.
… Next meeting not July 5 but July 19.

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/alogn/along/

Succeeded: s/flush shared storage/flush some site's shared storage/

No scribenick or scribe found. Guessed: wseltzer

Maybe present: angelina_iabtl, david_dabbs, jkarlin, JoelPM, josh_karlin, JoshKarlin_