Signaling Chrome's CMA-aligned cookie deprecation test label

[dmdabbs]

We encourage the community to opt in to access the testing labels and to share the value unmodified with partners via this community extension proposal. Please take a look and discuss.

[thegreatfatzby]

Hey @dmdabbs , reading through this and the Google posts, my initial thought is to encapsulate this inside of a little object that we could use to add further Chrome Label, Privacy Sandbox, etc, communication if it becomes relevant.

[dmdabbs]

Thanks Isaac (@thegreatfatzby).

So an object, say Device.ext.privacysandbox. That, initially, would have one attribute, say, testlabel.
I'm all for extensibility if we anticipate ch-ch-ch-changes.

My prime motivation is reaching consensus so folks who plan to opt into the label know where to send it and have a chance to take action as code freeze (or code slush as is sometimes the case) sets in. If Google clarifies that labels will be tracked per user, as presently this is ambiguous, then this is more appropriately extended from User.

[thegreatfatzby]

So, I should say that my brain tends to want to go in this direction, and I know there are arguments against it. Abstractly I like the ideas of encapsulating things together and future proofing, but it's not always the best idea.

I can't say I have anything reallllly solid at this point, maybe the first bullet and then a few lesser others:

• Let's say, just totally hypothetically, that another browser from another multinational, releases something like Fledge. And then, further suppose, it does it's own labeling that is similar in concept but not 100% homeomorphic (oh man, I haven't gotten to use that word in almost 2 decades) to what Chrome is doing. I could see wanting a separate label that doesn't have to adhere to Chrome's rules.
• I could see something similar if Android starts doing trials. In theory Chrome is 100% done with rollout by September 2024 and they don't overlap...ever, not possible. I guess if there was overlap time wise they could just use the same groups?
• Seems unlikely but maybe Chrome decides they did something wrong and want to do a second partitioning.
• Maybe the upstream wants to communicate something about PS experimentation it's doing downstream. Maybe the ad server faithfully communicates the label downstream, but still communicates the 3PCs and other identifiers via eids...maybe it's useful to put something in about testing so you'll know how to compete on an even playing field for that request (or choose not to). Or if it does wipe them out it could add a flag saying "I did wipe it out" to differentiate from a normal ID'less request, incognito or some such.
• The Google doc talks about consent potentially being needed to access the labels. Might the publisher want to communicate that consent, or lack thereof, downstream?

[dmdabbs]

The Google doc talks about consent potentially being needed to access the labels. Might the publisher want to communicate that consent, or lack thereof, downstream?

Note that label-specific consent signaling should not be needed. Accessing the label is accessing the user's device. Whatever is available today for that use case should suffice, for example IAB Europe's TCF covers ePrivacy consent. OpenRTB has well-established plumbing for that.

[simontrasler]

My only comment is on naming, so I hesitate to bring this up. :) However, this could be 1. shorter and 2. more specific to the test (I believe this is the value for the Sec-Cookie-Deprecation HTTP header).

[dmdabbs]

Thanks Simon. If one accesses the value via header, it's Sec-Cookie-Deprecation, if via Navigator API, cookieDeprecationLabel()
How 'bout pslabel? Shorter, but not more specific.

I'm fine with whatever shorter attribute on which we can agree. Guess I'm one of those people who aren't into the whole brevity thing, according to the Big Lebowski. But I am housebroken.

[simontrasler]

It's a good question. On one hand, it's "just a test". On the other hand, 10% of Chrome is ~7% of web traffic and the bytes add up fast.

If we could expect to use many of these labels, I'd suggest an object (e.g., labels) and then children of that (e.g., cdep or cookiedep). However, this structure feels like over-engineering.

So, back to a single field. If we could quickly settle on something shorter, like cdep or even cookiedep, that would be helpful. I know this is supposed to be temporary and I want to say I won't lose a lot of sleep over a longer name. And I don't want to extend this conversation more than necessary -- we just need a name so we can move forward. But things tend to hang around longer than expected, and we do prefer short names in the spirit of sustainability.

TL;DR the shorter the better, and we use the spec to explain the field. If you're good to go with pslabel that seems reasonable to me, and thanks for the discussion.

[dmdabbs]

If we could expect to use many of these labels, I'd suggest an object (e.g., labels) and then children of that (e.g., cdep or cookiedep). However, this structure feels like over-engineering.

Agree, @simontrasler. There is supposed to be but one label per browser. Either some flavor of percentage gradient in Mode A, Mode B or, potentially, a label indicating "not A or B," as our friends at Criteo have suggested that Google support. Please +1 that if you agree.

So, back to a single field. If we could quickly settle on something shorter, like cdep or even cookiedep, that would be helpful....we do prefer short names in the spirit of sustainability

I opened with chrometestlabel as a conversation starter. Mission accomplished.
SOLD to the man proposing cdep! Or gcdl (for Google cookie deprecation label).
Either is fine, let's tie a bow on it.

Anyone else? Bueller? Bueller?

[dmdabbs]

Amended to cdep

cc: @simontrasler

[simontrasler]

Thanks @dmdabbs!