floc
floc copied to clipboard
WICG
Access to CohortID - api vs protocol's header
Hello!
In the README there is only one way of accessing information about the user's CohortID - javascript api. Is it a final decision or only the solution for test purposes? Passing information about cohortID in the header of HTTP request would make integration with already working tools much easier.
Hi @michaljaron, good question. We originally described FLoC as using a Client Hints HTTP header to communicate the cohort, but that turned out to be not technically compatible with running a Third-Party Origin Trial, and technically difficult even during the full launch phase.
Can you say more about how you want to use FLoC that makes it hard to use a JS API?
Thanks @michaelkleber for a quick reply.
I work for a research company, providing surveys for content providers. We deliver our scripts, collecting information on providers' side, so accessing CohortID from javascript forces us to change tools' implementation on our side, but also (what is more painful) all ower clients have to change scripts on their websites. All together implies that participating even only in the origin trials requires a lot of work from us and our clients.
If it's hard for you to update your scripts, then participating in an Origin Trial may not make sense. This early stage of experimentation is a good fit for people who understand that the form of the API isn't finalized yet and may still change multiple times before it reaches its stable form. It sounds like you certainly wouldn't want to re-deploy each time anything changes.
Looking towards the final version of the API instead, there has been a bunch of discussion (e.g. in #45) about only making FLoC available on sites that actively opt into it. I'm not sure how that model could work with a Client Hints header approach to delivery. It seems like it would require your clients to do something, at any rate.
@michaelkleber
After setting up the Origin Trial on my site with meta tag header, should the FLoC JavaScript API be already available? I am currently using Chrome Version 89.0.4389.90 (Official Build) (64-bit).
@michaelkleber Thanks for your response!
I saw that it is now working on Chrome Canary. Will it be available on Google Chrome, since Linux users cannot run Canary?
Yes! Things become available on Canary first, then Beta, then Stable. Won't be long now.
@michaelkleber there was a rather long conversation in a prebid meeting about CohortID today, mostly revolving around how the CohortID is gotten (via a shared module vs each individual bidder), which got me thinking that it would be a lot easier if the CohortID was a header. I was pointed at this ticket and thought I'd comment on here to see if the possibility of moving the CohortID to a header could still be considered? If the CohortID was a header it could still be easily controlled by a user, and if the CohortID is supposed to be a replacement for thirdparty cookies it could even be sent in the Cookie header. Just instead of the HTTP server using Set-Cookie then later getting a Cookie header with that value, it could just get a Cookie header with a CohortID in it if the user has allowed it. A setup like this would also allow CohortIDs to be used in more places which might not have javascript enabled. If publisher controls over CohortID are needed, it seems something could be done similar to how a publisher can request access to the camera or microphone (which I think is the Feature-Request header?), which would allow a publisher to request access to the CohortID which if granted would cause the CohortID to be sent via a header.
The type of header that's appropriate here is Client-Hints, and as I said above, that is how we originally designed it, before we realized that it's impossible to control such a header with a third-party Origin Trial.
We've received a lot of feedback that publishers setting HTTP headers isn't always a possibility. So we'll need to think more about whether there is any way to make this possible.
The publishers currently use a 'Set-Cookie' header when using cookies, so I wonder if that argument is real or just FUD. If the publishers actually needed the control they would use 'Client-Hints' to control, otherwise it feels like a header which should be under user control (similar to the 'DNT' header, which I think was set via user control in a few browsers). I still think that having CohortID in a 'Cookie' header might allow easier transitions as one could just change the key one looks for from a current user identifier to that of the CohortID and use CohortID everywhere one used a third party cookie, but I can understand that's somewhat distasteful as it seems like a hack. But then again it is the web so hacks are all over the place ;). Thanks for reopening the issue.