Hi all,

Google Ads has put together a document that considers a modification for SPARROW which simplifies the Gatekeeper to a key-value server.

We think this modified approach may accelerate adoption by both ad tech and browser communities while preserving many of the core Sparrow use cases. The document's scope covers bidding and auction up until creative rendering.

We would welcome your thoughts and feedback on our write-up.
https://github.com/google/rtb-experimental/tree/master/proposals/dovekey

Thanks!

Hi,

Criteo proposes an open one-hour technical workshop on SPARROW on Thursday, July 16 at 5 pm CET = 11 am US East Coast time.

Zoom call details are here: https://lists.w3.org/Archives/Public/public-web-adv/2020Jul/0012.html

Purpose of this workshop is to address technical open questions, with a particular emphasis on reporting (and how and why it differs from TURTLEDOVE).

Please create issues in advance on GitHub for questions you would like to discuss (https://github.com/WICG/sparrow).

Minutes will be published in the form of answers to these questions.

Hi,

Thanks to the many constructive feedbacks on the SPARROW proposal, we are happy to propose a new version for the reporting capabilities. We believe that this proposal improves on securing users privacy without much compromises on the advertising use cases that SPARROW aims at preserving. In order to do so, we replaced the log-level reporting by three different levels of reporting, each of them playing on granularity and delay to serve different advertising use cases:

• A low latency aggregated report, whose purpose is to be used for campaign spend management and billing
• A delayed, personalized, display-level report, defined by the user, with privacy-preserving mechanisms, intended to be used for fraud detection, campaign optimization (machine learning), AB testing, etc.
• A delayed report listing all ad units served (without counting them precisely), for publishers to be able to audit publisher brand safety.

With this actionnable proposal, which should be precise enough to be implemented, we believe we address the concerns on privacy attacks on SPARROW, satisfying privacy sandbox requirements, preserving most of the ecosystem current capabilities, and ultimately allowing for a fair, thriving advertising-backed Open Web. Once again, we thank the community in advance for their feedbacks as they'll help bolster the SPARROW proposal.

Detailed document can be found here: https://github.com/BasileLeparmentier/SPARROW/blob/master/Reporting_in_SPARROW.md

This proposal makes a few technical assumptions that I think need to be clarified.

1. "The Gatekeeper, not the browser, is in charge of resource-intensive tasks: bid computation or ad bundle pre-fetch. This will result in less impact on device resources such as memory or battery life, and less network usage."

Can you quantify this? JavaScript performance in the browser has improved tremendously, to the point of things like full VR applications and AI models being deployed in the browser via JavaScript.

2. "Models executed by the Gatekeeper can be more complex than those that could fit in a js bidding script."

Again, could you be more specific about this? What model is really so complex that the JS interpreter in a modern browser can't deal with it?

I generally agree with your certification process & who does what, and when regarding certification. But I'm having trouble following the high level description of what functions each party is responsible for. For example,

"Browsers would send interest group information along with bid requests, and subsequent ad rendering information only to the certified entities."

If this is the case, does the Gatekeeper then send what it receives from the browser to an exchange? In effect the Gatekeeper becomes a hop in between pubs and exchanges? Would bidders still submit their bids to an exchange or would they submit them directly to the Gatekeeper.

The flow diagram at the bottom would be more illustrative if it contained the interaction between publisher and gatekeeper in addition to advertiser and gatekeeper.

In your reporting proposal's section Report on Ads Served you say "the publisher receives all web bundles" that rendered on their site.

This seems hard to reconcile with the proposals on the TURTLEDOVE repo like WICG/turtledove#31 from @jonasz or WICG/turtledove#36 from @appascoe that propose ways to make a web bundle targeted at just one individual. There are privacy problems with showing the publisher the ad that says "Hey Michael Kleber, your insulin prescription is about to expire, click here to reorder!"

Are these in fact mutually exclusive desires, or do you all think there's a way to achieve everyone's goals here?

From a browser point of view, it's hard for me to get comfortable with the notion that we'd offer a mechanism that looks like it sends a message to just one person, but in fact there's a built-in way for someone else to see it.

If the gatekeeper were to share a public key, then we could eliminate the communication between the browser and the gatekeeper. Instead, the browser could encrypt the interest group info using the public key and send it along with the contextual request to the ad network. The ad network could then get contextual bids as documented and request interest group bids in the same auction, by passing the encrypted info along with the request to the gatekeeper(s) (each requiring their own encrypted data for the advertisers they handle). Only the gatekeeper would be able to decrypt their interest group data.
Even though the gatekeeper is trusted, this eliminates the ability of the gatekeeper to see the user's IP address or other identifying details, so an evil gatekeeper would need to work harder to associate the interest groups with an individual.

Prompt for discussion in SPARROW technical workshop July 16th (see #14):

Can you explain what makes a variable un-protected? It seems that it's supposed to be something that can be known only to one party (either the advertiser or the publisher). But how can the reporting system be sure of that?

It's certainly not enough to say that a value is un-protected if one party comes up with it without talking to the other party. To take an obvious example, the publisher's code knows the time when the page loaded, and the advertiser's code knows the time when the ad rendered, but if these were both un-protected variables, then of course they would immediately let the two parties join up their reports. (As I mentioned in #9, I don't believe that an agreement to not collude or share data is a viable protection.)

I think that without un-protected variables, this is very nearly the same as aggregate reporting, though you're proposing k-anonymity instead of differential privacy. That is, a report containing each row, with k-anonymity used to redact rare values, is very similar to a report that lists each sufficiently-popular event and the number of times that event occurred. (The ranking preference idea here matches up with the Aggregated Reporting section "Grouping multiple keys in one query")

But joining these with un-protected variables seems like a pretty substantial change in the reporting model.

In Reporting in Sparrow, you define non-protected variables:

Non-protected variables
Many variables are relevant for one player only, like ad labels (click, view, click id), ABTest ID (see ABTest section below), and the interest group for the advertiser. These variables should be hidden to the other players and do not need other specific attention in this report, they do not represent any risk with regard to the user privacy and can be reported as is per display.

Non-protected suggests these variables are available to anyone.

I would suggest using private to align with class variable types or perhaps hidden or single-party to more accurately describe how they are treated.

Hi,

I was trying to find any issue which might have discussed possible implementation of Gatekeeper as a Decentralized Node

Have we considered following possible implementation?

SparroW3.0 - Decentralized Gatekeeper on a dedicated block chain where validators are ad-tech vendors

• Validating addition of users to interest groups based on size of Interest groups
• Execution of Smart contracts for Bids
• Ability for Smart contracts to call External APIs but Smart contract ensures no PII is leaked in the external web2.0

Advantages I can think of:

• Publicly verifiable chain implementation and smart contract implementation
• Shared cost of running Gatekeepers (economics yet not clear)
• Prevents paper legal work for compliance of Gatekeepers

Issues I can think of:

• Chain executions are generally slower than needed in ad-tech
• Might require custom implementation of the chain & network for Interest groups / PIIs handling
• Decentralized gatekeepers hosted by vendors can become attack vector for privacy of users, but I think can be mitigated by rotating the nodes which are contacted by User's browser

Let me know if there's any key concern in above possibility of interest-based targeting

Thank you for your attention to TURTLEDOVE and your desire to improve on it! To help me understand SPARROW, let me ask some questions about the flow of information between the browser, the Gatekeeper, and the ad network.

For the purposes of this Issue, I'll assume that everyone agrees that the Gatekeeper is perfectly trustworthy.

At that point, the ad network calls regular DSPs for contextual bids and the browser calls the Gatekeeper with interest groups and page contextual data.

Does this mean the "contextual data" is all computed by the browser and the publisher's ad network? In TURTLEDOVE, by contrast, it's possible for each DSP to learn the URL of the page and compute its own contextual signals (discussion).

Resulting bids are returned to the ad network which selects the winner.

First, this seems like a very large information channel, probably hundreds of bits. What prevents the set of bids from encoding lots of data that we are trying to keep private from the ad network?

Second, it seems like the ad network sees these bids (from the Gatekeeper) and the contextual request (directly from the browser) at nearly the same moment. It seems like it would be straightforward to match the two up, since the bids can be influenced by (and therefore can encode) contextual signals. This would make the information leak in the previous paragraph even worse.

If the Gatekeeper is already being trusted to run the ad network's code faithfully and keep it secret (when producing the bids), could it run the auction code that selects the winning bid as well?

The Gatekeeper notifies the advertiser, with a variable delay around one minute, of the display, including the winning interest group, the ad data (campaign, product, layout), the bid value, and the publisher it was displayed on.

This event-level reporting seems like another opportunity for the ad network to join contextual information with interest group membership directly (or to conclusively join the two ad requests of a minute earlier, if that hasn't already been done).

TURTLEDOVE deals with this by only allowing aggregated reporting for information derived from both contextual and interest-group information, and we've had some discussion about the latency. But it doesn't sound like this is just about an hour vs a minute, since you later say "reporting data at the display level, with the interest group and publisher information, allows for the advertisers to learn better ML models".

It seems like knowing the interest group, the publisher, the bid, and the minute is more than enough to know the exact event, and so join the interest group with the user's publisher-site identity.

Can you see any way to avoid this?

The Gatekeeper receives interests group x publisher data, but cannot link this data to individual users since it has no user-level information.

Maybe this sentence sums up part of my worries about this proposal. The publisher knows the user's first-party identity ("Hi! I'm NYTimes subscriber 12345!"). All publisher data could be influenced by this: any signals that feed into bidding, the contents of the page, even the URL might contain PII.

I don't see any way to separate publisher data from user-level information. Are you looking at something differently?

Prompt for discussion in SPARROW technical workshop July 16th (see #14):

The aggregated report "with the possibility to have real-time information" needs that turn-around "to be able to pause/start, control budget/bidding level, ... with very little latency."

Updating the value in real time seems problematic — I don't see how we could keep it from being used as a signal to detect individual events. The contextual signals mean that the buyer network is in a position to pick out one specific auction and give some campaign the instruction to bid on it. But if there is some campaign that only has one opportunity to show an impression during some minute, and the advertiser sees that campaign's budget drop vs. remain unchanged during that minute, then we've allowed the buyer network to learn the exact context (including publisher-domain identity!) of a person who saw some ad. This is enough to join people's identities across domains.

It seems to me that there are a variety of ways to avoid this privacy problem, which all come down to not letting the buyer observe a very small number of events. That is, "real time" isn't the problem, "real time even if the change is only a handful of events" is the problem.

I'd like to talk about the specific ad buyer flows that you want to support, so that we can figure out what possible approaches could meet those needs without risking buyers seeing the results of individual auctions.

(Continuing the post-TPAC Gatekeeper privacy discussion that was kicked off in public-web-adv email)

While #16 deals with privacy issues in the reports generated by the Gatekeeper, the TPAC discussion highlighted that the Gatekeeper auditing only covers the code for the Gatekeeper-provided functionality, and not the DSP-provided code that actually generates bid values.

This DSP-provided code is arbitrary and probably complex. In the normal course of operations, it gets to see all the signals that come from the browser — in particular it sees both the contextual signals and the interest group, the two pieces of information which must not be joined up according to the privacy model ("Web sites cannot learn the interest groups of the people who visit them").

Therefore, the Gatekeeper's job must include ensuring that the DSP's bidding logic cannot "smuggle out" that information.

It looks like in Auction Step 3, the DSP-produced bids are sent to the publisher-chosen SSP. If the bids are returned along with the identity of the advertiser, what you called the "less disrupting option", then I can't see any way to maintain privacy! But even if not, the bids themselves offer lots of opportunity to exfiltrate information.

For the winning bid, this would need to be in the "less-significant bits", though the remedy you mentioned in email ("4 digits rounding") still seems like it leaves plenty of room. But for losing bids, all of the information in the bid is available for smuggling user data out.

I don't see any protection here that would prevent a colluding DSP and SSP from learning all of a user's interests very quickly.

Dear W3C participants,

We are excited to share with you a Gatekeeper (as defined in SPARROW) certification process proposal. These Gatekeepers are necessary trusted servers for online advertising to work without negatively affecting user experience whilst protecting their privacy.

We propose to define together, with all interested parties, a code of conduct that would cover both principles (e.g. no fingerprinting) and rules of operation (e.g. following reporting proposal to disclose information about the ads served).
This code would then be used by certification authorities to certify and audit Gatekeepers to ensure compliance.

We consider this proposal as an actionable first step for the creation of Gatekeepers. This proposal is meant to be challenged, we are open to any suggestion or modification to this proposal to allow trusted entities to be certified.

Please join us in defining this code of conduct and the certification process for the emergence of a trusted server, that would allow for better privacy, user experience, and web monetization.

link can be found here: https://github.com/WICG/sparrow/blob/master/gatekeeper_certification.md

Do you imagine that conversions are reported to the Gatekeeper as well? This seems undesirable to me for a lot of reasons.

For example, it means that the Gatekeeper needs to keep logs of impressions around for a long time, waiting for conversion events to join up. It's not at all clear to me how the "Reporting in SPARROW" reports would interact with impressions that didn't have a conversion at the time the report was generated but got one later.

Turtledove

Hi all,

At RTB House we have been working on ways to improve recommendation quality under Turtledove and Sparrow. We've put together a document describing one possible approach, together with high level estimates on CTR impact.

For the sake of discussion the document focuses on Turtledove, but the core ideas are also compatible with Sparrow. It would be great to hear your thoughts and suggestions.

https://github.com/jonasz/product_level_turtledove

Best regards,
Jonasz

One thing I haven't seen in either TURTLEDOV or this proposal is a way to geotarget? Currently, we get lat/lng from the bid stream, and since we have unique IDs (cookies, or more likely IDFAs) then we can target that same user and also do in store conversion attribution.

Is there any way to target based on approximate lat/lng with either proposal?