search

WICG / floc

This proposal has been replaced by the Topics API.
https://github.com/patcg-individual-drafts/topics
Other
934 stars 90 forks source link

Hide FLoC from Advertisers and Publishers #125

Open RussStringham opened 3 years ago

RussStringham commented 3 years ago

Many of the privacy concerns raised around FLoC could be addressed if the FLoC was not actually exposed to the websites that a user visits. One way this could be accomplished, would be to expose it only through two paths.

First, the browser would send the FLoC along with the contextual data to the PARAKEET anonymization proxy (or similar), which would then route it to the ad networks without revealing to them the actual user. The ad networks would not be able to incorporate the FLoC into a user profile, since they won't know which user this is, but they will be able to use it to serve an ad.

Second, when an ad served as a result of a FLoC where the user later converts, the aggregate reporting API should report not only the value of the ad to aggregate conversions, but should break that down by the different FLoCs used to select that ad. The reporting should also include the user's current FLoC at the time of conversion, so that advertisers can discover the FLoCs that are more likely to be associated with people who convert.

dmarti commented 3 years ago

In the current implementation, browser extensions can read or send the cohort by injecting a script into the page. If the cohort is not exposed to JavaScript on the page, then any browser extension that reads or sets the cohort would need to have a different API.

https://github.com/WICG/floc/issues/17

Sora2455 commented 3 years ago

As much as I appreciate the thought, the entire point of FLOC is for advertisers to target ads for the current user at the moment the user loads the page. I don't agree with this goal, but it is the goal. Removing the ability for advertisers to know what cohort the user is in as the page loads disallows the main use case of FLOC.

RussStringham commented 3 years ago

@Sora2455 The title of this issue is probably misleading. Under this proposal, while the publisher can never see the FLoC, the ad network (on behalf of the advertiser) does see the FLoC. However, the ad network does not know who the user is. They only know their FLoC and whatever contextual data PARAKEET has shared with them. What I meant about the advertiser not seeing the FLoC refers to when the user visits the advertiser's site. The advertiser must rely on the aggregate reporting API to understand which FLoC values have a higher propensity of converting.

michaelkleber commented 3 years ago

Hi Russ, thanks for opening this discussion.

You're quite right that a FLoC-like bidding signal that is not visible to the publisher page would address some of the privacy concerns we've heard about the current API. And indeed the original TURTLEDOVE explainer talked about this possibility, along the lines you propose. There are two main reasons we didn't start by pursuing that approach:

  1. Adoption would be harder. TURTLEDOVE (or FLEDGE or PARAKEET etc) has a more involved request flow, and forces the restriction to only aggregate reporting. These are certainly harder for ad servers to adopt than FLoC's very simple "here is one more signal for you" approach.

  2. Knowing what to target would be harder. If we're hiding the FLoC signal from the publisher page at ad serving time, then of course we must also be hiding it from the advertiser at conversion time! So advertisers' ability to even figure out which cohorts they might want to target also would need to rely on the aggregate measurement APIs.

It may be that your proposal is the right way forward, and that having a targeting signal revealed directly to the web platform is the wrong trade-off. But the very large usability advantage is hard to ignore.

michaelkleber commented 3 years ago

(Noting for backlink purposes that @johnwilander has proposed investigating this as well, in https://twitter.com/johnwilander/status/1406309626233032706)