Consider update proposal to leverage TURTLEDOVE style request separation

[michaelkleber]

One key property of the TURTLEDOVE proposal is that there is no way for a publisher to learn what Interest Group one of their visitors belongs to. As a result, if a person used to be part of an interest group and then leaves the group, they won't see group-targeted ads any more. There's no way, for example, that a publisher first-party profile of the user could "remember" old interest groups.

That's why the TURTLEDOVE explainer says "People who wish to sever their association with the interest group can do so, and can expect to stop seeing ads targeting the group."

In this proposal, the user's CohortId is available directly to the publisher site, which means ads targeting it might persist. So this benefit, which you've copied from TURTLEDOVE, doesn't apply to your proposal.

As I mentioned in today's Web-Adv BG call, this is why perhaps your proposal could instead be about a way to build TURTLEDOVE-style Interest Groups (which would have the benefit you claimed!), rather than FLoC-style cohorts (which don't).

[brodrigu]

I think this is a fair point. It's certainly not the intention that previous cohortIDs would be stored or useful, but that wouldn't stop a poorly designed or malicious system from doing so.

I'll update this text for now, and will consider the value and mechanics of using a TURTLEDOVE style request separation.

[brodrigu]

@michaelkleber for your consideration #12

[michaelkleber]

Yup, definitely helps. And using SPARROW-style serving, rather than TURTLEDOVE, would address the "costs" in your Tradeoffs section, right?

[brodrigu]

Yep, though I suspect if we had a trusted "Gatekeeper" we might prefer to leverage that trusted relationship instead of building a trustless API.