-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signaling Chrome's CMA-aligned cookie deprecation test label #143
Signaling Chrome's CMA-aligned cookie deprecation test label #143
Conversation
Proposal for signaling Chrome's CMA-aligned cookie deprecation test labels
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. |
Thanks Isaac (@thegreatfatzby). So an object, say 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 |
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:
|
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. |
<td><strong>Description</strong></td> | ||
</tr> | ||
<tr> | ||
<td><code>chrometestlabel</code></td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amended to cdep
cc: @simontrasler
Per conversation thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @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.