Persistent Opt Outs

[thegreatfatzby]

Background

Today we have a little page, the Xandr Privacy Center, which a consumer can go to to make elections about how their data is used, in our case pretty simply "do not use my data". It has two options: one which will set your Xandr Cookie to -1, which will indicate an opt out, and Xandr Platform will respect on a go-forward basis, for both our ANID and any other IDs we may get on a request (RampID, etc); the second will do that and record the ID (can be a device ID as well) so that any IDs we have linked at the household level are also opted out.

(There is also the MSFT Privacy Dashboard that does similarly for the MSAN platforms, it has a few other variables, but we can focus on the Xandr piece for our purposes here).

Issue

With Cross Partition 3PC going away, I'm actually not sure how we'll accomplish this anymore.

• We don't have a cross partition cookie to tell the browser "send me -1 in the future on all requests so I know to treat you as opted out".
• I can call clearOriginJoinedAdInterestGroups but based on what I'm reading here that won't do anything on a go-forward basis.
• I can set a CHIP to -1 but I won't get that on every request from the browser, only on that partition, so I won't know to not set a CHIP on other partitions.
• I could join an Interest Group and call it OptedOut=true or something, but that only impacts my behavior in PAA, and I'm not sure how we'd have that indicate "don't bid" across all of a domain's IGs in the long run.

So, all else equal, the following will occur:

• In 2025, user U has been browsing the web, and Xandr has dropped CHIPS in multiple partitions, and multiple Interest Groups.
• A user comes to Xandr Privacy Center and opts out, saying "don't use my personal information for advertising".
• We can set the CHIP for xandr.com to -1 and call clearOriginJoinedAdInterestGroups(adnxs.com, etc).
• CHIPs still exist for all other partitions.
• When the consumer visits nike.com, which they previously visited, we see a CHIP with no Interest Group, and make an IG since we can't see the xandr.com partition CHIP that says OPTOUT.
• When the consumer visits rebok.com, which they had never previously visited, a CHIP is set and and IG is created, since ^ same reason.
• When the consumer visits any site, those new IGs can be used, violating the directive.
• More subtly, when the consumer visits a site using RampID, we won't have a thing tell us not to use the data.

Solution?

In the "previously visited" case we could use "CHIP w/o IG" as a signal, but that is a weak/noisy/bad signal I think; I'm not sure what we even could do in the "not previously visited" case (fingerprinting based opt outs :) ).

Could clearOriginJoinedAdInterestGroups offer additional flags to:

• Disallow future IG creation from that domain.
• Set 0-variance "virtual CHIP" that the browser knows to send on any request to adnxs.com, with a value of -1 (or whatever, 0-variance) to tell the ad tech this is opted out?
• Alternatively to previous it could silently disallow all CHIP creation from that domain, but I thiiiiinkkk that would be too broad.

[dmarti]

Global Privacy Control (GPC) might do what you're looking for here. It's a persistent setting that works independently of third-party cookies.

Although GPC has a specific legal meaning in some jurisdictions, there's nothing preventing an individual company or industry organization from also treating it as equivalent to their old cookie-based opt-out.

Most users aren't familiar with the specifics of web advertising, so GPC would likely produce less surprising results than an opt-out that is tied to PAAPI. (It also means less code to maintain than separate opt-outs for PAAPI and non-PAAPI browers.)

[lbdvt]

On the same use case, @thegreatfatzby : #573 (comment)

Also, I guess that Xandr "do not use my data" applies to all forms of processing for web advertising. If so in the case of Privacy Sandbox, the solution should apply not only to Protected Audience, but also to Topics, Attribution Reporting, and Shared Storage.

[thegreatfatzby]

@dmarti thanks for the suggestion. That said, I'm not quite following, might need a bit more elaboration.

I hadn't looked at GPC since doing Xandr's US Privacy work last year, just reviewed it, to summarize a few key things:

