How consent management is handled in Fledge?

[pm-harshad-mane]

The AdTech industry must adhere to privacy regulations such as GDPR and CCPA, and there are established consent-management protocols like TCF, USP, and GPP.
Publishers set up Consent Management Platforms (CMPs) on their pages, which allow users to provide their consent to ad-tech companies for delivering ads/content.
These CMPs also offer standard APIs for sharing consent signals with AdTech players on the page, who use this information to provide personalized ads/content.

Questions:
How consent signal passing will be handled in the world of Fledge?

Will Fledge provide the consent signals to SSPs and DSPs in the network calls initiated from the page?

In the case of Prebid, Prebid has a consent management module that takes care of handling multiple scenarios for example If the consent is not given to a particular SSP then Prebid does not initiate the bid-request call, will Fledge do something similar?

There are multiple config options provided by Prebid Consent management modules to handle different scenarios, will Fledge support such config?

Refer:
https://docs.prebid.org/dev-docs/modules/consentManagement.html
https://docs.prebid.org/dev-docs/modules/consentManagementGpp.html
https://docs.prebid.org/dev-docs/modules/consentManagementUsp.html

[pm-harshad-mane]

One thing to note here is that in Fledge the user-specific id is not generated but does that mean the calls generated from Fledge do not need to pass on the consent signals at all?

[dmdabbs]

I'll take a shot @pm-harshad-mane.

TL;DR
The Chrome team has expressed (I'm paraphrasing) that contextual information, e.g. consent signaling, is not within PAAPI's scope. The spec is providing carriage for auction context information PAAPI shares with all a seller's auction participants via the auctionSignals attribute. Any signals available prior to runAdAuction() could be put there. It's up to us in the adtech community to assess whether we can get the signals we need and how to structure them and that there are no gaps in their being usable throughout the PAAPI lifecycle - auctions and downstream (impression delivery &c).

Will Fledge provide the consent signals to SSPs and DSPs in the network calls initiated from the page?

AFAIK network requests like decisionLogicURL, trustedScoringSignalsURL, directFromSellerSignals,
biddingLogicURL, biddingWasmHelperURL, updateURL, trustedBiddingSignalsURL, temporary forDebuggingOnly.reportAdAuctionLoss/Win() &c. do not have unconstrained context info passed to them since that would be a data leakage.

In 'classic' on-device auctions auctionSignals are passed into auctions and provided to all buyers. The emerging bidding and auction services follows this with the seller's "ad service" receiving cleartext contextual info (whatever we decide to pass into the auction) along with encrypted interest group data (labeled as remarketing).

In today's programmatic world, we specify macros so that consent or other signals can be provided to creative fetch urls. This is not possible in PAAPI since an interest group owner's creative url is provided when the browser joins the interest group or when PAAPI calls the interest group's updateURL.

One thing to note here is that in Fledge the user-specific id is not generated but does that mean the calls generated from Fledge do not need to pass on the consent signals at all?

PAAPI may not be generating identifiers, but they could be passed into the auction, and an interest group has userBiddingSignals arbitrary metadata that may be specific to an individual. PAAPI takes pains to ensure that this cannot be exfiltrated

[pm-harshad-mane]

Thank you @dmdabbs for your detailed explanation.

[lknik]

@pm-harshad-mane Interesting question. However, how did you reach a conclusion that a GDPR consent is necessary in this system?

[omriariav]

@pm-harshad-mane @lknik hi! any updated guidance on how we should handle PAAPI auction under CCPA (or any other US privacy law in GPP) regarding the following statuses -
SaleOptOut (do not sell)
SharingOptOut
SensitiveDataProcessing
PersonalDataConsents

@michaelkleber see the above, and let me know, please if I should open a new ticket?

[lknik]

@omriariav Interesting question that would warrant an innovative analysis, and perhaps on a case-by-case basis even. In the meantime, have a look at my analysis w.r.t EU data protection law: https://blog.lukaszolejnik.com/data-protection-assessment-of-privacy-sandboxs-protected-audience-api/

[omriariav]

@lknik, fantastic work. We will need to find a similar analysis to the US privacy laws. I wonder what the right place to do so... should be here or via the IAB, which governs the GPP. What do you think?

[lknik]

@omriariav Thank you! I believe that many of these points are very simple to translate to the US side. However, it should be made with care. In general, I doubt that anybody would be doing such a thing in their free time. That's a complex analysis, and sounds like billable. I did mine as part of the LL.M. thesis :-)

[omriariav]

@michaelkleber do you have any legal analysis you can share? I will ping the IAB legal team as well.

[michaelkleber]

No, Chrome does not have any legal analysis to share here. I can only suggest that you (and all ad techs) speak to your lawyers.