Skip to content

Commit

Permalink
Merge pull request #12 from MagniteEngineering/TURTLEDOVe
Browse files Browse the repository at this point in the history
Writing up TURTLEDOVe style workflow
  • Loading branch information
brodrigu authored Jul 30, 2020
2 parents 9d4d5b0 + 4ee3fab commit 35bcb7b
Showing 1 changed file with 83 additions and 0 deletions.
83 changes: 83 additions & 0 deletions TURTLEDOVE-style.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
# Proprietary Cohorts provided via Two (or more) Uncorrelated Requests Then Locally Executed Decision of Victory Everybody!

We often have the opportunity to trade some functionality or convenience for increased privacy. The workflow descibed in the TURTLEDOVe proposal offers a method which could be applied to the concept of Proprietary Cohorts to increase privacy.

We will outline how this could work, and discuss the tradeoffs of this method.

## How it would work

A website (news-publisher.example) who chooses to utilize proprietary cohorts adds a new html tag to the page header:

```
<link rel="cohort-provider" href="https://cohort-provider.example/.well-known/cohort-assignment.js" reader="first-ad-newtork.com">
```

A supporting browser reads this tag and executes a request to https://cohort-provider.example/register?cohortRegistrationId=12345&domain=news-publisher.example where 12345 is a unique identifier generated by the browser included on all cohort registration requests across domains to this provider.

The cohort provider records this cohortRegistrationId and domain to build a proprietary graph of browserIds and behaviors and returns a cohort ID to the browser.

```
{
cohortID: abcd
}
```

The browser stores this cohortId but does not make it directly available to webpage.

The reader attribute indicates the ad-network that should get access to the cohort id.

From here, we borrow some of the TURTLEDOVe workflow:

Since a relevant ad network is used by a web site I visit regularly, a while later my browser contacts first-ad-network.com and requests ads targeted at this interest group:

```
GET https://first-ad-network.com/.well-known/fetch-ads?cohort=cohort-provider.example_abcd
```

The response points at a [Web Bundle](https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html) holding an ad, along with some browser-intelligible metadata about when that ad can appear, and some ad network logic and data for later decision-making.

```
[{'cohort-owner': 'cohort-provider.example',
'cohort-id': 'abcd',
'ad-cbor-url': 'https://first-ad-network.com/ads/ad-123456789.wbn',
'cache-lifetime-secs': 21600,
'max-times-per-minute': 1,
'max-times-per-hour': 6,
'auction-signals': {'atf_value': 250, 'btf_value': 25},
'decision-logic-url': 'https://first-ad-network.com/js/on-device-bid.js'}]
```

The browser fetches the on-device bidding JS and the Web Bundle. The bidding JS is very simple:

```
function(adSignals, contextualSignals) {
return contextualSignals.is_above_the_fold ?
adSignals.atf_value : adSignals.btf_value;
}
```

A while later I visit news-publisher.example again (or perhaps another publisher using cohort-provider.example). An ad network script on the page requests ads from first-ad-network.com. The response requests an in-browser auction to pick between a contextually-targeted ad and the previously-fetched proprietary-cohort-targeted ad:

```
const contextualBid = 107;
const metadata = {'network': 'first-ad-network.com',
'auction-signals': {'is_above_the_fold': true}};
const rendered = navigator.renderInterestGroupAd(contextualBid, metadata);
if (!rendered) {
...render the contextually-targeted ad...
}
```

The ad network's on-device auction logic runs, and since the network believed the ad would render above the fold, it returns the atf-value 250. The browser compares that to the contextual ad's bid of 107, finds that the contextual bid is lower, and renders the previously-downloaded web bundle. The news-publisher.example page shows an ad for the targeted cohort.

## Tradeoffs

As compared to the initial proposal for Proprietary Cohorts, the TURTLEDOVe style workflow offer the following additional benefits:
* The users cohortID can not be associated with any first party data and cannot be persisted after it has been cleared/changed.
* This adds a couple of TURTLEDOVes goal outcomes to Proprietary Cohorts. namely:
* People who wish to sever their association with the interest group can do so, and can expect to stop seeing ads targeting the group.
* Web sites cannot learn the interest groups of any specific people who visit them.

These benefits come with the following costs:
* Marketers cannot quickly adjust campaign goals as cached client side ads must have reasonably long ttls to have a change to serve
* Additional bandwith and memory is needed on the client over-use of which could lead to degraded user experience, particularly on older devices.

0 comments on commit 35bcb7b

Please sign in to comment.