• From a server perspective, if we get the Sec-GPC header we could then treat it as equivalent to opted out.
• But, I don't see a way for either our client or server side code to instruct the browser to do so. For Chrome in particular it looks like an extension is still needed to make sure Sec-GPC is actually sent on all websites, not just from the TLD where a cookie was set.
• If there was a way to do that, we'd be electing the user into not just an opt out of sale for our tech, but for all requests to all techs, which means we're taking the users instruction to us and making it an instruction to the internet. (It may very well be the case that the overlap of users who would go to the trouble of finding Privacy Center and those who want GPC is quite high, but I don't think we can assert that).

So I guess my main question is if there a way to instruct the browser, Chrome in particular, to always set GPC?

[thegreatfatzby]

@lbdvt agreed.

[thegreatfatzby]

@michaelkleber I'm curious if you'd be open to something directionally like this:

• Chrome provides a discrete set of settings, each with enumerated values, that a domain can set. (I.e. it's not free form for either the name or value).
• Those values would be sent in as cookies or some other header on any request to that domain from that browser, across partitions.
• If the user blows out their cookies, these are deleted as well.

So two examples could be:

• OPTED_OUT can be 0 or 1. adnxs.com could set that when we receive an optout at pc.xandr.com, but know it will come back to us on any request.
• Chrome Mode A/B Labels: being able to set this once would really simplify some things, remove odd edge cases, etc.

[thegreatfatzby]

Maybe we could call them E-CHOPS: Enumerated Cookies Having Overlapping Partitions State?

[dmarti]

@thegreatfatzby GPC is one of the specifications to be discussed at the proposed Privacy Working Group. Right now it is not implemented in Google Chrome as far as I know.

The current trend in the privacy policy and services scene is to try to give users fewer, but more effective controls, so GPC might be more future-proof than an opt-out tied to a specific technology. For example,

• Permission Slip by CR is a service you can set up once to opt out of data sale/sharing by a growing list of companies
• The California Delete Act establishes a public registry to do multiple opt outs with with one action

GPC is different technically, but it also ties in to the trend of trying to minimize privacy labour for users.

If an opt-out takes effect only one domain at a time, there is a backwards incentive for domains to provide worse opt-out UX. Whoever can design the worst opt-out is going to end up being able to collect the most data. Enabling opt-outs that take effect for all domains connected to by the same browser (or user, if they share a preference across multiple devices) means you won't get punished relative to competitors just for improving UX.

Currently many privacy polices include instructions on how to set up a third-party-cookie-based industry opt out, and those tend to be less reliable than GPC which can be set once in a browser preference. There may be a few users who want to out out of just Xandr and nobody else, but they're going to be rarer than people who just want to opt out.

[thegreatfatzby]

Coming back to this after a bit, few comments I'll separate out.

@dmarti I certainly agree that if there is a global opt out available, and it's reasonably clear what it means in the context of a request to a platform, in a jurisdiction, etc etc, that platform should respect that opt out w/o needing an additional platform specific opt out for that purpose.

For right now I still think a per-platform opt-out feature makes sense to pursue for a few reasons:

• Reading and communing with the GPC proposal more, it seems there's some consideration in there for cases where the meaning is unclear, or a platform needs additional guidance in a particular jurisdiction or for some other reason.
• Right now both Xandr and MSFT more broadly have a stated privacy policy and do receive instructions from users on our privacy sites that we need to respect, and it doesn't currently make sense for us to use something global for the reasons mentioned above. It would be interesting and arguably good if the global (meaning earth global) standard became to only use global (meaning internet wide) opt outs, but I don't think we can swing that lawyer wise now.

Now I suppose what we could do, technically, is on our privacy site say "You can opt out of our services by indicating a global opt out. Some ways to do that include installing this Chrome extension...etc"...I'm not sure which side will win that battle internally :)

[thegreatfatzby]

So @michaelkleber et al, we talked about this in our Wed group a bit back, and my "enumerated cookie" idea didn't get much love (whatevs), but I was digging around Private State Tokens and it seems to have evolved in a direction that is kinda-sorta like what I meant, so I wanted to bounce this off the group.

Very Coarse Sets

A much better way to say what I meant by "enumerated cross partition cookie", might be this from the PST Motivation doc (highlights mine):

Segmenting users into very coarse sets satisfies other use cases that establish web trust as well. For instance, sites could use this as a set inclusion primitive in order to ask questions like, “do I have identity at all for this user?” or even do non-personalized cross-site authentication ("Is this user a subscriber?")

One of those "very coarse sets" for a site/service could very well be "is opted out", and that seems like a reasonable "web trust" use case.

So I'd like to reframe for this forum as whether "site defined coarse set segmentation" is a use case that Privacy Sandbox is open to, or even currently wants to, support, with/without design limitations related to "web trust"? I would see what PST is today as a great starting point, with a few issues I'll call out below.

Couple of Specific PST Notes

The challenges I think we (Xandr/MSAN, others I suspect as well) would hit with PST as it exists now are around some of the (intentional) design limits that were baked in for Trust Tokens and I'm unclear if PST wants to evolve in a more general, if not unlimitedly general, direction:

• Need for registration (seems that is going away?)
• Limit of 2 issuers per top level site.
• Key rotation.
• Token expiration.

I thiiink we could deal with token expiry by setting an effectively unlimited expiration date, never redeeming a token, and just using the query API hasPrivateToken. Key rotation mayyyybe could work by just not rotating, although that doesn't seem great.

But for this to be a reliable primitive for something like opt-out-status, the 2 issuer limit would be a problem, as that could get quickly filled with opt outs on 2 out of the many ad tech platforms, let alone other types of services.

Private State Tokens Limitations

So my more general PST questions seem more appropriate in the PST repo, but I'll refer to it here. WICG/trust-token-api#288

[ruturajv]

I wonder if the DNT header could be useful.

sequenceDiagram
    participant b as Browser
    participant s as K-V Server
    participant g as generateBid.js
    b->>s: with DNT header
    s->>b: sends a Key with DNT flag
    b->>g: Call generateBid(...with args)
    g->>b: No Bid !   

Loading

• Each SSP can choose to bid / ignore based on the header.
• Caveat: DNT is deprecated.

[thegreatfatzby]

@ruturajv thanks! Yeah I think that would be interesting. Am I getting it right that, at least in theory minus the deprecation status, DNT is similar to GPC at least in the sense that it is a browser level setting, i.e. you tell the browser "send DNT=X" and it sends it every (or most) requests it sends out?

(Also nice sequence diagram, I need to get better at those).

[dmdabbs]

Chrome has a recently-opened issue to remove DNT.

Remove Do-Not-Track Settings and Header (https://issues.chromium.org/issues/41440843)

[dmarti]

GPC is not currently supported in Chromium/Chrome but there is a feature request issue for adding support: https://issues.chromium.org/issues/40745270

[thegreatfatzby]

Right, the downside to using something "browser level", DNT/GPC otherwise, is that it would cause an opt out of advertising on all platforms, and impact non-adtech requests as well (I'm assuming, to be fair). Again I'd guess the overlap of people who would visit privacy-center.xandr.com to opt out, and those who want GPC=1 everywhere, is high, but I don't think Xandr should be making that choice for other platforms (and again I'm curious the non ad tech consequences).